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.
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.
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:
- Salesforce: add items to the fetch->exclude->metadata list, as detailed in the adapter documentation
- Netsuite: add items to the fetch->exclude->types list, as detailed in the adapter documentation
- Zendesk: add items to the fetch->exclude list, as demonstrated in the adapter documentation
- Jira: add items to the fetch->exclude list, as demonstrated in the adapter documentation
After excluding them in the configuration file, re-fetch the environment to dismiss the original warnings.
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.
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
- Jira: add the fetch.fallbackToInternalId option to your environment or workspace configuration file, as detailed in the adapter documentation
Updated about 4 hours ago