To create changes, you simply have to clone your integration and make changes to either your remote or current integration. You can make changes to 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 have to clone the entire integration. This doesn't mean that you can't change a flow. It just means that if you want to manage or test a flow using Integration Lifecycle Management, you must clone the entire integration.
- Learn about Integration Lifecycle Management
- Manage integration lifecycles
Note: You can revert to an integration state within a completed pull revision in your revision history at any time.
Tip: 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 C and D.
Important: You can't make changes to both related integrations (Original and Clone A) and merge your changes. If you make changes to both, your future merge will fail. Only make changes to one integration at a time.
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.
- When the Verification type is HMAC, enter the Key (secret).
- When the Verification type is Secret URL, enter the Custom URL token.
- When the Verification type is Token, enter the Token.
- When the Verification type is Key (secret), enter the Key (secret).
After this, you don't have to enter the authentication credentials, unless the credentials are changed.
Imagine that you changed an integration and need to pull the changes into your clone. Note that you can also pull changes from a clone into an integration. The process is fairly straightforward:
- This action may cause a conflict between your integrations. You cannot continue a pull without resolving conflicts.
- Any modified references (imports, exports, etc.) are changed for 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.
- Navigate to your original integration and create a pull.
- Click Revisions → Create Pull to begin pulling changes from the remote integration to your current integration.
- Add a description of your pull and select your integration from the list. You can pull your integration into your clones (or vice versa) one at a time in any order.
Review changes between your original and clone integrations. They can sometimes include new resources like exports, imports, and scripts.
- You may have conflicts if you made changes to each clone individually. Review and fix any outstanding issues before completing your pull to resolve your 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.