Salto simplifies Okta application management by enabling the deployment of tested applications from Okta preview to production and the ability to restore changes made to applications.
​
Since application settings often interact with external services and involve environment-specific configurations, some additional steps might be required. This article outlines common scenarios and provides guidance for deploying Okta applications with Salto.

When creating a new SAML application with Salto, Okta automatically generates a new certificate, which is required to configure the service provider. After deploying a new application, Salto provides clear guidance on the additional configuration steps needed to finalize the setup and ensure a smooth deployment process.

OIDC integrations rely on the client ID, a unique identifier used by external applications and services to communicate with Okta. Salto ensures the client ID remains consistent when deploying applications between tenants or restoring a deleted applications.
​While Salto supports migrating client IDs, it does not support deployment of internal application ID. This ID is generated by Okta and cannot be controlled, meaning that integrations relying on internal IDs may need additional manual adjustments.

When testing an application integration in a preview tenant, the application might connect to a sandbox version of the service provider. In production, however, it will connect to the production version. This discrepancy can lead to differences in various application properties, such as URLs, domain name, and other environment-specific settings.
​

Salto makes it easy to handle these differences: