Self-service promotion process FAQs
For background on self-service promotions in PingOne Advanced Identity Cloud, learn more in Introduction to self-service promotions.
Who owns the configuration in my environments?
You own and are responsible for the configuration in your tenant environments. Although Ping Identity manages and supports the Advanced Identity Cloud platform, you are accountable for creating, applying, updating, and supporting the configuration applied to the platform to meet your specific use cases.
Can I partially promote configuration? Or promote the configuration for an individual realm?
Ping Identity promotes static configuration for the whole environment, so promotions always include all realms and all other static configuration. It is therefore not possible to promote partial configuration of any kind between environments, or promote the configuration for an individual realm between environments.
What kind of configuration changes can my company make?
Ping Identity considers configuration to be either dynamic or static.
- Dynamic configuration
-
Dynamic configuration changes occur automatically when your application end users use Advanced Identity Cloud features. For example, when they configure applications or add users in the Advanced Identity Cloud admin UI, the changes take effect immediately in the development, staging, or production environments.
Dynamic configuration is not promotable.
- Static configuration
-
Static configuration changes occur only when authorized administrators make changes in the development environment, or when configuration changes get promoted to another environment.
All static configuration is promotable.
The following tables summarize the types of configuration changes possible:
Identity Cloud UI Configuration
| Feature | Dynamic (not promoted) |
Static (promoted) |
||
|---|---|---|---|---|
Applications
|
Yes |
|||
Custom domain names
|
Yes |
|||
Custom themes |
Yes |
|||
Federation
|
Yes |
|||
Federation login requirements |
Yes |
|||
Gateways & Agents
|
Yes |
|||
Identities
|
Yes |
|||
Journeys |
Yes |
|||
Password policy |
Yes |
AM Configuration
| Feature | Dynamic (not promoted) |
Static (promoted) |
|---|---|---|
Applications > Agents
|
Yes |
|
Applications > Federation
|
Yes |
|
Applications > OAuth 2.0 (excluding scripts)
|
Yes |
|
Authorization
|
Yes |
|
Scripts (all) |
Yes |
|
Services (per realm)
|
Yes |
IDM Configuration
| Feature | Dynamic (not promoted) |
Static (promoted) |
|---|---|---|
Configuration (using
|
Yes |
|
Managed objects
|
Yes |
|
Managed objects
|
Yes |
How do we determine what is static and dynamic configuration?
Ping Identity considers all configuration static, except for the two types of configuration data that may be changed at runtime: applications and access policies. These config data types can be created on the fly, and can be used immediately afterwards.
Applications represented by OAuth2 clients can be registered at runtime through the Dynamic Client Registration Protocol. Access policies are created every time an end user shares access to a resource.
Ping Identity recognizes that other types of applications or access policies might not change at runtime. But Ping Identity products handle each data class consistently, so we can leverage potential usage patterns in the future.
What exactly is promoted and what is not?
These artifacts are NOT promoted. They remain unchanged during the promotion process:
-
Identities:
Users, things, admins, roles, and assignments -
Applications:
Gateways and Agents -
Access policies:
AM policy sets and resource types
All other configuration can be promoted between environments.
How do I manage configuration?
You have the choice of using the Advanced Identity Cloud admin UI, or using the REST APIs for configuration.
- Dynamic configuration
-
-
You configure applications and add users in your development, staging and production environments.
-
Changes take effect immediately.
-
- Static configuration
-
-
You make changes in your development environment.
-
You promote it to staging or production when you are ready.
-
What if I need to revert configuration?
Static configuration is maintained in Git repositories within each of your environments. So, configuration can be restored as a whole to previous settings.
You may need to revert static configuration for these reasons:
-
You promoted configuration that caused instability or errors and want to restore the upper environment to the previous configuration.
In this case, you can run a self-service rollback using the API. Learn more in Run a rollback.
-
You made experimental configuration changes in your development environment. Despite reasonable efforts to reverse them, you haven’t succeeded and want to return to a stable configuration.
In this case, you can raise a ticket to Backstage Support to revert the configuration of your development environment to the safest backup point before the time you specify. Learn more in Revert configuration in your development environment.
Dynamic configuration is not altered when reverting static configuration. Users, applications, and access policies remain as they are.
What if some configuration attributes must vary per environment?
We understand that sometimes you have to use a configuration attribute value that is not identical across development, staging, and production environments. For example, you might need one set of credentials for an external service in the development environment, but a different set of credentials in the production environment.
For an explanation of how this type of configuration is handled, learn more in Define and promote an ESV.