Misalignment of Salto Element IDs

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.

Basing 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:

Sandbox Refresh:
- When an operation alters the Service IDs of elements, Salto may perceive these as new elements due to the changed Service ID.
- 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 IDs results in the new sandbox having updated Salto IDs.
- This can cause mismatches when comparing with other environments.
Manual Alignment of Environments:
- Consider a scenario with a sandbox and a production environment:
  1. An element named X with a specific Service ID is added to the sandbox and fetched, resulting in a Salto ID of X.
  2. This element's name is changed from X to Y in the sandbox and fetched again. However, its Salto ID remains as X.
  3. In the production environment, an element named Y is manually created and fetched, leading Salto to assign a new Salto ID of Y.
  4. Comparing sandbox to production, Salto inaccurately suggests adding the X element and removing the Y element.

Regenerating Salto IDs

To effectively address the above 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.

Important Notice on Restoring with Regenerated Salto IDs

When fetching an environment with the option to regenerate Salto IDs enabled, be mindful that attempting to restore to a version prior to this fetch may result in elements with newly generated Salto IDs not being restored. This limitation is due to the absence of these IDs in earlier versions, which can prevent a direct match during the restoration process. Please plan your restoration activities accordingly to make sure you recover the environment's configuration.
Related articles: Restoring an environment, Reverting deployments.