Omitted instances due to Salto ID collisions
During an environment 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 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
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).
After changing this on the business application side, re-fetch the environment 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 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, you'll need to change your environment NACL configuration. Follow these instructions according to the affected application:
Salesforce: use the data->saltoIDSettings configuration, as detailed in the adapter documentation
Jira & Zendesk: use the apiDefinitions->types->[type name]->transformation->idFields configuration
Other Adapters: use fetch->elemID configuration , as detailed for example in the Okta documentation page
You can always contact Salto Support with the "Help" button, or at support@salto.io, to get assistance with setting this up.
Make sure you change this setting in all the relevant environment configuration files, 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 configuration file, as detailed in the adapter documentation