Common Salto ID Issues

Omitted instances due to Salto ID collisions

During an environment or workspace fetch, you may get a warning such as "Omitted 2 instances of ticket_field due to Salto ID collisions.". This message indicates that some instances were not fetched due to Salto ID or name collisions.

Salto IDs are individually generated for each SaaS element type, according to its own adapter logic. For example, Zendesk User Fields' Salto IDs are generated according to their unique Zendesk "field key". To view elements' Salto IDs, click "Copy Element ID" when viewing a Salto element.


The "omitted instances" message indicates multiple SaaS elements have the same calculated Salto ID, and therefore were not fetched, as Salto could not generate a unique identifier for each one.

The adapter-specific message will include:

  • The calculated colliding IDs
  • For each ID, the message may also indicate the exact instances that were omitted and their application-side URL
  • Adapter specific solutions to the issue

When this error occurs, the colliding elements will not be fetched. You will not be able to audit or deploy them, and they will not appear in any searches or as dependencies of other objects.

Possible Solutions

Remove or edit colliding instances in the Business Application

The best solution in these cases would be to resolve the collision on the Business Application side: go to the colliding objects, and change their name (or any other field that participates in the ID calculation for that type). You can see which fields are part of the key calculation in the error message itself.

After changing this on the business application side, re-fetch the environment or workspace and observe that new instances were fetched and the previous error message does not appear again.

Excluding colliding items

If the colliding instances are simply not needed in Salto, you can exclude them in your NACL configuration file, in order to stop getting these errors.

In order to exclude specific items, follow these instructions according to the affected application:

After excluding them in the configuration file, re-fetch the environment to dismiss the original warnings.

Changing the ID Key criteria

If fixing this problem on the business application side isn't possible, but there is a different set of instance fields that is unique, sometimes you can change the key calculation settings in the application connection configuration. After changing these settings, re-fetch the workspace or environment to get the new instances. Note that previous instances of the same type that were already successfully fetched (as they did not collide with each other) will have the previously calculated ID.

In order to change this key, follow these instructions according to the affected application:

  • Salesforce: use the data->saltoIDSettings configuration, as detailed in the adapter documentation
  • Other applications: use the apiDefinitions->types->macro->transformation->idFields configuration. Contact Salto Support at [email protected] for usage examples.

In workspaces, do this change in the application's configuration file.
In environments, make sure you change this setting in all relevant environments, so that deployments between them will work reliably.

After making these changes in the configuration file, re-fetch the environment.

Adding Salto's Internal ID to the element name

When using Jira, you can configure Salto to add an internal ID to duplicated elements to make them unique. After changing these settings, re-fetch the environment to get the new instances.
This solution will prevent reliably deploying elements between two environments, as the same element may get 2 different IDs in the source and target environment

Did this page help you?