Make

What Make is

Make is a visual platform for automation and application integration. Its unit of work is the scenario: a set of modules that receives data, applies operations and produces results. Its current catalogue advertises more than 3,500 applications, and the platform also includes agents and AI assistance.

A visual representation makes the information path easier to follow, but behaviour depends on configured fields, conditions and connections. The central question is which process needs resolving and what evidence will verify it. A simple scenario may be more valuable than an extensive diagram if it handles exceptions correctly and another person can maintain it.

Reference documentation: About Make · Make scenarios documentation.

History: from Integromat to Make

Make developed from Integromat, a platform created in the Czech Republic. The official biography of co-founder and CTO Patrik Simek dates the project’s beginnings to 2012; the corporate page describes serving customers since 2015. These references concern different stages of development.

Celonis announced its acquisition of Integromat on 14 October 2020. Make launched as a new brand and platform on 22 February 2022. It remains part of Celonis, with its headquarters in Prague.

The former name still appears in older tutorials and scenarios. When using those materials, check whether they describe the current product, a previous interface or commercial conditions that have changed. Funding and valuations for the whole Celonis group should not be attributed to Make alone.

Reference documentation: Patrik Simek: co-founder and CTO · About Make · Celonis announces acquisition of Integromat · 2022 at Make: launch of the new brand and platform.

Modules, data bundles and iterators

Make passes information between modules in data bundles. An Iterator turns a list into separate bundles; an Aggregator combines several bundles into one output. Understanding this distinction helps anticipate how often downstream steps will execute.

Editorial example: a request contains three material references. Treating the list as one unit may create a single task with three references. Iterating may create three tasks. Either choice can be correct, but they serve different management criteria and require consistent identifiers.

Before aggregation, decide which information must survive for each item. A summary that loses the document identifier or language may look tidy yet be insufficient to locate the approved version. Test empty lists, a single item and repeated items.

Reference documentation: Iterator: arrays to bundles · Aggregator: bundles to a combined output.

Routes, conditions and merging

Router distributes a flow across routes and processes them sequentially, rather than in parallel. A fallback route can handle data that does not meet the other conditions. If-else follows the first true condition and allows the selected route to rejoin through Merge. These mechanisms are not interchangeable.

To classify requests by language, write explicit conditions and reserve a review route for unknown values. Missing information should not be interpreted as approval or an automatic language choice. The fallback route needs an owner and an expected outcome.

A useful test includes overlapping conditions. If a request meets two rules, decide what should happen before implementation. The required behaviour should follow the process need, then be translated into the appropriate module configuration.

Reference documentation: Router: routes and processing order · If-else and Merge.

Scheduling, webhooks and execution order

A webhook receives data through an HTTPS address and can start a scenario when a request arrives. This differs from periodically querying a service. Webhook executions may run in parallel; settings allow one run to finish before the next begins.

This is distinct from route order within one execution. Two simultaneous requests could attempt to change the same record even where each scenario has a clear internal sequence. Define a stable identifier and a policy for concurrent updates.

Also decide what delay is acceptable. An administrative queue may wait; a situation requiring immediate response should not depend on general automation without an alternative procedure. Measure time from receipt to outcome, including waiting, review and recovery.

Reference documentation: Make webhooks · Scenario settings.

Inputs, outputs and reusable components

Scenario inputs and outputs define what information an automation receives and returns. They support subscenarios and expose functions to other systems, including agents. Blueprints preserve modules, settings and mapped values for design reuse or sharing.

A reusable component needs a comprehensible contract: required fields, formats, successful responses and error responses. For example, “find approved material” should return a reference and version, or clearly state that no valid match exists. It should not return a similar document as though it were the requested one.

When reusing a design, review connections, permissions and test data. Copying its structure does not establish that the new environment has the same fields or should apply the same rules. Keeping input and output examples makes handover easier.

Reference documentation: Scenario inputs and outputs · Scenario blueprints.

Make Grid and visibility across workflows

Make Grid generates a visual map of an automation environment and its relationships. It helps reveal connections between scenarios and applications beyond an individual workflow. The product introduction describes development from a closed beta announced in 2024 to a later open beta.

Use this view to distinguish technical dependencies from operational dependencies. Two scenarios may share an application while only one produces data required by the other. Reviewing the map can help identify what to check before changing a connection or retiring a resource.

Team documentation should add purpose, ownership and acceptance criteria. These elements support interpretation and maintenance priorities. Technical visibility becomes more useful when linked to process responsibilities and outcomes.

Reference documentation: Make Grid: visualising automation.

Maia and AI agents

Maia supports building and modifying automations through conversation inside the visual editor. Documentation also describes assistance with understanding or debugging existing scenarios. Make AI Agents includes agent execution and context management; provider and consumption options vary by connection and plan.

Design assistance and autonomous execution serve different purposes. A generated proposal may speed construction, but its logic needs review before activation. An agent interpreting text requires limits on available tools and permitted changes.

For a pilot, choose a bounded task, prepare examples with known answers and record ambiguous cases. Measure corrections and review time alongside construction time. A convincing output does not replace comparison with the expected outcome or establish suitability for sensitive information.

Reference documentation: Maia: conversational construction and maintenance · Make AI Agents app.

Credits, plans and cost estimation

On 27 August 2025, credits replaced operations as the billing unit. An operation still describes scenario activity. Many functions consume one credit per operation, but some AI capabilities have variable consumption; using a custom connection may add model-provider charges.

Plan comparisons should include execution frequency, volume, team functions and support. Dividing the monthly fee by the number of scenarios is insufficient. A list split into many items may multiply downstream module work.

For budgeting, measure a representative sample and separate receipt, transformation, writing and recovery. Include unmatched cases and repetitions. Cost per correctly resolved case is more useful than the cost of the first successful test.

Reference documentation: Transition to credits on 27 August 2025 · Make credits and connection types · Make pricing and plan comparison.

Security and data in execution logs

Make publishes information on SOC 2 Type II and SOC 3 audits, encryption and access controls. Its security page states thirty-day default log retention, with additional Enterprise options. These service characteristics should be checked against the contracted offering.

The confidentiality setting reduces information retained after processing. Official training warns that preventing input and output storage also limits the ability to save and recover failed executions. Privacy and diagnosis need to be addressed together, with an explicit decision about retained evidence.

For document processes, transporting references and statuses may suffice without copying complete documents. Define who may view histories, download designs and modify connections. Review example values before sharing a blueprint, since the design may contain information not intended for other teams.

Reference documentation: Security and compliance at Make · Incomplete executions and confidential data: Make Academy.

Supporting applications in OSH

As Sabentis editorial proposals, Make can coordinate repetitive tasks around prevention where the environment’s connectors and permissions support them:

• Preparing materials: classify requests by language and reference so that a person can select the approved version.
• Consolidating information: standardise fields from several records before preparing a report, retaining their source and date.
• Coordinating reviews: create internal tasks from a document review schedule, with an owner and document reference.

These proposals do not attribute professional OSH judgement to Make. Rules should transfer already defined decisions and expose cases that require human intervention.

Hypothetical example: preparing a campaign in three languages

A team receives internal requests for information sheets in Spanish, Catalan and English. It wants to organise preparation without confusing an available translation with an approved document.

1. Define an input containing request identifier, site, language and material code. Keep medical data and individual case files outside the process.
2. Validate fields and route each request to its language queue. Send an unknown language for review instead of automatically choosing another.
3. Create a task referencing the approved version and record its identifier in the original request.
4. Test an interruption between task creation and updating the source. Before retrying, look for the existing task to avoid duplication.
5. Reconcile received requests, created tasks and exceptions by language. An owner verifies the version and decides on distribution.

Acceptance requires an identifiable outcome for every request and no reference pointing to a draft. The number of executed modules does not replace this check.

Incomplete executions and recovery

Make can store incomplete executions, but this setting is disabled by default. Once enabled, stored cases can be resolved through supported retries or manual intervention. Storage capacity depends on the usage allowance.

Saving a failure is not the same as fixing it. Assign an owner to the exception queue, define a review deadline and determine which actions can safely be repeated without duplicates. Check connection expiry, field changes and expected volume as well. Retained debugging data may contain inputs; minimise them and restrict access.

Reference documentation: Incomplete executions.

Criteria for choosing Make

It is useful when visualising transformations and routes matters and someone can maintain them. Before choosing, evaluate connector availability, execution cost, recovery and how easily another person can understand the scenario using a real case.

Zapier provides another approach to connecting applications; n8n offers deployment options that may matter where in-house technical capability exists. The decision should include ongoing maintenance as well as initial setup speed.

Frequently asked questions about Make

Are all failures saved automatically?

Do not assume so. Storing incomplete executions requires activation and has limits. Check each scenario’s configuration.

Does a completed route mean the task is resolved?

It only confirms what that route executed. Verify the created record, its contents and acceptance of the outcome by the appropriate person.

What should be documented before handing over a scenario?

Inputs, outputs, identifiers, routing criteria, connections, ownership and recovery procedure. Include examples of valid data and rejected cases.

Reference documentation: Incomplete executions.