Clients always come with the requirements to refresh the lower environment with PROD like data. There are many reasons for this but not limited to the few mentioned below:
Refresh testing environment to perform UAT (User Acceptance testing) or SVP (Stress, Volume and Performance) testing.
Refresh PSP (Production Support Platform) environment which is used to replicate PROD issues.
This documents contains the steps to refresh lower environment database from PROD/higher environments.
Note: This does not contain the steps to mask PROD data. This work needs to be done separately with the help of experience resources.
Nice compilation of steps for prod to dev data refresh. How you handle the provisioning to target systems for the identity cubes created in dev IIQ from prod IIQ? The old identity snapshot will be lost, will Identity refresh task be able to trigger process to perform sync( provisioning) to downstream target systems?
It all depends on the conditions on the LifeCycle Events if the identities qualify for a trigger or not.
For example: at one site we have logic for Joiner = Initiate Joiner if there is no AD account. In such scenario when identity is migrated from PROD, it brings account links also. So Joiner will not be initiated.
However, it is possible when the triggers can be initiated. This is handled in past. For example: we have closed all the pending provisioning transactions from PROD in DEV by routing all the Provisioning requests to Work items. This way it does not impact he downstream system and creates work items in DEV system.
Above mentioned is one pattern that is followed. Similar to that different patterns can be followed.
Can you please elaborate the different implementation patterns to handle provisioning and deprovisioning of the requests in the DEV environment with the production data, similar to create work item?
