Integration Lifecycle Management (ILM) overview

Integration Lifecycle Management (ILM) is integrator.io's version control and release management system for integrations. ILM lets you clone integrations, move updates from development to production with pulls and merges, and roll back with snapshots and reverts. integrator.io records each snapshot, pull, and revert as a revision. Its git-style features let you push, merge, and commit changes to an integration. Use ILM when you need to test changes before they reach production, collaborate across teams on the same integration, or maintain a reliable rollback point for mission-critical integrations.

Note: Non-production environments are recommended for ILM workflows. If you see Production and Sandbox in integrator.io, your account uses the legacy environment structure; see Legacy Production and Sandbox accounts.

Key concepts

• Revision — A revision is a versioned record of an integration's state, created automatically by integrator.io whenever you perform a snapshot, pull, or revert operation. Editing a flow or other resource doesn't create a revision on its own. Every revision has a unique ID and is saved indefinitely. You can revert to any Completed revision, regardless of its age. Failed and Canceled revisions can't be reverted to.
• Snapshot — A snapshot is a copy of an integration's state that you can create manually at any point as a backup. Use snapshots before making changes to a production integration, before you promote changes from another environment, or any time you want a restore point you can return to if something goes wrong. integrator.io also creates snapshots automatically before and after every completed pull and revert; see Create a snapshot.
• Clone — A clone is a copy of an integration, including its flows, steps, scripts, and configurations but not its connections, that you can modify without affecting the original. The clone keeps a direct relationship with its source, so you can pull changes between them. Cloning is the first step in a standard ILM workflow: you clone a production integration into a development or non-production environment, make and test changes in the clone, then pull those changes back into production. You clone the entire integration, not individual flows; see Clone an integration for Integration Lifecycle Management (ILM).
• Pull — A pull compares the changes in a remote integration against your current integration and merges them in. Pulls have four statuses: In progress, Completed, Failed, or Canceled. You can revert a completed pull to the integration's state before or after it; see Revert to a pull or previous revert revision.
• Revert — A revert rolls back an integration to a previous revision — a snapshot, a completed pull, or a completed revert. Like pulls, reverts have four statuses: In progress, Completed, Failed, or Canceled. A revert most commonly fails because the target revision contains deprecated features; see Failed revision status. Reverts are themselves revertable; see Revert to a pull or previous revert revision.
• Current and remote integrations — In an ILM pull workflow, the current integration is the one you're pulling changes into, and the remote integration is the one you're pulling changes from. In a standard workflow, the current integration is your production integration and the remote integration is a development clone. Which integration is current depends on where you start: the integration you open and create the pull from is always the current integration. Because of this, you can pull in either direction between an integration and its clone.

Revision tracking in ILM

ILM tracks changes through revisions. integrator.io creates a revision every time you perform a snapshot, pull, or revert on an integration. You can view, filter, and act on every revision from Revisions on the integration page.

Standard clone-and-pull workflow

A typical ILM workflow follows this pattern:

1. Clone the integration into a non-production environment to create an independent working copy. See Clone an integration for Integration Lifecycle Management (ILM).
2. Make and test changes in the clone.
3. Create a pull to compare the clone's changes against the production integration. See Pull changes from one integration to another.
4. Review the changes in the Review changes panel, resolve any conflicts, and merge the pull. See Review changes and Merge changes.

When the merge completes, integrator.io records a Completed pull revision that you can revert to. See Revert to a pull or previous revert revision.

Revision types

integrator.io creates three types of revisions:

Only one revision operation can run at a time. If a pull or revert is in progress, you can't start another until it completes or is canceled.

Example integration and clone setups

These diagrams show example ways to set up integrations and clones for ILM. For step-by-step setups, see Developing with integration lifecycle management.

Supported integrations and resources

You can use ILM with any custom integration you create or any template you install. ILM supports integrations that contain flows, APIs, tools, and topics. MCP servers aren't supported. You clone an integration with Clone integration, and you create snapshots, pulls, and reverts from Revisions on the integration page.

Integration apps don't have a formal backup feature. To learn how Celigo helps if you run into an issue with an integration app, see Back up an integration with a snapshot.

ILM operations work on an integration's configuration. A clone, pull, snapshot, or revert carries the resources and settings that define the integration, but not the runtime data, credentials, and environment-specific objects described below. Use this section to plan a clone or pull, and to check what to set up before you run flows in the integration that received the changes.

ILM supports the following resources:

• Flows
• Exports
• Webhooks
• Imports
• Scripts
• APIs
• Tools
• Lookup caches
• Topics

A pull carries every change to these resources, including resources added to the remote integration after the clone was created, except for fields on the current integration's ignore list. See Ignore fields during pull. A clone doesn't carry the original's revision history; the clone starts its own.

Lookup caches

ILM carries lookup cache references, mappings, and transformations, but never the data stored in a lookup cache. After every pull, merge, or revert, repopulate (or re-upload) the lookup cache data before you run any flows. When an operation introduces a new lookup cache, also validate the lookup cache manually in both the current and remote integrations before you run any flows.

• Cache references, mappings, and transformations — Carried by clone, pull, merge, snapshot, and revert. A lookup cache added to the remote integration after the clone was created is a new resource, and the pull creates a corresponding empty lookup cache.
• Cache data in a pull, merge, snapshot, or revert — Not carried. ILM never saves lookup cache data in any revision, new or existing. If you revert to a snapshot taken before a lookup cache was deleted, an empty lookup cache is created.
• Cache data in a clone — Carried only when you clone into the same environment, Include data when lookup cache is cloned or downloaded is selected on the lookup cache, and the total size of all lookup caches is under 5 MB. Otherwise, the clone contains the lookup cache with no entries, which you populate before you run any flows. In the same environment, you can reuse an existing lookup cache instead of cloning it.

See Clone an integration for Integration Lifecycle Management (ILM) and Ignore fields during pull.

Topics

ILM carries a topic's configuration (name, description, and retention), but never its retained messages or subscription positions (where each subscription resumes reading). Topic configuration changes appear in the Review changes panel during a pull or revert; retained messages don't.

• Topics in the same environment — A clone reuses the topic the original step points at. It never creates a second topic. To publish to a separate topic, open the cloned step and create a new topic from the topic picker.
• Topics in a different environment — The first clone or pull into an environment creates the topic there and registers it to the integration. Publish steps and subscriptions (Listen for messages from a topic steps) point to it with no further setup. Later pulls reuse that topic and apply any configuration changes.
• Topic limit — A pull, or a clone into a different environment, fails before any changes are applied if creating its topics would put the target account over its topic limit. Topics that already exist in the target environment don't count toward the limit. See A pull or clone fails because of the topic limit.
• Topics in a snapshot or revert — A snapshot includes topic configuration. A revert restores it, but doesn't restore messages or change where a subscription resumes. If a step's topic no longer exists, the revert fails.
• Retained messages and subscription positions — Never carried by clones, pulls, or reverts. Subscriptions in a clone start with no saved position, and Start from is set to its default. To process messages already in the topic, set Start from to All retained messages before you turn the flow on for the first time, or replay messages after.

See Topics overview.

Connections

ILM doesn't copy connections. You configure them when you set up a clone, in the Merge changes panel before a pull merges, and in the Revert changes panel before a revert runs.

• Connections in a clone, same environment — Not copied. integrator.io preselects the connection used in the original flows. Confirm or change each connection when you configure the clone.
• Connections in a clone, different environment — Not copied. Select an existing connection in the target environment, or create a new one.
• New connections in a pull — Not copied. Each new connection appears as a numbered step in the Merge changes panel, with Configure, and Merge stays disabled until you complete it. Select Configure and set up the connection, then select Merge.
• Connections in a revert — The revert adds or removes connections to match the revision you revert to. Any connection that needs setup appears as a step in the Revert changes panel. Configure the connection there, then select Revert.

See Merge changes and Revert changes.

Important: When you configure a clone, set up a separate, distinct connection for each connection in the original integration. Don't reuse one connection for more than one original connection. If two original connections share one connection in the clone and the original integration later removes one of them, a pull from the original fails at merge. See Troubleshoot ILM revision and pull issues.

Webhook credentials

ILM doesn't carry the credentials of a webhook with authentication. When you create a pull or revert for an integration that contains one, open the webhook and enter the credential for its verification type the first time. After that, you don't need to enter it again unless it changes.

• Basic — Enter the Password.
• HMAC — Enter the Key (secret).
• Secret URL — Enter the Custom URL token.
• Token — Enter the Token.
• Key (secret) — Enter the Key (secret).

ILM use cases

Use ILM when:

• You need to test integration changes before they reach production.
• Multiple developers or teams are working on the same integration and need to coordinate changes.
• You're maintaining a mission-critical integration where an unexpected change carries significant business risk.
• You want a reliable rollback point before making major changes to a live integration.
• Your organization follows a software development lifecycle with distinct development, QA, and production stages.

Don't use ILM when:

• You're the only developer on a simple integration that changes rarely. Cloning and pulling can add more overhead than value. Create snapshots before each change instead.

Related articles

• Integration Lifecycle terminology
• View and filter revisions
• Developing with integration lifecycle management
• Clone an integration for Integration Lifecycle Management (ILM)
• Back up an integration with a snapshot
• Pull changes from one integration to another
• Best practices for Integration Lifecycle Management (ILM)
• Revert changes
• Ignore fields during pull
• Review changes panel reference
• Troubleshoot ILM revision and pull issues
• Manage user roles & permissions to an account