How to Add and Configure Modules in Make.com

Decide what the new module should accomplish

Before adding a module, describe its job in one sentence. For example: “When a new task is received, create a reporting row,” or “When an opportunity reaches a qualified stage, notify the assigned owner.” If the action cannot be described clearly, the scenario probably needs a process decision before it needs another module.

Also identify the business state that should trigger the action. A new module added after every incoming record may process items that are incomplete, duplicated, cancelled, or not relevant to the next step. A filter or a different trigger may be more appropriate.

Write down four items before configuration:

• Input: Which module supplies the data?
• Decision: Which records should continue?
• Action: What should the new module do?
• Output: What result must be available to the next step?

How to add a module in Make.com

Open the relevant scenario in the Make.com editor and locate the module that produces the data required by the next action. Select the control for adding a module at the appropriate point in the route. Depending on the scenario layout, this may be the plus control beside an existing module or an equivalent insertion point on a route.

1. Choose the app that will perform the next action.

2. Select the operation, such as creating a row, updating a record, searching for an item, or sending a message.

3. Confirm that the new module is positioned after the step that produces its required input.

4. Open the module configuration and create or select the connection to the target service.

The app and operation determine which fields become available. A create operation will usually ask for fields needed to create a new item, while an update operation normally requires a way to identify the existing item as well as the values to change.

Do not choose an operation only because its name sounds close to the intended result. “Create,” “search,” “get,” and “update” have different effects. Choosing the wrong one can create duplicates or cause a scenario to appear successful without changing the intended record.

Configure the target resource before mapping fields

After selecting the app and operation, configure the resource that the module will work with. This may be a spreadsheet, table, list, project, folder, database, contact, or another supported object.

1. Select the connection that has the required access.

2. Choose the specific file, workspace, database, list, project, or other resource.

3. Select any lower-level location, such as a sheet, table, board, folder, or pipeline.

4. Review the fields that Make.com loads from that resource.

Field names and available options can depend on the selected resource. If the destination structure has recently changed, refresh the module fields or reopen its configuration so the mapping choices reflect the current structure.

Required fields deserve particular attention. A required field may need a value from an earlier module, a fixed value defined in the scenario, or a value generated by a previous search. Optional fields should not be populated automatically just because they are available. Extra data can make downstream reporting harder to interpret.

Map data from earlier modules

Mapping connects an output from one module to an input field in another. Open a destination field and select the relevant value from the mapping panel. The available values normally come from modules that run earlier in the same route.

For each mapped field, check three things:

• Meaning: Does the source value represent the same business concept as the destination field?
• Format: Is the value in the form the destination expects, such as text, number, date, email, or record identifier?
• Availability: Will the source value exist for every bundle that reaches this module?

For example, a task title can map to a reporting name, but a task owner object may not map directly to an email field. The destination may require the owner’s email address rather than the complete owner object. Similarly, an update action may require a destination record ID, not the visible name of the record.

Static text and mapped values can be combined when the resulting value is useful to a human or a downstream system. A notification subject might contain fixed text followed by a mapped task title. Keep these expressions understandable. If a field contains a complicated transformation, consider whether a separate preparation step would make the scenario easier to maintain.

Example mapping sequence

Imagine a scenario that receives a new task and records selected information in a reporting table. The task module might provide the following outputs:

• The task title maps to the reporting table’s name column.
• The task status maps to the status column.
• The owner email maps to an owner email column.
• The task identifier maps to a source ID column used to identify the original item.

The source ID is especially useful when a later version of the scenario needs to update an existing reporting row instead of creating a duplicate. The exact fields will differ by app, but the principle is consistent: store enough information to understand and reconcile the result.

Choose execution order and filters deliberately

Adding modules in a line creates an execution sequence. Earlier modules provide the context and data used by later modules. That order should follow the business process, not just the order in which actions were first imagined.

Use a filter when only some bundles should continue. A filter can check a status, date, category, email value, or other condition. For example, a notification route might continue only when a task status is “Ready for review.” A reporting route might exclude records that do not have a stable identifier.

Place the filter before the action it controls. This prevents the downstream module from running for records that should not receive that action. If different conditions lead to different actions, use separate routes and make each route’s rule easy to understand.

A filter should express a decision that someone in the business could explain. Conditions based on unexplained field combinations are difficult to maintain and make scenario behaviour harder to audit.

Adding a third module safely

After the first new module works, you can add another action to the route. A common pattern is to write data to a destination and then send a notification, create a follow-up task, or update another system.

Before adding the third module, decide whether it should use data from the original module or the newly added module. If it needs the result of the new action, map from the new module. If it only needs information from the original event, mapping directly from the original module may be simpler.

For an email or notification module, define the recipient, subject, and message body separately. The recipient should come from a validated address or a known owner field. The subject should identify the event. The body should include only the information the recipient needs to take the next action.

Be careful with dependent actions. If a notification should be sent only after a record was successfully created, place it after the create module and test the failure path. If the notification is independent, coupling it to the destination write may create unnecessary delays or make troubleshooting harder.

Run a controlled test of the complete scenario

Testing should confirm more than whether the scenario runs without an error. It should verify that the right record was processed, the right values were mapped, filters behaved as intended, and any later action used the correct output.

Test at least one record that should pass and one that should be stopped by a filter. Also test missing or unusual values where they are realistic, such as an empty optional field or a task without an owner email.

Common problems after adding a Make.com module

The expected field is not available

Check whether the previous module has produced a sample output and whether the selected destination resource is correct. Refreshing the available fields may also be necessary after changing the structure of the destination.

The module runs but creates incorrect data

Compare the mapped source value with the destination field definition. A label, name, and identifier may look similar while serving different purposes. Review the actual bundle data rather than relying only on field names.

Records are processed more than once

Review the trigger, scheduling behaviour, search criteria, and create-versus-update decision. If the workflow needs to recognise an existing record, store and use a stable identifier instead of matching on a changeable display name.

A later module does not run

Inspect filters and the output of the preceding module. A filter may be working as designed, or the previous action may have returned no bundle for the next step to process.

Keep the scenario understandable as it grows

A scenario becomes harder to operate when every new requirement is solved by adding another module without clarifying ownership and data flow. Name modules where the platform allows it, keep filters close to the actions they control, and remove mappings that are no longer needed.

Document the business purpose of unusual conditions and identify which system is authoritative for important fields. Reporting should support a decision, not merely collect every value available. Notifications should have a clear owner and expected response. Automation should reduce manual work without making exceptions invisible.

For broader system design, workflow implementation, and connected data practices, see ConsultEvo’s systems and automation services. Examples of connected operational systems are also available in the ConsultEvo portfolio.