--- title: Configuration resources requiring special handling description: Some configuration resources require special handling or behave a bit differently than other resources. Others can't be promoted directly because they're environment specific or include attributes that aren't compatible with the promotion process. component: pingone page_id: pingone:promote:p1_configuration_management_special_handling canonical_url: https://docs.pingidentity.com/pingone/promote/p1_configuration_management_special_handling.html llms_txt: https://docs.pingidentity.com/pingone/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md section_ids: p1-promote-exclusions: Resources excluded from promotion deleted-configuration-resources: Deleted configuration resources davinci-resources: DaVinci resources davinci-flows: DaVinci flows davinci-flow-policies: DaVinci flow policies davinci-applications: DaVinci applications secrets-and-passwords: Secrets and passwords certificates: Certificates agreements: Agreements notification-templates: Notification templates saml-idps: SAML IdPs user-attributes: User attributes ldap-gateway: LDAP gateway --- # Configuration resources requiring special handling Some configuration resources require special handling or behave a bit differently than other resources. Others can't be promoted directly because they're environment specific or include attributes that aren't compatible with the promotion process. ## Resources excluded from promotion Some resources can't be promoted at all. Excluded resources generally fall into the following categories: * **User and operational data**: Resources that contain user-specific or operational data, such as audit logs, user profiles, or device and session data, are excluded from promotion to prevent data integrity issues. * **Environment-specific secrets and keys**: These resources are inherently tied to a specific environment for security reasons and can't be promoted or used by another environment. These resources should always be configured in the promotion as sensitive promotion variables. * **Roles and permissions**: Although you can promote resources that require permissions or roles, the administrative access to them isn't promoted. This includes administrator role assignment and application role assignments. After the resource is promoted, you must manually assign the appropriate roles and permissions to the resource in the target environment. You can find a complete list of excluded resources in the [Excluded Resources](https://developer.pingidentity.com/pingone-api/platform/configuration-management/promotions/excluded-resources.html) section of the PingOne API documentation. ## Deleted configuration resources When you delete a configuration resource from the source environment after it has been promoted to the target environment, that resource remains in the target environment until you explicitly delete it there. You can use the promotion service to handle the deletion. A deletion promotion works similarly to a standard promotion, but instead of creating or updating the resource in the target environment, the promotion service deletes it. Learn more in [scenario 5](p1_config_promotion_scenario_5.html). ## DaVinci resources The promotion service fully supports the promotion of PingOne DaVinci resources, including flows, subflows, flow policies, connectors, and DaVinci applications. However, there are several differences in how certain types of DaVinci resources are processed during promotion. As with other configuration resources, you can map DaVinci dependencies to existing resources in the target environment or create them as new resources, but dependency behavior varies depending on the type of DaVinci resource you select for direct promotion. ### DaVinci flows When you promote a DaVinci flow, the promotion service identifies all of the dependent configurations used in the flow if they're referenced correctly. Only the most recent deployed version of the flow is promoted to the target environment. For example, if your flow has four versions, and version 3 is the most recent deployed version, only version 3 is promoted. Similarly, if the flow includes subflows, only the subflow versions referenced by the flow are promoted. DaVinci flows often contain a lot of environment-specific configuration. In established environments, flows might require refactoring before they are ready to promote. Before you promote a flow: 1. Review the flow and its subflows for embedded environment-specific values such as URLs, API endpoints, keys, tenant identifiers, or connector-specific settings. 2. Move these values out of flows and into DaVinci company context variables. 3. Create promotion variables for the company context variables so that the flow logic remains portable, and the environment values remain distinct. 4. Test refactored flows in lower environments such as development or test before considering them ready for promotion. | | | | - | ------------------------------------------------------------------------------------------------------- | | | Runtime data such as flow state and timeouts can remain in the flow as flow instance context variables. | Learn more in [Flows](https://docs.pingidentity.com/davinci/flows/davinci_flows.html) and [Variables](https://docs.pingidentity.com/davinci/variables/davinci_variables.html) in the DaVinci documentation. ### DaVinci flow policies When you promote a DaVinci flow policy, the promotion service identifies the flows referenced by the policy and the specific versions of the flows referenced. All flow versions used in the policy are promoted as dependencies of the policy. For example, you decide to promote a a flow policy that references two flows, and the policy uses version 2 of flow A and versions 1 and 3 of flow B. In this case, version 2 of flow A and versions 1 and 3 of flow B are all promoted as dependencies of the flow policy. | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | DaVinci flow policies are always linked to a DaVinci application. If you promote a flow policy directly, the associated DaVinci application is promoted as a dependency of the flow policy. This application isn't listed on the **Auto-Selected Dependencies** page when you configure the promotion, but it will be listed when you confirm the promotion configuration.If the application has additional flow policies associated with it, those policies aren't promoted as dependencies of the application.To promote all flow policies associated with a DaVinci application, promote the application directly instead of promoting the flow policies individually.Learn more in [Flow Policies](https://docs.pingidentity.com/davinci/applications/davinci_flow_policies.html) in the DaVinci documentation. | ### DaVinci applications When you promote a DaVinci application, the promotion service identifies all associated flow policies and promotes them as dependencies of the application. The specific versions of the flow policies referenced by the application are promoted. Learn more in [Applications](https://docs.pingidentity.com/davinci/applications/davinci_applications.html) in the DaVinci documentation. ## Secrets and passwords Many configuration resources in PingOne use secrets or passwords to connect third-party services, such as an external identity provider (IdP) or a PingOne DaVinci connector. When you select a resource to promote that includes attributes for secrets or passwords, PingOne requires you to create sensitive variables for promotion, which are stored securely and encrypted anywhere they appear. Learn more in [Sensitive variables](p1_promotion_key_concepts.html#p1-promote-sensitive-variables). ## Certificates Certificates can't be promoted directly, and certificate references in other resources require special handling: * **Default certificates**: If a resource in the source environment references a default certificate, the promotion service automatically maps that reference to the default certificate in the target environment during the promotion. * **Certificates as variables**: For non-default certificates, you must create promotion variables to store the certificate IDs for both the source and target environments. During the promotion, the service substitutes the variable value for the certificate ID in the target environment. The following example illustrates this process: 1. Create verification certificates in both the source and target environments. 2. Create a SAML application in the source environment that uses the verification certificate for that environment. 3. Create a promotion variable for the certificate ID attribute of the SAML application, setting the source environment value to the certificate ID in the source environment and the target environment value to the certificate ID in the target environment. 4. Promote the SAML application from the source environment to the target environment. The SAML application in the source environment uses the certificate ID defined in the variable for that environment. The SAML application promoted to the target environment uses the certificate ID defined in the variable for the target environment. ## Agreements When you promote an agreement: * Only the current revision for each localized version of the agreement is promoted. * The **Effective Date** in the target environment is set as follows: * If the **Effective Date** for the agreement is in the future in the source environment, that date is preserved in the target environment. For example, on September 1, 2026 you promote an agreement with an effective date of September 15, 2026. In the target environment, that agreement will have an effective date of September 15, 2026. * If the **Effective Date** for the agreement is the same or earlier than the date of the promotion in the source environment, the **Effective Date** in the target environment is set to the date of the promotion. For example, on September 1, 2026 you promote an agreement with an effective date of August 15, 2026. In the target environment, that agreement will have an effective date of September 1, 2026. Learn more in [Agreements](../user_experience/p1_agreements.html). ## Notification templates Notification templates can't be promoted directly. You must promote each content type and language combination individually. For example, if you have a notification template with two content types (email and SMS) and two languages (English and Spanish), you must promote each of the four combinations separately. These configuration resources are in the **Content** category for configuration promotion. The format of the resource name is \:\:\. For example, **New Credential Updated:en:SMS** is the English version of the **New Credential Updated** notification template for SMS delivery. **New Credential Updated:es:Email** is the Spanish version of the same notification template for email delivery. For notifications with a delivery type of email, you should create promotion variables for the **From Address** and **Reply-To Address** attributes if you want to set these addresses during promotion. However, you shouldn't use promotion variables if these values use a trusted email domain. Trusted email domains can't be promoted due to offline verification requirements. When you promote the resource without creating promotion variables for the email attributes, they're ignored. You can configure them manually in the target environment after promotion. Learn more in [Notification Templates](../user_experience/p1_notifications.html). ## SAML IdPs To successfully promote SAML IdPs: * Create a promotion variable for the **PingOne (SP) Entity ID** attribute for the IdP. If you don't use a variable, PingOne generates a unique value for the target environment and doesn't promote the source environment value. * Create a variable for the **Verification Certificate** for the IdP. This variable is required. If you don't create a variable, the promotion will fail. | | | | - | ------------------------------------------------------------------------------------------- | | | If there are multiple verification certificates for the IdP, create variables for each one. | Learn more in [Adding an identity provider - SAML](../integrations/p1_add_idp_saml.html). ## User attributes Individual user attributes are supported for promotion. However, when you promote an application or FIDO policy that references custom user attributes, all schema attributes are added to the promotion plan. You can manually exclude them before you run the promotion. Learn more in [User Attributes](../directory/p1_user_attributes.html). ## LDAP gateway Gateway credentials can't be promoted or managed using promotion variables. These credentials must be created in each environment after the gateway is promoted. Learn more in [LDAP gateways](../integrations/p1_ldap_gateways.html).