Articles in this section

Review changes within a pull or revert

When you want to pull or revert an integration, you must review any changes between your current and remote versions. Various features, including references, difference (diff) screens, and conflicts, help you analyze how your changes affect your integration.

Review Changes is supported for integrations that contain flows, tools, and APIs.

Note

You need Manage access or above to review changes within a pull or revert.

Review changes

The Review Changes screen displays all differences between your current and remote integration. Use the features below to analyze changes, identify conflicts, and prepare for the merge.

Conflicts

Conflicts arise when identical resources are modified between the current and remote integration. You'll run into a conflict if:

  • The resource names don't match:

    • Get Amazon sales vs Get sales from Amazon

  • The same hook has edits on the same line.

Conflicts can be introduced when multiple users are working on the same integrations. To resolve them, edit either one of the integrations to match the other, then merge and pull.

Name_change_conflict.png

Refresh refresh.svg

You can use Refresh to review any changes to your integration in real time. The refresh button works best if you're using two integrator.io webpages; one for editing and making changes to an integration and the other for reviewing merge data in real-time. This way, you can update an integration and see its effects on your merge.

Expand all Expand.svg

Select Expand all to open every resource section at once, so you can scan all pending changes without expanding each item individually.

References reference_button.svg

This list displays all the flows containing a reference in your account. For example, an export (Export all Salesforce leads) could be used in multiple integrations, like Salesforce – NetSuite and Salesforce – Acumatica.

Important

Any modified references (such as imports and exports) are changed for all integrations and flows. If you modify a reference you must check this to ensure that it isn't modifying anything in a different integration.

Manage resources

The Review Changes screen lists every export, import, flow, API, tool, and script affected by your pull or revert, grouped by resource type, with an Action label indicating whether each will be updated, added, or removed.

Warning

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.

lookup_cache_reference_in_data.png
lookup_cache_ILM_mapping.png

Important

In your JSON data, imports (including lookups) and exports are called pageProcessors and pageGenerators (PP and PG), respectively. This applies if you are inspecting the raw JSON diff — most builders can ignore this.

Warning

Modifying a resource in one integration will modify it throughout all your integrations. When your open a shared resource to edit it, a Proceed with caution banner appears at the top of the editor showing how many places use it. Click Used by in the banner to review all references before saving changes.

reuse_resources_UI_msg.png

Review API changes

When a pull or revert diff includes API changes, an APIs section appears in the Review Changes panel. Each API entry shows field-level diffs — individual fields are highlighted as added, updated, or removed, rather than showing the entire API as a delete-and-add pair.

Note

If a pull or revert would introduce a route, method, and version combination that already exists in the destination integration, integrator.io automatically increments the API version (for example, v1 becomes v1.1) to avoid a conflict.

Note

Known limitation: When pulling from a Production environment to Sandbox, the Review Changes panel may show an API version change even if no API changes were made. This causes the pull to fail at merge. To work around this, use ILM Ignore to ignore the version field on the affected API before completing the pull. See Ignore resource fields in a pull for instructions.

Update an existing resource

This change includes an update to an export. The method was changed to POST and the relative URI was changed.

Change_to_export.png

Add a new resource and delete an existing resource

This change includes a new export and a deleted export.

New_import.png
removed_export.png

New, modified, and deleted resources

This change includes new, modified, and deleted resources. Notice that the Action is available for each change (removed, update, new).

If components you expect to see as Action: Update appear as Action: Removed and Action: New instead, see Troubleshooting in Pull changes from one integration to another.

multiple_changes.png

Delete a resource shared with multiple flows and integrations

In this situation, you're deleting an export shared between multiple flows. Exports are not linked to a single integration since they can simultaneously be used in multiple integrations. If an export is removed from a flow, it won't be deleted from your account. Instead, references to it in the flow are removed. Always check your references to ensure you're not deleting or editing a resource used in multiple flows or integrations.

used_by_other_integrations.png
Used_by_in_this_integration.png

Manage scripts

Scripts are commonly used in multiple integrations at once. If a script is removed from a flow, it won't be deleted from your account. Instead, references to it in the flow are removed.

Warning

Modifying a script in one integration will modify it throughout all the integrations you use. When your open a shared resource to edit it, a Proceed with caution banner appears at the top of the editor showing how many places use it. Click Used by in the banner to review all references before saving changes.

Remove an existing script from a flow

In this example, you've removed an existing script from a current integration and then you're pulling the changes. The script isn't deleted from your entire account, but it is deleted from the flow.

  1. Navigate to the hook you want to delete from your flow.

  2. Select your script, then select None.

    remove_hook_click_none.png
  3. Save the hook.

  4. Create a pull from the remote integration to your current integration.

  5. Verify that the script has been deleted.

    Hook_delete.png

Modify and delete multiple scripts

In this situation, you've modified, and then deleted, an existing script and modified a second script in a different flow. It's important to remember that this script is not going to be permanently deleted from your account. Instead, you've deleted it from your flow and modified it in another.

The first script you modified and then deleted is highlighted in red to show that it was removed from your flow.

Hook_delete.png

The deleted changes in your second script are highlighted in red, and the updates are highlighted in green.

Update_script.png

Troubleshooting

Review Changes shows unexpected "Removed" and "New" actions

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.

What causes this

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.

What to do

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.

  1. 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.

  2. Create a fresh clone of your Sandbox integration into the Production environment.

  3. 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.

  4. 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.

How to prevent this

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.

Pull shows a conflict when the same resource is changed in both integrations

A conflict occurs when your current and remote integrations have both made changes to the same resource. For example, if the remote integration removed an import and the current integration replaced the same import, the pull can't resolve the mismatch automatically and surfaces a conflict.

In the Review Changes panel, you'll see the same resource listed with different actions on each side — for example, removed in Remote and replaced in Current.

How to read the conflict UI

In the Review Changes panel:

  • Current = the integration you are pulling into

  • Remote = the integration you are pulling from

If the same resource shows as removed in Remote and replaced in Current, that mismatch is the source of the conflict.

To resolve this conflict

  1. In the current integration, remove the import that appears as "replaced" in the diff. This makes both integrations consistent.

  2. Pull from the remote integration again. The pull should complete without conflicts.

Note

Adding the import back on the remote integration to match the current integration is not recommended. Fix on the current side.

Merge fails after pull with a connection error

A connection linkage conflict occurs when a clone was installed with two remote connections mapped to the same current connection, creating a one-to-many linkage. If the remote integration later removes one of those connections, the pull fails at merge with the message: The merge of your pull was unsuccessful. Try your pull again.

Note

This issue may not be visible during the Review Changes step. The merge failure occurs after you attempt to complete the pull.

To prevent this issue

When installing a clone, configure a separate, distinct connection for each remote connection. Do not reuse the same connection for more than one remote connection.

To resolve this conflict

  1. In the current integration, find the import step that still references the connection being removed.

  2. Replace that connection with a new or correct connection.

  3. In the remote integration, select Revisions > Create Pull and select the current integration as the source. This reverses the pull direction to bring your connection fix back into the remote.

  4. In Review Changes, confirm that the removed export and its old connection no longer appear, and that the import step references the new connection.

  5. On the connection install step, select the intended connection.

  6. Complete the merge.

  7. To align both sides, run Create Pull from the current integration back to the remote integration. This ensures connection linkages are consistent for future pulls.