🕵️♂️ Step-by-Step Debugging in Make.com: A Beginner’s Guide

Introduction: Why Debugging in Make.com is Crucial

At a glance, making scenarios in Make can seem very straightforward, even to a beginner. Further along, it can become complex, which often ends up being one of the reasons for a scenario not acting like it's supposed to. That's where debugging comes in - to detect and fix something if it has gone wrong. Be it bugs or unexpected behavior, that's what debugging is all about. It is a core competency for any Make user.

This tutorial will break down the entire debugging process into very simple, easy steps so that you can follow them. You will then be able to troubleshoot your scenarios even if you are an absolute beginner in the area. You will have much more confidence by the end of being able to identify, fix, and handle those errors which might come up and make sure that your automations run seamlessly, performing exactly as they are supposed to.

I. How Make.com Scenarios Work

First and foremost, it's important to understand the general structure and flow of a scenario before one can get a good enough idea of debugging it.

A scenario is nothing more than one step or module after the other. Each module does something specific, like sending data to an API, updating a spreadsheet, or sending an email. How those modules are connected and ordered in execution is critical to how your scenario works, and how it might fail if something goes wrong.

1. Breaking Down Scenarios in Make.com?

1.1. Trigger: The Starting Point of Every Scenario

In Make, every scenario begins with a trigger. An example of a trigger includes any event that is capable of initiating the play of the defined scenario, such as new entries in a Google sheet or a new inbound email. It is important to know what triggers your scenario since this will be where the execution flow begins. If your scenario is not running at all, the first thing you should check is the trigger.

1.2. Modules: The Building Blocks of Your Scenario

Following the trigger, a chain of modules is in place, such that each module works on one piece of work. For example, one module may go out to the database and fetch data, another module may process the data, and yet another sends the data to a different service. These modules work in sequence, passing the data through each of them as a unit. If something goes wrong, it’s often helpful to check the modules step by step to see where the problem might be.

1.3. Flow of Execution: The Sequence That Matters

The order in which your modules execute within a given scenario can be referred to as the execution flow. Think of this as following a recipe: you start with step one, then move onto step two, and so on. It's an important order, because if there is some kind of error in one of the early modules, it may stop the whole scenario or provide incorrect data for the next modules to handle, thus leading to more errors.

2. Common Mistakes When Building a Scenario in Make 

Error messages from scenarios will fall into three categories:

• Internal errors

• External errors

• Silent errors

Knowing how to recognize each type of error and what to do will give you much better debugging capability and productivity.

I'll break down each error type in detail, so you’ll have a clear understanding of how to handle them. No need to worry—I'll guide you through each one step by step.

II. A Step by Step Approach to Debugging in Make.com

With an idea of how scenarios work, coupled with the types of possible errors, you can now start the process of debugging. The following section will guide you through steps to follow in finding and fixing problems within your scenarios.

1. Input and Output Data Analysis

• Bubbles: In Make, the small bubbles that come up above each module are all you have to work with to understand what happened in your scenario. They indicate if a module executed correctly and with what data it was dealing.

• Green Bubble: The green bubble shows the successful completion of a module. You can click on it to view the input data and also the output data from that module. It's actually really useful for checking if it did what you think it has done.

  

• Red Bubble: A red bubble signifies that something is wrong. When you click on the red bubble, you will see an error message and the data that was erroneous. You now have a start in trying to figure out what was wrong and how to fix it.

  

• Gray Bubble: It means that the module is represented by a grey bubble and it did not run. That could be because the conditions for the module weren't met, or it could be that a previous module failed and stopped the scenario before it reached this point.

  

• Inspect Data: Clicking a bubble will show what the module received as data and what it returned. If, contrary to expectation, this does not hold, either something has gone wrong with input of data to the module, or else there is something wrong with how it is set up. By careful inspection of this sort you can often chase down a symptom to its source.

  

2. Fixing Internal Errors Step-by-Step  

2.1. Definition of Internal Errors

Internal errors occur within Make’s own tools and modules. These errors typically happen when data isn’t in the correct format or when a module isn’t properly configured.

2.2. Example

Suppose you’re using a JSON module, and you pass a plain text string instead of a properly formatted JSON string. Make will throw an error because it doesn’t recognize the text as valid JSON. Such mistakes are common, especially when dealing with new data formats for the first time.

2.3. How to Handle Internal Errors

Step 1: Know the error message. 

• Every time a red bubble shows, you can click on it, and it will show the error message given by Make. Most of the time, it will inform you about something that has gone wrong, like "Source is not a valid JSON."

• Example: For an error message like "Source is not a valid JSON," what it means is that the data was expected in JSON format, but it was not properly formatted. This clearly gives you an idea of where to begin solving the problem.

  

Step 2: Look Through Input Data

• After identifying an error message, one can click on the bubble to take a look at the input data that generated the failure. This will be important as it will help indicate the data that this module was fed and probably why it failed.

• Example: If the data comes in plain text and the module is expecting a JSON string, you will understand why there is a data format issue. Consequently, you can revisit the module, identify the module that supplied that data, and fix the format.

  
  

Step 3: Run the Scenario Again.

• After making the above changes, run the scenario again, which is going to show the correct status. If you get a green bubble, then the problem is fixed. If it is still red, you might need to cross-check your input data or look for other problems.

  

3. Working Through an External Error One at a Time

3.1. Definition of External Errors

External errors take place every time your scenario interacts with services outside Make, like APIs, databases, or webhooks. There can be many reasons why this error might occur - either the said external service is down, it might be returning unexpected data, or there could be an issue with the setup implemented by your scenario in order to interact with this service.

3.2. Example

Let's say that your scenario is supposed to fetch data from an API, but the API endpoint is incorrect or the server is down. Your scenario might return a 401 error (incorrect API) or a 500 error (server error). These errors originate from the external service, not from within Make

3.3. How to Handle External Errors

Step 1: Check the error message. 

• Generally this will be in the red bubble and provided from the external service. The message may also contain an HTTP status code within, for example, 404 (Not Found) or 500 (Internal Server Error)

  

Step 2: Include an Error Handler

• The coming line is a way by which you can avoid the whole statement from crashing. You can include the error handling in the module itself. This allows the specification of actions that should be applied when an error occurs – to retry, skip the error, or take an alternative action.

• Example: In case of a non-fatal error, an error handler can be established as "Ignore," which indicates to the scenario to just ignore the error and continue with the further steps of the scenario. This would prevent the scenario from halting completely over a trivial matter.

  
  

Step 3: Run the Scenario Again

• After putting an error handler in place, rerun the scenario to test its behavior. The scenario should still run on getting an error so that the other modules can execute.

  

4. Tracing and Fixing Silent Errors on Your Make Website

4.1 Definition of Silent Errors

Silent errors are the most difficult to catch due to the fact that they don't throw a clear error message. Instead, they often return incorrect results or do some other unexpected action. Most often, such errors occur due to logic flaws in your scenario or because data is processed in a way you did not anticipate.

4.2. Example

Suppose your scenario is designed to retrieve a date value into Google Sheets. You expected a date to be in the format “August 2024” and instead see a number like “142024 14 08 24” in your Google Sheets, you know your data is in the wrong format.

Technically, the scenario may seem to have worked because no errors were thrown. However, the scenario results in incorrect or incomplete output. This is considered a silent error.

4.3. How to Handle Silent Errors

Step 1: Observe the output data.

• The thing with silent errors is that sometimes they are a bit elusive, in that no clear error message will be generated, and even the output may be wrong. Instead, you will have to check the output data from each module against what you were expecting.

  

Step 2: Work back to the source of the error

• After identifying that the output data is bad, run backward to identify which module generated bad data. Check the input data to that module, then see if the mistake occurred one step earlier than that module.

  

• For example, if this is the wrong format of a date and it should have gone through a module that processes timestamps, then you would have to adjust the settings accordingly in that module to turn into some human-readable date format.

  

Step 3: Edit the logic or data handling.

• After identification of the problem module, edit the logic or data handling of the scenario as in the case. This could be reformatted data, checking for the conditions in a different manner, or changing the sequence of the steps. Finally, execute the scenario to check if the problem has been solved.

  

III. Advanced Techniques in Debugging and Error Handling

The more you work with Make, probably the more complex scenarios you will be building, and the advanced debugging techniques will help you a lot in such cases. In this section, we will explain some of the more sophisticated methods for ensuring the smooth running of your scenarios.

Debugging using the HTTP Module

Test with webhook.site: 

• In using the Make HTTP module to send requests to web services, at times they tend not to work the way they should.

  

  Tools like webhook.site can be invaluable to debug HTTP queries because they allow everything that is sent and received to be visualized.

  

• Example: If your situation sends a request to a URL but it doesn't receive back the desired response, you can use webhook.site for capturing this request. It will show exactly what data: headers, query parameters, and body. Through comparing this to what you expect the data to be, you can see where the fault lies.

  

Understanding Status Codes

While working with the HTTP module, it is paramount that one understands HTTPS status codes for debugging. Basically, these codes tell a user how the application processed their request:

• 200-299: Success.

  The request has been dealt with successfully, as well as receiving the expected return.

  

• 400-499: The client has erred. 

  A lousy request, or the request, in general, could not be processed. One of the examples is the 404 error message that the required resource will be unable to locate.

• 500-599: Server Error.

  The Server has an error in processing your request. A 500 is an example of an Internal Server Error.

Example: If you get a 404 error, it might mean the URL is wrong or the resource is moved. A 500 error would indicate that the problem is on the server's side. Maybe it's because of overload or probably under maintenance.

IV. Best Practices for Debugging and Handling of Errors

Developing sound debugging skills and robust scenarios necessitate that you maintain best practices in your workflow.

1. Test Your Scenarios Incrementally

Test Small Parts: Rather than build and test a very large, complex scenario at one time, the approach is to break the large scenario into components. Test these components separately in order to identify each working part before assembling them into the whole scenario. That way, you can tell where the errors occur quite easily.

Example: For example, if your scenario such as the “LinkedIn Post Scaping” tutorial involves collecting data, processing it, sending it to Apify, calling back data from Apify, and then inserting the processed data into Google Sheets, test each step separately. First, ensure the data collection works as expected, then test the data processing, and finally check the API call. If something goes wrong, you'll know exactly which part of the scenario needs attention.

Once all the modules are set up correctly, click “Run Once” to test the entire automation.

2. Utilize Online Tools and Resources

Utilize Debugging Tools

• Many free online tools are at your service to assist you in debugging your scenarios. For instance, test and debug using HTTP requests using webhook.site, or services like ChatGPT can be used to decrypt very complex error messages to offer a solution.

• E.g., if you're a beginner developer and ask in ChatGPT about an error message that you don't understand, you could learn where the problem may be coming from and how to solve it.

  

• Similarly, testing HTTP requests with webhook.site can let one see what is exactly being exchanged back and forth and be hence in a better position to identify where the problem lies.

3. Quick error handling reference

If you want a more detailed overview of error handling in Make, including the different directives available, you can visit this article on the Make website. It offers a comprehensive guide to understanding and implementing error handlers effectively in your scenarios.

Conclusion

Debugging is a critical skill to someone working with Make and also one that naturally improves with experience. With the steps and techniques mentioned in this guide, you can quickly spot and correct the mistakes in scenarios. This assures you of these scenarios to run smoothly and effectively.

Remember to approach debugging systematically. Start by building your understanding of how the scenario operates; next, establish what type of error is being experienced, and finally apply the appropriate fix or fixes. You will learn with practice how to proceed with errors, and you will be able to debug even the most complex of scenarios. By all means, keep experimenting, testing incrementally, and documenting your work, and you will soon be an experienced Make user.

We'd love to hear from you! Have you ever had any particularly frustrating errors crop up while using Make? How did you defeat them? Or are you still wrestling with some that you're not sure how to solve? Share your experiences and tips in the comments below - your insights may help someone else who's wrestling with similar frustrations.

If you are interested in other topics and how AI is transforming different aspects of our lives, or even in making money using AI with more detailed, step-by-step guidance, you can find our other articles here:

• Ready to Trade Smarter? Build Your Own AI-Powered Stock Trading Bot with Zapier - No Coding Needed*

• Master AI Automation: 10 Levels from Basics to Advanced

• Discover the Power of AI: A Comprehensive Beginner's Guide to Workflow Automation

• A Detailed Guide to Transform Client Info into Insightful Reports with AI Research Automation

• 10 LinkedIn Posts Daily Made Easy with This AI Automation!*

*indicates a premium content, if any