- An instance refresh is planned. What check points are recommended to review?
- A company wants to refresh Test instance content and configuration with the current Production Environment.
- A new Development instance requires to match current Production environment.
- Instance Refresh Tool Enablement
SAP SuccessFactors HCM Suite
- For implementation or testing purposes, customers or partners may want to copy the Data and Configuration of Instance A (SOURCE) to Instance B (TARGET). This can be achieved by submitting a refresh request to support team.
- Best practice for refreshes is to perform this for the whole suite (BizX, LMS, ONB, WFA); however, you also have an option to request specific module refreshes.
Note: This KB article is intended only for BizX Refreshes. Please refer to the other KB articles listed below for other module refreshes.
Several points to be considered when requesting an Instance Refresh or Clone, based on previous experiences and lessons learned:
- To ensure a smooth refresh please ensure there is no ongoing implementation changes being performed 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
- Since the refresh activity is a one to one "copy and paste" from the source to the target environment, please note that any customizations only present in the target instance will be overwritten. This includes (but not limited to):
- 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
- Impact to integrations: if you have an integrated system in your source environment (such as LMS, Onboarding, RMK, JAM), performing a refresh will result to the following scenarios:
- My Source instance is integrated to other modules, while Target instance does not have configured integrations
RESULT: Target will be integrated with the same system as the source.
- My Source and Target instances are integrated to different module systems
RESULT: Target will be integrated with the same system as the source.
- My Source instance is not integrated to any module systems, but Target instance is integrated
RESULT: Target integration configuration will be removed.
- In each case, this requires performing post refresh activities to restore the correct configuration after the refresh.
- For customers/partners submitting the refresh request, please refer to page 3 of the attached BizX refresh form to identify which modules or features currently being used in the TARGET environment.
- What items to check before and after the refresh?
- Admins/Implementation partners managing the instances should be able to identify which modules are currently enabled. **Typically, you should verify basic functionality for each module works before and after the refresh.
- For integrated systems, you should verify connectivity and ensure the BizX instances are properly integrated with the right environments.
- Take time to read the items listed under *IMPORTANT NOTES* on the attached BizX refresh form found at the bottom part of this KBA.
- If Integration Center Jobs are configured in the TARGET instance, make a backup of this from Admin Center > Integration Center page. Admins will need to manually revert this on the TARGET instance after the refresh.
- If there are any post-refresh issues, make sure to report these via support incidents so we can engage the right resources to resolve them.
- If several modules are affected after the refresh, please open one incident per affected 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.
- Some modules are not supported by the Instance Refresh process, see below:
- 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 : Is not copied as part of the BizX refresh refer too 2341764 - Workforce Analytics (WFA) Refresh - FAQ KBA for further details.
Note : ORD (Advanced Reporting data source) refresh is now part of the BizX refresh however some reporting products are not refreshed reference (KBA 2315083) for further details and reference blog on Advanced reporting.
Example: if the TARGET instance does not have Advanced Reporting (has only live data), no reload is required.
- If changing the date of the refresh is needed after it’s been confirmed by CPS/Engineering, contact CIC or your CSM.
- 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/ORD: 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 2315083 .
Note: If the instance is located on the Production stack and the target instance is located on the Preview stack, we'll need to include a specific WFA script in the process to correct settings overwritten from Prod to Preview.
- 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. If you have requested for LMS refresh, please refer to KBA 2165346 .
- 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. Also, there is RMK refresh and so, any other setting or data within RMK is not included on the BizX Copy.
- RCM: If you are using the RCM module, the refresh scripts will replace all external candidates’ e-mail addresses in the TARGET instance with a dummy e-mail address after the refresh. 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 than the ones listed above or any other 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?
- Open Medium support incident to request a refresh.
- Please fill out the BizX refresh specific template which you may download at the bottom part of this KBA (2088117) as this will be required for processing.
Instance Refresh Tool Enablement - Early Adoption Program
- The SuccessFactors team will execute pre-qualification criteria check on your pair of instances for enablement of the Instance Refresh self-service tool.
- If all pre-qualification criteria are met, tool will be enabled, and you will be notified.
- If your instances do not qualify to enabling the tool, we will proceed with manual refresh process and notify you of the schedule.
Note: There are validations in place to identify if your Source and Target instances are eligible for tool enablement.
- Some of the limitations for the tool enablement are:
- SOURCE and TARGET Data Center must be the same (ex: DC4 – HCM4Prev)
- Schema Size Limitation
FAQ (Frequently Asked Questions)
1. 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 (DATA and CONFIGURATION).
Note: Selective copy is NOT supported. By default, all Data and Configuration will be copied from SOURCE to TARGET for BizX Refreshes.
2. 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.
3. Will there be any downtime involved as part of the refresh?
Downtime will only be observed on the TARGET instance. SOURCE instance will be available all throughout the refresh process.
4. 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 10 to 20 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. Any integration settings changed after this date will not reflect after the refresh is completed.
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 integration will not be reverted on the Target instance after the refresh.
5. What is the correct process for canceling any refresh requests submitted to support?
If you wish to cancel any refresh requests at least 3 working days prior to the confirmed refresh date, you may do any of the following:
a. Reach out to your CSM to internally communicate with the internal teams for the cancellation of the refresh
b. You may call our Customer Interaction Hotline to request for cancellation.
6. My Source and Target instances are on different versions. Is this supported, and/or should I expect any problems?
If you are requesting for a refresh during release season, please be aware that we only support Production (Lower version) to Preview (Higher version).
SOURCE (b1811) while TARGET (b1902) > Supported
SOURCE (b1902) while TARGET (b1811) > Not Supported
Note: Instance versions are not being copied during a refresh.
There are no restrictions for SOURCE and TARGET on the same release versions
7. 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.
8. I want to mask the email addresses in the Target Instance after the refresh. Is this possible?
There are 2 types of email addresses being masked for BizX Refreshes.
a. Internal Email Addresses (BizX Emails) - Should you want to mask the BizX Email addresses in the Target instance, please put "YES" on the BizX Refresh Form for the question "Do you need Internal Email masking?".
b. External Candidate Email Address - By default, if you have specified on the BizX refresh form that you have RCM enabled in SOURCE, automatically, External Candidate Email addresses in the TARGET instance will be masked as part of the BizX Refresh Process. This prevents external candidates receiving emails from testing.
NOTE: Agency Users Email Addresses - This is not part of the standard refresh process. Any other email addresses not mentioned above will not be included on the email masking offered for BizX refresh. Sample would be Employee Central Email addresses. Masking of EC emails will need to be manually done by Administrators via Import.
9. 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.
10. 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.
11. Is the company logo copied 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.
12. 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.
13. 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.
14. Are Custom Themes copied from the Source to the Target instance after a refresh?
Yes. Custom Themes are copied as part of the manual refresh.
9. Are PGP Keys copied from the Source to the Target instance after the refresh?
Yes. Any scheduled FTP jobs which are using these PGP keys will be overwritten with the SOURCE instance's PGP keys. Should you require generating a new set of PGP keys for your scheduled imports, please advise support during 1:1 meetings or via incident submission.
10. I have integration Center jobs in the Target instance. Will this be included to SAP's post refresh activities?
Any existing integration center jobs on the Target instance will not be included to SAP's post refresh activities. Admins will be asked to manually revert them on the Target instance > Admin Center > Integration Center as not all parameters are present in Provisioning backend. Also, any modification to Integration center jobs in provisioning will result to failure. [2573673 - How to stop a scheduled interface in Integration Center]
11. Are the GDPR features or settings copied during the BizX Refresh?
No, it is never copied, because its in the code to exclude those feature ID’s during Company Settings copy.
sf, success factors, plt, platform, biz x, rebuild, re build , KBA , LOD-SF-SER-REF , Instance Refresh , LOD-SF-LMS , Learning Management System , How To
|IRT_BizX_Instance_Refresh Request Form__b1905.docx|