Important: The Instance refresh Tool should be used when scheduling BizX refreshes. Only if your instances do not qualify for IRT, then the manual refresh will be executed. - For full details on the instance refresh tool see KBA 2791468 - BizX Instance Refresh Tool & FAQ
This KBA outlines the Manual Refresh Process and considerations which should be carefully read prior to executing a manual refresh see below points :
- An Manual instance refresh is planned. What checkpoints 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.
- I want to remove all of my existing data and configuration. Is it possible to perform a refresh from a blank instance?
Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental
SAP SuccessFactors HXM 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.
IMPORTANT things 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.
- There could be post-refresh activities required to be performed to restore the correct configuration after the refresh.
- For customers/partners submitting the refresh request, please refer to page 4 of the attached BizX refresh form to identify which modules or features currently being used in the TARGET environment.
- Support only reverts select integration settings in the target as part of post activities. If the target instance already has the wrong configuration pre-refresh, this will not be corrected as part of the refresh request.
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.
- Recruiting Management: After a system instance refresh, information such job requisitions history or applicant history is lost, this is expected behavior see KBA for further details 2834508 - Job requisition history and applicant history lost after instance refresh - Recruiting Management
- Recruiting Marketing: Refresh is not available for Recruiting Marketing. Please refer to 2883870 - RMK Instance Refresh Request - Recruiting Marketing.
- Onboarding 2.0: We do not allow BizX Refreshes where Source instance does not have Onboarding 2.0 Enabled. See 2912722 for further details.
- WorkForce Analytics : Is not copied as part of the BizX refresh refer to 2341764 - Workforce Analytics (WFA) Refresh - FAQ KBA for further details.
- 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.
PRE-REFRESH CHECKS for System Administrators:
- 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. Support will not be responsible for correcting any misconfiguration identified in the TARGET instance post refresh.
- Take time to read the items listed under *IMPORTANT NOTES* on the attached BizX refresh form found at the bottom part of this KBA.
- The new homepage version of the SOURCE will be copied to the TARGET instace for manual refreshes. See combination of scenarios below.
- If Integration Center Jobs are configured in the TARGET instance, please take a backup of the job settings from Admin Center > Integration Center page. Admins will need to manually revert this on the TARGET instance after the refresh.
- Any settings under Integration Center > Security Center are also included in the copy. Should you require oAuth related settings to be reverted post refresh, please refer to KBA 2817861 - System / Instance Refresh and OAuth Configurations for further details.
- Picklists are covered by the instance refresh. In case one of your instances has already undergone Picklist Migration and the other one has not, please be aware of the potential outcomes for each scenario below:
- If SOURCE picklists are already migrated and TARGET picklists are still on legacy model
Result: the instance refresh will be equivalent to migrating TARGET picklists. Both instances will then have only MDF Picklists and Picklist Management will not be available in neither instances anymore.
- If TARGET picklists are already migrated and SOURCE picklists are still on legacy model
Result: the instance refresh will revert picklist migration. You should either wait for SOURCE to be migrated or request TARGET to be migrated again after the refresh takes place. Please refer to KBA 2793223 for additional details on migration schedule.
For instructions on how to check if your instance is already migrated, please check the Picklist Migration guide.
From 2011 Release, Instance refresh process will be supported with SAP SuccessFactors People Analytics so customers can carry their usual instance refresh activity on their SAP SuccessFactors People Analytics enabled instances. See Blog for details.
Note: Stories from the source tenant aren't copied to the target tenant during Instance Refresh. We recommend that you export the Story reports you want to retain on your target tenant, before you perform Instance Refresh. After the refresh is complete, you can reimport the Story reports into the target tenant.
For Manual refresh, there are some additional steps customers need to take:
- Export the relevant X509 certificates and OAuth settings before you initiate the manual refresh process, and import the files into your tenant after the refresh is complete.
- See help guide for completed step.
For support: To confirm if customer has Embedded Edition of People Analytics on the instance, you can check this in Provisioning > Company Settings > SAP Analytics Cloud Application URL.
Starting b2005, attachments will not be copied for BizX Refreshes. For more details, please refer to KBA 2900061 - Attachments are empty post BizX Refresh.
If you are using OpenText as your Document Storage in the Target instance, please refer to KBA 2926317 - How to re-establish OpenText Integration in Target instance post-refresh?
If you have EC Payroll integrated in the Target instance, please take a backup of the following settings in the Target instance. You will need to restore them post refresh as these will be overwritten with the configuration from Production.
- Admin Center > Manage Data > Payroll Control Center Configuration
- Admin Center > Manage Data > Payroll System Configuration > Payroll System URL
- 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.
- 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.
If the TARGET instance is integrated with IAS (SAP Cloud Identity Authentication Service), please do the following post refresh Instance Refresh (both automated and manual):
- Before doing the IPS resync, the customer needs to verify IPSADMIN and corresponding permissions in the refreshed target instance. Please see a KBA 2954491.
- Verify IPS template where refreshed target instance is the source system and then do a manual Resync (for all the target systems in IPS). The details on IPS Resync process can be found on this section of the admin guide.
- If the customer has set up real time user sync, they need to verify and update the integration configuration for the business scenario Real-time User Account Sync from SAP SuccessFactors to SAP IPS. The details on configuration for real time user sync can be found here.
- 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. 2313794 - Instance Refresh - Employee Central - How to Reschedule Daily HRIS Sync Job
- 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 .
If you have WFA license, please refer KBA 2341764
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
- Adhoc Reports: You might see ad hoc reports missing in the Report Center post refresh. To retrieve the reports, please follow the steps in KBA 2610465 to sync copied ad hoc reports post refresh.
- People Analytics: If you have this enabled in the target instance, Administrators will need to restore of X509 by following the steps provided in KBA 2817861.
- 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.
- Continuous Performance Management: Depending on the scenarios listed below, please check the "Customer Call to Action" column to see the post activities needed to be done after the refresh. Further details can be found in this section of the administrator guide.
- 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 all information and would like to go ahead with a Refresh. What are the next steps?
- Open an incident to support to request a refresh. Please use "LOD-SF-SER-REF" component for BizX Refreshes.
- Please fill out the BizX refresh specific template which you may download at the "Attachments" section of this article (2088117) as this will be required for processing.
NOTE: If the refresh is being conducted transferring data from a different customer, then an approval from both customers in written form is required.
Is it possible to perform an instance clean up a target instance via Refresh?
Yes, this is possible for BizX tenants. Proceeding will wipe all Data and Configuration existing in the TARGET instance. If you wish to proceed, please open a case with LOD-SF-SER-REF for support team to assist you. Please ensure to fill out the refresh form and mention "BLANK TENANT" on the SOURCE instance details. No need to fill out the other details as there is no need for support to perform post refresh activities. Further information can be seen on KBA 2277508. Form can be downloaded on the attachment section of this knowledge base article.
**NOTES for support, please see "Internal memo" section of this KBA for your reference.
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 (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.
- 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?
Downtime will only be observed on the TARGET instance. SOURCE instance will be available all throughout the refresh process.
- 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.
- 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.
Refresh requests are normally assigned as a "P3 - Medium" priority incident. If there is a more urgent priority required, please provide a 'Business Impact', so support can assess the priority requirement. Please note that a response of "Go-Live" is not sufficient information. No matter the priority, all time frames, depend on the availability of the Operations team.
- 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 and there are no restrictions for SOURCE and TARGET on the same release versions
- 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.
- 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 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.
NOTE: Onboarding 2.0 emails anonymization or masking is not possible as of the moment. We will consider this in future enhancements. As a workaround, please try using imports to anonymize the email addresses as they are stored at a person level.
- 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.
However, DATA ANONYMIZATION for select module fields is possible if the refresh is BizX refresh is performed via the automated process / Instance Refresh Tool. You can refer to KBA 2791468 - BizX Instance Refresh Tool & FAQ for more details on how to use this.
- 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 the company logo copied from the Source to the Target instance?
- 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 by following the steps here.
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.
- Are Custom Themes copied from the Source to the Target instance after a refresh?
- 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 by updating the incident. NOTE: After PGP is migrated to Security Center, Security center artifacts are restored on the same instance after refresh. It is not copied from one instance to other. Each instance should have its own PGP Key which gets restored after the refresh.
- 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]
- Are tiles (including custom tiles) copied from SOURCE to TARGET?
Yes. If you have custom tiles in the TARGET which you need to revert back post refresh, please ensure to save the tile settings pre-refresh.
sf, success factors, PLT, platform, biz x, rebuild, re build, refresh, job, Sync,EC,ANA , KBA , LOD-SF-SER-REF , Instance Refresh , LOD-SF-LMS , Learning Management System , LOD-SF-PLT , Platform Foundational Capabilities , LOD-SF-ANA , Analytics & Reporting (Ad Hoc, YouCalc, ORD) , LOD-SF-EC-HRS , HRIS Sync , How To
|BizX Manual Refresh Form_2105.docx|