Use cloning to speed up integration creation and change management. You can clone an existing integration to create an exact copy, make changes in the source integration, and systematically pull the changes into the cloned integration, or vice versa. Snapshots are automatically created whenever you merge changes, which helps you return to a previous state if you want to revert your changes.
Tip
-
To use ILM, you need to clone an entire integration, which requires 'Manage' access to the integration. Ideally, you should create integrations with 'Administer' access and invite users to the integration based on their access level (Manage or Monitor). Then, users with Manage access can create clones.
-
Avoid independently cloning integration resources (such as lookup caches, exports, or imports) and reusing them within the same integration, as this can lead to inconsistencies across revisions.
Imagine your original integration is running in production. You can create a clone (integration A) (Amazon-NetSuite → Clone of Amazon-NetSuite). In this case, integration A is the clone integration and original is the source. You can keep the two integrations in sync or introduce new changes in the source and then pull the new changes into your clone or vice versa.
You have now recreated several flows, steps, scripts, and configurations. Everything is copied. Now, to introduce a new change, use the source integration, test everything, and merge new changes to integration A using a pull request.
Approach: Original integration → Integration A clone of the original integration Example: Amazon-NetSuite → Clone of Amazon-NetSuite
You can also create multiple clones of the original integration. This is helpful when you want to create and maintain a large number of integrations based on a common source integration. In this case, you can introduce changes in the source integration and then pull changes into any of the clones.
Tip
Don't forget to repopulate the lookup cache data after reverts.
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 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.
You can extend the above concepts to manage work across multiple teams, even if you don't have a legacy sandbox or multi-environment license.
You can further separate work across different environments and make changes in both the sandbox and production environments. In your sandbox, you can develop your integrations, test any changes, and pull those stable changes into your production integration.
Tip
Use the sandbox environment to create Dev tiles and QA tiles and the Production environment to create Prod tile.
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.
Tip
Provide Manage access only to Developers in Dev tiles and Manage access to QA only in QA tiles.
You can separate work into development and QA teams by creating clones of each integration and granting the Dev and QA teams access to the cloned tiles. When development work is complete, the QA team can pull in changes for testing, and once everything is working, the final changes can be pulled into the original integration.
You can also manage development by assigning a clone to each developer for independent development. Whenever a developer completes a task, the changes can be pulled into the original integration. Later, other developers can pull from the original integration to incorporate the changes into their own clones.