This document has been created to review OAuth Configurations in terms of System Refresh activity
- You are planning to refresh one of your systems (e.g. Production [source] > Test [target] )
- You would like to know if OAuth Configurations (Manage OAuth2 Client Applications) will be copied from source to target system
Currently, the system refresh can be performed in the two ways outlined below:
- Manual Refresh (standard process for last number of years)
This involves customer / partner logging an incident with Cloud Support (LOD-SF-PLT)
The request is validated by Support and the refresh is then performed by our Operations team.
The manual refresh WILL copy all OAuth2 Client Configurations from source to target as part of the refresh.
- Instance Refresh Tool (this tool is currently in beta)
Refresh can now be performed on the customer / partner end, using the Instance Refresh Tool available via Admin Center.
Any customer who places a request for manual refresh, is evaluated by CS team to see if their source and target instance fulfill all criteria required for Instance Refresh Tool
If so, the tool is enabled for the customer and customer is asked to perform the refresh using the tool.
When refresh is performed via the tool, then the OAuth2 Client Configuration and other security related artifacts like X.509 certificates, key pairs WILL NOT be copied from source to target.
OAuth2 Client Configurations, System Refresh, Manual Refresh, Instance Refresh Tool , KBA , LOD-SF-INT-ODATA , OData API Framework , LOD-SF-INT , Integrations , LOD-SF-PLT , Platform Foundational Capabilities , Problem