Integration
Integration means combining systems. Between systems, it is a connection that transfers data or triggers actions without manual copying.
On this page
Source content checked . English translation published 2026-10-27.
In business automation
An integration is an agreement between systems about what information moves, in which direction, and how often. The connection also needs to handle differences in field names and in how each system identifies a customer.
What moves, and in which direction
Define what information leaves each system, where it goes, and how often. In Make, mapping determines which information received from an app is passed to a destination and what changes are applied to it. This is a Make capability, not business approval to write to every field in the destination.
An example of data received in a Make bundle helps identify which fields were available in that example. It does not prove that every future record will contain them. Before implementation, document the transfer direction and business rule for each field separately.
Who determines each field’s value
There is no need to declare one system the source of truth for all data. Authority can be defined field by field: the project management system determines the project name, a proposed conversion rule supplies a status for the report, and a local role retains control of a note that the connection is not allowed to change.
The card below is an edited example of such rules. The field and system names are generic, and it does not describe a mapping, permission, or default found in a real account.
What to do when a value is missing or old
Decide in advance what a missing value, an empty value, and a value absent from the conversion table mean. There is no universal rule that works for every connector or API, so verify the behavior against the specific connection’s contract and documentation.
When information comes from two directions, decide how update order is determined before overwriting an existing value. Arrival time alone does not guarantee that the information is the newest, and clocks in different systems are not necessarily synchronized.
How to distinguish output from a destination result
In Make documentation, Input is the information sent to the external app, and Output is the information returned by it. A module response alone does not prove that all business fields were saved correctly. Reading the selected fields back from the destination is an editorial acceptance criterion, not a guarantee made by a particular connector.
An Instant trigger in Make waits for incoming data when run once or on its own. No example may mean that no input arrived, not necessarily that a field is unsupported. Do not submit a live form to create an example. The checks in this entry have not been performed; without an authorized, isolated test environment, the procedure remains a plan only.
Scroll the table sideways to read every column.
| Example report field | Who determines the value | Proposed transfer rule | What the reader needs to check |
|---|---|---|---|
| Project name | Project management system | Copy the title into the report. The system and field names here are generic and for illustration. | Can users change the name in the report, and what will happen to that change in the next update? |
| Work status | Project management system | In this example, the value "Waiting for equipment" is shown in the report as "Blocked". This is a proposed business rule, not a tool default. | Is losing this detail appropriate for report readers, and which values have not been mapped yet? |
| Due date | Project management system | When there is no date, mark the date as missing. Do not automatically fill in today’s date. | What is the difference between a missing field and an empty field, and what format or time zone do both sides expect? |
| Manager’s note in the report | The role that manages the report | The connection does not write to this field, leaving the local note under its owner’s control. | Do the connection permissions and settings allow writes to this field to be avoided? |
Examples
These examples illustrate a possible workflow. Adapt the connections and rules to your own systems.
Business process example
For illustration only: a payment processor reports a payment, the CRM is expected to mark the deal as paid, and the service system is expected to open a kickoff task. The transaction ID is retained at each step so the same event can be tracked. This is a conceptual example, not a tested workflow, and it does not create a payment or write data to a customer account.
Relevant tools
- Make
- Make lets you map information received in a bundle to fields and actions later in a scenario. You still need to define who is authorized to write to each field, how to handle missing values, and which result to read back from the destination.
What to check
- Define who is authorized to determine each field. Two-way synchronization without rules can overwrite a correct update with an old one.
- Distinguish between a missing value, an empty value, and a value absent from the mapping. Check actual behavior against the specific connection.
- Do not rely only on a module’s output. Read the selected fields back from the destination, in an authorized, isolated test environment only.