Pull changes from one integration to another

In Integration Lifecycle Management (ILM), a pull revision promotes tested changes from one integration into a directly related clone — for example, from a development integration into Production. This article is for integration builders who move changes between clones or environments. Use a pull to promote changes through your environments, keep clones in sync, or incorporate changes made in one clone into another. The process has three stages: create the pull, review the changes in the Review changes panel, and merge. This article also covers how to identify and resolve conflicts when they arise during review.

Prerequisites

Permission: You have Manage access to the integration in both environments, or you're an account owner or administrator. See Manage user roles & permissions to an account.

Before you begin, confirm the following:

For the integrations and resources a pull supports, see Supported integrations and resources.

Create a pull

1. Select an environment at the top of the page.
2. Go to Home, and then open the integration you want to pull changes into (your current integration).

3. Select Revisions > Create pull.

   

4. In the Create pull panel, complete these required settings:
   1. Description — Enter a pull description.
   2. Environment — Select the environment that contains the integration you're pulling changes from.
   3. Integration — Select the integration you want to pull changes from (your remote integration).

Note: You can pull from an original integration to a clone, or from a clone to its original.

Note: If your integration contains an API and you pull across environments, add version to the ignore list in Ignore fields during pull first; see API version difference blocks a pull.

Note: When you create a pull for an integration that contains a real-time export with authentication, you enter its credentials the first time. See Webhook credentials.

Review changes

The Review changes panel lists every resource affected by the pull — for example, integrations, flows, exports, imports, scripts, APIs, and tools — grouped by resource type. Each resource shows an Action label that indicates whether it will be updated, added, or removed when the merge completes, and a diff that shows the Before pull and After pull versions side by side.

1. Check the conflict count at the top of the panel. If it isn't 0 conflicts, resolve the conflicts before you continue.
2. Expand each resource to see the specific fields that changed, and confirm every change is expected.
3. Check the References list to see which other integrations and flows use the shared resources in this pull. A change to a shared resource applies everywhere it's used; see References.

If a resource you expected as Action: Update appears as Action: Removed and Action: New, don't continue; it isn't a conflict you can resolve. See Unexpected Removed and New actions in Review changes.

For a full explanation of action labels, panel features, and script behavior, see Review changes panel reference.

Note: To include changes made after you created the pull, select the refresh icon before you merge; see Refresh.

Resolve conflicts

A conflict occurs when the same resource has been modified in both the current and remote integration since the last pull. The conflict count at the top of the Review changes panel shows how many conflicts remain, and you can't continue to the merge until it shows 0 conflicts.

What causes a conflict

• Mismatched resource names — an export, import, flow, or script has been renamed in one integration but not the other (for example, "Get Amazon sales" in one and "Get sales from Amazon" in the other).
• Conflicting hook edits — the same hook has been edited on the same line in both integrations.
• A resource removed in one integration and replaced in the other — for example, the remote integration removed an import and the current integration replaced the same import. See Resource removed in Remote and replaced in Current for how to resolve this conflict.

Conflicts are most common when multiple users are working on the same integration across different clones without coordinating changes.

Resolve a conflict

You can't resolve conflicts from within the Review changes panel. You must edit one of the two integrations so that the conflicting field matches the other, then return to the pull.

1. Note the resource and field causing the conflict — for example, a renamed export.
2. Decide which version is correct — the current integration or the remote integration.
3. Open the integration that needs to be updated and edit the conflicting field to match the other integration.

4. Return to the pull and select the refresh icon next to the conflict count in the Review changes panel to reload the diff.

   The conflict count returns to 0 conflicts when the conflicting fields match. If the conflict still appears, confirm the edit was saved and refresh again.

5. When the panel shows 0 conflicts, continue to Merge changes.

Note: For hook conflicts (the same line edited in both integrations), decide which edit should take precedence, update the hook in one integration to match the other, and refresh the panel.

Note: To avoid conflicts when working with a team, establish pull and merge guidelines before onboarding collaborators. See Best practices for Integration Lifecycle Management (ILM) for recommendations.

Merge changes

Merging is the final step of a pull: it applies the reviewed changes from your remote integration to your current integration. In ILM, a merge completes a pull; it isn't the create-or-update behavior of an import. If the pull adds new connections or installation bundles, you configure them in the Merge changes panel before the merge can complete.

Note: Only one revision operation can run at a time. See Revision types.

Merge a pull without new connections

Use this path when your pull doesn't include any new connections or installation bundles.

1. In the Review changes panel, confirm that all listed changes are correct and that the panel shows 0 conflicts.
2. Select Next. integrator.io merges the changes directly.

The pull appears in Revisions with a Completed status.

Merge a pull with new connections or an installation bundle

Use this path when your pull includes a new connection that doesn't exist in the current integration, or a new connection that requires an installation bundle — for example, a NetSuite bundle or a Salesforce package. A new import that uses a new connection adds a connection step to the merge.

1. In the Review changes panel, confirm that all listed changes are correct and select Next.

   The Merge changes panel opens and lists numbered steps.

2. If the merge includes an installation bundle, complete the steps to install it.
3. For each new connection step, select Configure and configure the connection.
4. On the final Merge changes step, select Merge. Merge stays disabled until all earlier steps are complete.

The pull appears in Revisions with a Completed status.

After you merge

Note: To roll back a completed pull, see Revert to a pull or previous revert revision.

Note: If the merge is unsuccessful, a notification appears and you can retry. Retrying is supported even when the failure occurred during resource addition or bundle configuration.

To retry an unsuccessful merge, select Actions (...) on the pull row in Revisions, and then select Resume operation.

Cancel or pause a merge

• To cancel the merge, select Cancel merge in the Merge changes panel. If you already closed the panel, select Actions (...) on the in-progress pull row in Revisions, and then select Cancel revision.
• To leave the merge in progress and resume it later, select Close. Closing the panel doesn't cancel the merge. To resume, select Actions (...) on the in-progress pull row in Revisions, and then select Resume operation.

Note: If you cancel the merge after a new connection has been added, the connection isn't deleted. To finish configuring connections later without canceling, select Close instead of Cancel merge.

Note: A canceled merge appears in Revisions with a Canceled status, along with its description, the date it was created, and the name of the user who created it.

Notes and constraints

• Lookup cache data isn't managed by ILM. After a pull and merge, repopulate lookup cache data before you run any flows; see Lookup caches.
• Topics. A pull carries topic configuration but never retained messages or subscription positions; see Topics. A pull that would put the target account over its topic limit fails before any changes are applied; see A pull or clone fails because of the topic limit.
• Pull relationships are direct only. You can pull only between directly related integrations. For example, if you clone Original to create A, clone A to create B, and clone B to create C, you can pull between Original and A, A and B, or B and C — but not between Original and B, or Original and C.

To plan pulls across Development, QA, and Production, see Developing with integration lifecycle management.

Related articles

• Review changes panel reference
• Clone an integration for Integration Lifecycle Management (ILM)
• Ignore fields during pull
• View and filter revisions
• Revert changes
• Troubleshoot ILM revision and pull issues
• Developing with integration lifecycle management
• Best practices for Integration Lifecycle Management (ILM)
• Integration Lifecycle Management (ILM) overview