Use cloning to speed up the process of creating integrations and managing changes. You can clone an existing integration to create an exact copy, make changes in the source integrations, and systematically pull the new 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 access level (Manage or Monitor). Then, users with Manage access can create clones.
-
Avoid independently cloning integration resources (like lookup caches, exports, or imports) and reusing them within the same integration, as it can lead to inconsistencies with 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.
If you have access to the sandbox environment, create an integration in the sandbox first. Then, create a clone in the production environment. When you introduce new changes, make them in the sandbox integration and, once everything is working as expected, pull the newly tested changes into the production integration.
Approach: Original integration (sandbox environment) → Integration A, a clone of the original integration (production environment) Example: Amazon-NetSuite (sandbox environment) → Clone of Amazon-NetSuite (production environment)
You can extend the above concepts to manage work across multiple teams and environments.
Tip
Provide Manage access only to Developers in Dev tiles and Manage access to QA only in QA tiles.
You can separate work according to your development and test teams. Simply create clones of each integration and provide access to the cloned tiles based on dev and test teams. When development work is finished, changes can be pulled in for testing by the QA team and, when everything is working, 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 on, other developers can pull from the original integration to incorporate the new changes into their own clones.
You can further separate work across different environments and make changes in both 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.