A pull revision lets you bring changes from one integration into a directly related clone — for example, promoting tested changes from a Sandbox integration to Production. This article covers how to create a pull, manage conflicts, and troubleshoot unexpected behavior in the Review Changes panel.
Note
You need Manage access or above on the target environment to create a pull revision.
To create changes, you must clone your integration into the same or another environment and change either your remote or current integration. You can change exports, imports, connections, scripts, or flows. Just remember, for revisions specifically, cloning is done at the integration level, not the flow level. You can't clone one flow; you must clone the entire integration. This doesn't mean that you can't change a flow. It means you must clone the entire integration to manage or test a flow using Integration Lifecycle Management.
Tip
-
You can revert to an integration state within a completed pull revision in your revision history at any time.
-
You can pull from an original integration to a clone (or vice versa). The examples below will work for both.
Pulling or fetching changes lets you compare one directly related integration to another. You can pull data only from a direct clone or source integration. For example, clone your Original integration into Clone A, then A to B, B to C, and B to D. You can create a pull between integrations A and B, B and C, B and D; but not between A and C, or A and D.
Warning
You can't change both related integrations (Original and Clone A) and merge your changes. If you do, your future merge will fail. Only make changes to one integration at a time.
The pull functionality in Integration Lifecycle Management (ILM) supports real-time exports with authentication. When you create a pull or revert for an integration containing a real-time export with authentication, you must authenticate it the first time. Enter the authentication credentials in the real-time export, created due to pull or revert, based on the type of verification used:
-
When the Verification type is
-
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).
-
After this, you don't have to enter the authentication credentials unless the credentials are changed.
Warning
-
This action may cause a conflict between your integrations. You cannot continue a pull without resolving conflicts.
-
Any modified references (imports, exports, etc.) affect all integrations and flows. If you modify a reference, you must check your References to ensure that you aren't modifying anything in a different integration.
-
Any changes made after you start a pull are not included in the pull request. You'll need to make a second pull to include any changes made after the first.
-
Lookup cache data is not stored or managed in Integration Lifecycle Management (ILM). Although references to the lookup cache are included (like in mappings and transformations), ILM does not support lookup cache data.
To pull changes from one integration to another:
-
Select Revisions > Create Pull to begin pulling changes from the remote integration to your current integration.
-
Add a pull description. You can pull your integration into your clones (or vice versa) one at a time in any order.
-
Environment: Select your environment. Only active environments you have Manage access to (or above) are visible. After cloning to a new environment, you must complete the setup steps; however, you can choose to complete the setup later. Learn how to use multiple environments.
-
Integration (required): Select the integration from which you'd like to pull changes.
-
Review changes between your original and clone integrations. They can sometimes include new resources like exports, imports, and scripts.
Warning
You may have conflicts if you changed each clone individually. Review and fix any outstanding issues before completing your pull to resolve conflicts.
-
Select Next to approve and merge the changes. You can review your pull at any time in the Revisions tab.
A broken component ID linkage between Sandbox and Production can cause the Review Changes panel to show existing components as Action: Removed and Action: New instead of Action: Update during a pull revision. This typically appears when pulling changes from Sandbox to Production — existing exports, imports, or flows are listed twice: once as Action: Removed and again as Action: New (or as Action: Deleted paired with Action: New for flows) — rather than the expected single Action: Update entry.
This is different from components that were intentionally deleted or added. If you see the same component name appearing as both Removed and New in the same pull preview, that is the signal that something has gone wrong.
This typically happens when multiple significant structural changes are made in the Sandbox integration between pull revisions — such as renaming exports or imports, recreating components, or making several large changes at once. After enough changes accumulate, the platform loses the ID-to-ID mapping between the Sandbox and Production components.
Do not proceed with a pull that shows this pattern. Continuing may delete flows, create duplicates, and leave your Production integration in an inconsistent state that is difficult to recover from.
-
Stop and do not delete your existing Production integration. It may share components with other integrations or clones. Deleting it prematurely can cause additional data loss.
-
Create a fresh clone of your Sandbox integration into the Production environment.
-
Test the new clone by making a minor change in Sandbox and pulling to the new clone. Confirm the pull preview shows Action: Update — not Removed/New — before proceeding.
-
Use the new clone as your Production integration going forward.
Important
Re-cloning resets the integration's revision history in the target environment. Previous revision history will not carry over to the new clone.
Make small, incremental changes in your Sandbox integration between pull revisions. Avoid making multiple large or structural changes — renaming, recreating, or significantly modifying several exports, imports, or flows at once — before pulling. Smaller, more frequent pulls reduce the risk of ID mapping issues.
In this example, you are pulling from a Development (Dev) clone, Quality Assurance (QA) clone, and Dev+QA clone to update your original integration. Your clones are daisy-chained, meaning that the Dev+QA clone is created from the original integration, the QA clone is created from the Dev+QA clone, and the Dev clone is created from the QA clone.
After you've tested your changes in the Dev clone, pull to QA and then Dev+QA. You may run into similar merge conflicts since your clones should be identical.
Legacy production and sandbox licenses
In legacy Production and Sandbox environments, changes in one environment affect both environments. The Production and Sandbox environments share the same underlying resources. Any resource you create, edit, or delete in one environment is immediately reflected in the other.
This includes connections, imports, exports, flows, scripts, and API tokens. Use caution when editing resources in either environment.
This behavior doesn't apply to accounts on the multi-environment license, where each environment maintains its own isolated resources.
Migrations from the legacy Production/Sandbox license to the new multi-environment license are underway. Your account has not migrated to the new multi-environment license if you can toggle between environments.
Below are various examples:
In this example, you're creating a development environment, creating an integration and flows, cloning the integration into Prod, and pulling changes from development to Prod.
-
Create your non-production environment as referenced above. In this example, we've created a Development (Dev) environment. Now you have your original Production environment and your newly created Dev environment for a total of two environments.
-
Create an integration and create your flows in your new, non-production environment. In this example, it's a development integration in the Dev environment.
-
After you've developed your integration, you can clone it into your Production environment. Remember, for ILM specifically, you cannot clone a single flow. You must clone the entire integration.
-
Pull your changes from your Dev environment to your Production environment.
In this example, you're creating a development and QA environment, creating an integration and flows in Dev, cloning the integration into QA, cloning the integration from QA to Prod, and pulling changes from development to QA, then Prod.
-
Create your non-production environment as referenced above. In this example, we've created a Dev and QA environment. Now you have your original Production environment and your newly created Dev and QA environments for a total of three environments.
-
Create an integration and create your flows in your new, non-production environment. In this example, it's a development integration in the Dev environment.
-
After you've developed your integration, you can clone it into your QA environment. Remember, for ILM specifically, you cannot clone a singular flow. You must clone the entire integration.
Then, clone your QA integration into your Prod environment. Now you have a daisy-chained integration and can make changes from Dev to QA and QA to Prod. You cannot pull from Dev directly to Prod.
Important
If you clone your integration from Dev directly to Prod, you won't be able to create the daisy-chained development lifecycle later by adding a second non-production environment. If you clone from Dev to Prod, you can't add a QA environment and integration later and move changes from Dev to QA to Prod since the clones will be distinct.
-
Pull your changes from your Dev environment to your QA environment.
Then, pull from QA to Prod.