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 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.
Imagine you changed an integration and must pull the changes into your clone or vice versa. The process is relatively straightforward:
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.
-
Click 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 more about using multiple environments.
Warning
This feature will be available after the 2025.1.1 release in new accounts or accounts that haven't previously used the Sandbox feature. Creating multiple environments in existing accounts already using the Sandbox feature will be available in March 2025.
-
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.
-
Click Next to approve and merge the changes. You can review your pull at any time in the Revisions tab.
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.
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 environment. Now you have your original Production environment and your newly created Development 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 Development environment.
-
After you've developed your integration, you can clone it into your Production environment. Remember, for ILM specifically, you cannot clone a singular flow. You must clone the entire integration.
-
Pull your changes from your Development 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 Development and QA environment. Now you have your original Production environment and your newly created Development 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 Development 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 Development 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 Development environment to your QA environment.
Then, pull from QA to Prod.
Comments
There literally is a "Clone flow" feature, I use it all the time
Hi Geoff Tipley,
Just to clarify, do you have the ability to clone a flow and then use it in revisions? This information on cloning at the integration level is specific to Integration Lifecycle Management (ILM). You do have the ability to clone a flow, but you can't use revisions for a standalone cloned flow. That is to say, in the Revisions tab, you can't clone or otherwise modify a single flow. I've posed this question to the PM responsible for this feature, but I wanted to clarify with you as well.
Thanks!
Please sign in to leave a comment.