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 deploy them or document related changes, 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:
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.
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->[type name]->transformation->idFields configuration. Contact Salto Support at support@salto.io 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
Jira: add the fetch.fallbackToInternalId option to your environment or workspace configuration file, as detailed in the adapter documentation