We are planning an Instance Refresh. What check points are recommended to review?
My company wants to refresh Test instance content and configuration with the current Production Environment.
Our new Development instance requires to match current Production environment.
Typically, Test/Development/PreProd instances are used by selected administrators while preparing performance, compensation or learning cycles (annual, bi-annual, etc).
Double check within your company that no feature, test configuration or form will be lost when overwriting this kind of target instance. A best practice would be to validate the refresh activity with the administrators for each module in your company.
The most common practice we see in refresh requests is a refresh from Production instance to Test instance. With that in mind, you need to be aware that Production instance data is actual private information from live end-users and it might be required you anonymize certain fields like e-mail addresses after the refresh.
Find below several points that should be considered when requesting an Instance Refresh or Clone, based on previous experiences and lessons learnt:
- To ensure a smooth refresh please ensure there is no ongoing implementation or projects being done in your target instance by either one of the following :
- Your own internal implementation teams
- Third party partners and/or consultants
- The SAP-SuccessFactors professional services team
- Any existing configuration present only in the target instance (For example, from ongoing implementations or other related activities)
- Any Configuration Change requests (CCOR) that was only performed in the target instance
- Any other configuration only present in the target for testing purposes
- Source is integrated but not target: Target will be integrated with the same system as the source.
- Source and target are integrated to different environments: Target will be integrated with the same system as the source.
- Source is not integrated but target is integrated: Target integration configuration will be removed.
In each case, this requires additional activities to restore the correct configuration after the refresh. If you have any doubts, simply provide us with the list of modules your company uses so that we can check.
This is dependent on the modules you have. Typically, you should verify basic functionality for each module works before and after the refresh.
For integrated systems, you should verify connectivity and also ensure the BizX instances are integrated with the right environments.
If you have any post-refresh issues, make sure to report these via support incidents so that we can engage the right resources to resolve them.
If several modules are affected please open an incident per module as this allows the respective teams to work on each issues in parallel rather than having several teams working on a single incident fixing one module at a time.
- SAP Jam: While you may choose to perform a refresh for BizX instances that are integrated with JAM, there is no process to refresh a JAM instance to another JAM instance.
This means that your JAM data and users will still be linked to the "old" users present in the target instance prior to the refresh.
For example if user ABC is present in the target BizX instance (and by extension also in the JAM instance integrated with the target instance), and your source BizX instance does NOT have user ABC, then the user ABC will be an orphan record in JAM after the refresh to the target.
- WFA/ORD: You should refer to reporting and analytics refresh KBA. Most BizX test instances that have WFA are linked to a snapshot that is not representative of actual data from BizX. If you have one of these and you perform a refresh from Production to Test, the data will stay as it is.
If you are refreshing data into a target instance that has live data (for example refresh from Test into production, or if you have a test instance that has Live data in WFA) then the data in WFA will not be up to date.
You will need to request a manual refresh of WFA to reflect what has been changed in BizX. You will need to contact your customer representative or open an incident for customer support.
- Advanced Reporting (ODS): A refresh must be done separately. Please refer to reporting and analytics refresh KBA.
If you have a doubt or want to make sure your other modules are supported please add these concerns and questions in the initial refresh request incident.
- Modules and features that can be impacted by the refresh :
- SSO: If you are using Single Sign-On in either the source, target, or both instances, please inform us prior to overwrite of the target in the support incident so that we can make sure your Single Sign-On configuration is exported in advance and restored after the refresh.
- IP access restriction: If you are using IP-restriction in either the source, target, or both instances, please inform us prior to overwrite of the target in the support incident so that we can make sure your IP list is exported in advance and restored after the refresh.
- Employee Central: Please refer to the KBA 2313764 for an up to date list of considerations and actions you will need to carry out after an Instance Refresh on an EC enabled instance.
- WFA: If you have Workforce Analytics in the source and Target instance, please wait for confirmation from the support team that WFA settings have been corrected in the target instance prior to logging into the WFA module in the target instance. You should refer to reporting and analytics refresh KBA .
- Specifically, if your source instance is located on Production stack and your target instance is located on Preview stack, we'll need to include an specific WFA script in the process to correct settings overwritten from Prod to Preview.
- Advanced Reporting (ODS): A refresh must be done separately. Please refer to reporting and analytics refresh KBA.
- LMS: If your BizX instance is integrated with an LMS instance on either the source, target, or both instances please inform us in the support incident so that we can make sure your LMS integration configurations are restored after the refresh.
- RMK: If your BizX instance is integrated with RMK on either the source, target, or both instances please inform us in the support incident so that we can make sure your RMK integration configurations are restored after the refresh.
- RCM: If you are using the RCM module, the refresh scripts will replace all external candidates’ e-mail addresses by dummy e-mails after the refresh from source to target. This is to ensure the external candidates do not receive duplicate e-mail notifications. All other candidate information (CVs, cover letters, address details, etc.) will be copied to the target instance.
- Mobile: If your target instance has mobile users showing in the mobile admin panel, these will remain after the refresh. This is because the association between Bizx Users and mobile devices takes place on a separate mobile server database. After the refresh the associations will show but admins will not be able to remove them. There is no current fix for that. In order to avoid this scenario you can delete all mobile associations in the target instance BEFORE the refresh takes place.
- Other: If you are using any other modules and have concerns, please let us know so that we can assess any potential configuration that may require backing up before the refresh takes place.
I have read the above and want to go ahead with a Refresh. What are the next steps ?
- You will need to open a P3 support incident to request a refresh. Please attach the refresh specific template as it will be required for processing and will speed up the initial processing of the incident.
The template and generic information about refreshes can be found in this KBA and KBA-2088117.
What is a Refresh?
A Refresh is the process of fully overwriting the database schema of an instance with the image of another. All contents of the TARGET instance will be permanently dropped and replaced with the contents of the SOURCE instance.
What is a Clone compared to an (Instance) Refresh?
A Clone is almost the same as an Instance Refresh but requires an additional process to have a net new instance provisioned. Where as an Instance Refresh already has a TARGET established, a Clone does not yet have a TARGET and the TARGET is created as part of the process. The significant difference in both is that any net new instance requires proper Sales documentation completed via CRM. Each instance provided to customers is contractually committed so any additional instances sought must first have the necessary CRM process completed.
Will there be any downtime involved as part of the refresh?
There is no downtime for your source instance as part of the refresh. There will be downtime for your target instance, this is usually only for a few hours but can vary depending on the nature of your request.
When I create a ticket requesting a refresh, how much notice do I need to provide for my preferred date to be available?
As per the process we need you to submit refresh request only 20 days prior to the requested refresh date.
If the refresh incident is created Prior to the 20 days then CPS engineers has rights to close the incident.
Note: Target instance Provisioning integration backup will be taken on the day the JIRA created. If any integration will be done between the incident submitted date and refresh scheduled date then those changes will not be reflect in the target instance and CPS team is not responsible for this
Ex. If on-boarding is not enabled in the target instance the date the refresh request is submitted and if this configuration is done in between incident submitted date and the refresh scheduled date then after instance refresh on boarding will not be there in the Target instance
Is there any restrictions regarding having a refresh from production to preview environments?
Between Preview Code Release and Production Code Release we are not able to refresh tenants from Preview to Production. Only Production to Preview refreshes can be done during this period of time. When both Production and Preview instances are on the same release version, there are no restrictions.
My source and target instances are on different versions. Is this supported and should I expect any problems?
Yes this is supported. This is a common scenario during refreshes from Production to Preview stack, while the preview instance is on a higher version then the Production environment.
After the operations teams perform the refresh, the database will be on the "older" version whereas the application code will be on the higher version. To resolve this, Operations will run an upgrade on the refreshed target instance.
After this upgrade, both the application and the database will have matching versions on the target instance. There are no special considerations required.
What is the process for masking email addresses in the target instance?
Please note a script is completed during the Refresh process replacing all email addresses within Target instance with dummy e-mail address like ‘email@example.com’ or ‘'firstname.lastname@example.org'’ (custom email addresses not available)
This prevents external candidates receiving emails from testing/processes, as well as emails that derive from PM or any other email related processes within Target instance. No other data will be scrambled and will be Customers responsibility within Target post refresh.
*Please note not every email address within instance is modified. Email addresses displayed in Live Profile or Employee Central are not edited and would require customer completion.
Can i Scrambled the target instance data ?
Scrambling of data is not part of Instance refresh. Any sensitive information requiring modification will be the sole responsibility of the customer, Admin.
When will the refreshed Instance be ready for use?
Once the DB activities is completed, both Operations and Cloud Support Engineers have a number of post refresh activities which need to be completed.
as per the new process after the DB task operation team will performing Solar re-indexing which required 24 to 48 hours to complete.
Once re-index done CPS will restore all the integration in the target instance and hand over the instance for customer use.
Customer may expect target instance will be available between 24 ~ 48 hours the DB task is complete
(Ex. If refresh date is 5th Mar and the DB task will complete on 7th March then on 9th the target instance will be available for customer use)
Operational limitations could prevent refreshes and all are subject to Operational approval and ability to complete.
Is Audit frame work will copy from source to target instance ?
Audit feature will not copy from Source to target instance if Target instance Audit is not enabled before refresh.
If you want to enabled audit in target instance after instance refresh then create separate incident to enable Audit feature
If source instance audit feature is not enabled and target instance Audit is enabled then after instance refresh CPS will switch on Audit from Provisioning. It is a part of post refresh task.
Is Logo will copy from Source to target instance ?
Logo copy is not part of instance refresh. Hence if customer want to update source logo in target instance then they have to follow the manual process to update
Is Show me video and features will work in target instance after refresh?
a) If show me video will not dispaly in UI screen of refreshed instance then customer need to disable and enable this feature manually in their target instance to work/display this option.
b) If source instance videos are not getting copied to the target instance then submit a new incident so that CPS will work with engineering team to copy the videos from source to target instance
Instance Refresh, Considerations, Planning, Issues, Problems, , KBA , LOD-SF-SER-REF , Instance Refresh , LOD-SF-LMS , SuccessFactors Learning , How To
|Instance_Refresh Request Form_V1.2.2018.docx|