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.
- SAP SuccessFactos Bizx Platform
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 one incident per module as this allows the respective teams to work on each issue 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 to the initial refresh request incident.
7. 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 .
NOTE: Specifically, if your source instance is located on Production stack and your target instance is located on Preview stack, we'll need to include a 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 Medium 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 on this KBA as well as on KBA 2088117.
FAQ (Frequently Asked Questions)
- 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 a refresh?
A Clone is almost the same as a Refresh but requires an additional process to have a net new instance provisioned. Whereas a REFRESH is performed when a TARGET is already 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, which 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?
We need you to submit refresh request between 20 and 10 business days prior to the requested refresh date.
SAP’s Operations team has a timeframe of 10 business days to schedule an Instance Refresh. If the refresh incident is created prior to 20 days, CPS engineers have rights to close the incident.
NOTE: Target instance Provisioning integration backup will be taken on the day the JIRA (Operations ticket) is created. If any integration settings is changed between the incident submitted date and refresh scheduled date, then those changes will not be reflect in the target instance. For example: If Onboarding is not enabled in the target instance on the date the refresh request is submitted and this configuration is enabled in between incident submitted date and the refresh scheduled date, Onboarding will not be presented on the Target instance after the refresh.
- Are 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/or 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 than 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 upgrade 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 ‘firstname.lastname@example.org’ or ‘'email@example.com'’ (custom email addresses not support).
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 it will be customer's responsibility to do so within Target post-refresh.
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 have the target instance data scrambled?
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 to use?
Customer may expect target instance to be available between 24 to 48 hours after the DB activities are completed, or 72 to 96 hours in total.
Once the DB activities are completed, both Operations and Cloud Support Engineers have a number of post-refresh activities which need to be completed. After the DB activities, SAP's Operations team will perform Solr re-indexing, which requires 24 to 48 hours to be completed. Last, once re-indexing is done, CPS will restore all integration settings in the target instance and then hand over the instance for customer to use. Operational limitations could prevent refreshes and all are subject to Operational approval and ability to complete.
Example: if a refresh is scheduled for March 4th, the DB activities will potentially complete on March 7th and target will be ready for customer to use on March 9th.
- Is Audit Framework copied from the Source to the Target instance?
Audit feature will not be copied from Source to Target instance if it is not enabled on Target before refresh.
If you want to enable Audit in your Target instance, please create a separate incident.
In case Audit is already enabled in Target and not enabled in Production, it will remain enabled in Target after the refresh (as part of the post-refresh activities, CPS will switch on Audit from Provisioning when restoring the integration settings).
- Is the company logo copied from from the Source to the Target instance?
Logo copy is not part of instance refresh. If customer wants to update Source logo in Target instance then, have to follow the manual update process.
- Will "Show me" video and features work in the Target instance after a refresh?
Yes. For the most common issues with that functionality, please follow these steps:
a) If "Show me" video is not being displayed on the UI of the refreshed instance, customer needs to disable and enable the feature manually to force the system to display it correctly.
b) If videos are not getting copied from the Source to the Target instance, then submit a new incident for CPS to work with Engineering team and copy the videos from Source to Target.
What do I expect to happen to change/read audit logs(GDPR) and general audit logs?
- Except for Employee Central and Onboarding, all other audit logs(general audit logs) will not be copied from the source to target system post refresh.
- All the other general audit logs present in the target system will be purged.
- Read and change audit logs from the source system will not be available in the target system post refresh.
- Read and change logs already captured on the target system before refresh will be purged post refresh.
Instance Refresh, BizX, Copy from production, Refresh, Platform refresh , KBA , LOD-SF-SER-REF , Instance Refresh , LOD-SF-LMS , SuccessFactors Learning , How To
|BizX_Instance_Refresh Request Form_V2.12.2018.docx|