Each configuration element has unique identifier which is determined by its application. In Salto’s language, this identifier is known as the
Service ID. This ID is crucial in the context of a Salto environment, particularly when fetching configurations. For example, if a Salesforce configuration element is updated, Salto utilizes the element’s
Service ID to ensures that the correct element is updated. Similarly, during deployments, the
Service ID is the definitive reference, guiding which updates are deployed to the applications.
A key Salto use case is ability to compare and align configuration elements across multiple environments. Salto can deduce that element
x in one environment should be compared to element
x in another environment only if the ID of both of these elements is identical. In cases where the elements’
Service ID is consistent across environments, such as with Salesforce’s API names or NetSuite script IDs, everything works well. However, there are cases where the
Service ID may change only within a specific environment. To overcome this
Service ID limitation, Salto relies on its own ID, known as
Salto ID. Typically the
Salto ID inherits its value from the
Service ID, except for the ‘problematic cases’ (when a consistent cross environment ID is not available) where the
Salto ID anchor itself to changeable attributes, like an element’s name or title.
Salto IDs on changeable attributes, such as an element’s name or title, can introduce unique challenges. While Salto relies on the constant
Service ID for accurate updates during fetch operations, the
Salto ID once assigned, remains static, meaning that it can change in certain cases. This is vital for ensuring consistency, since we assume configuration elements initially have matching attribute values. However, there are several scenarios where complications arise:
When an operation alters the
Service IDsof elements, Salto may perceive these as new elements due to the changed
This can result in the assignment of a new
Salto ID, potentially misaligning with IDs from other environments.
New Sandbox Creation:
Creating a sandbox from an environment with outdated
Salto IDsresults in the new sandbox having updated
This can cause mismatches when comparing with other environments.
Manual Alignment of Environments:
Consider a scenario with a sandbox and a production environment:
An element named
Xwith a specific
Service IDis added to the sandbox and fetched, resulting in a
This element's name is changed from
Yin the sandbox and fetched again. However, its
Salto IDremains as
In the production environment, an element named
Yis manually created and fetched, leading Salto to assign a new
Comparing sandbox to production, Salto inaccurately suggests adding the
Xelement and removing the
To effectively address these cases, it's possible to regenerate the
Salto IDs to reflect the current element attributes. To do so, you should run a fetch operation, in both the source and target environments, with the 'Regenerate Salto IDs' option enabled.