2277508 - SuccessFactors Cloud Manual Instance Refresh Process & FAQ

Important: The Instance Refresh Tool should be used when scheduling BizX refreshes only if your instances do not qualify for IRT. If so, 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 the points below:

• A 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 is required to match the 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 the Support team. The 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 KBA is intended only for BizX Refreshes. Please refer to the other KBAs listed below for other module refreshes.

• Learning Management System Refresh 
• Onboarding System Refresh
• WFA Refresh

IMPORTANT things to be considered when requesting an Instance Refresh:

1. We now have the Instance Refresh Tool available in Successfactors for BizX & LMS refreshes, which allows customers to schedule and execute a refresh without having to engage Support.
   This tool can be used for most refreshes, excluding a few specific scenarios where the tool has technical limitations. Those limitations are covered in KBA 2791468 under the "LIMITATIONS" section.
   
   BizX and LMS Refreshes that are technically eligible to be performed using the Instance Refresh Tool must be scheduled using the tool itself. Manual refresh requests for such refreshes will not be accepted by the Support team.
   
   Manual refreshes will only be an option for:
• Refreshes that cannot be scheduled in the Instance Refresh Tool due to its technical limitations.   
• Refreshes that were scheduled using the Instance Refresh Tool but have failed or gotten reverted for any reason.
  
  
2. Any kind of refresh (manual or through the Instance Refresh Tool) is not reversible post-completion, so please make sure to provide correct source and target details while requesting the refresh.
   
   
3. 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.

2. Email masking:
   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.
   
   Masking of any other email address fields across SuccessFactors is not part of Manual Instance Refresh.
   
   NOTE: 
   a. Agency users mail address masking 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. An example would be Employee Central email addresses. Masking of EC emails will need to be manually done by Administrators via Import.
   b. Onboarding 2.0 email masking is not part of the standard refresh process. We will consider this in future enhancements.
   
   
3. 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

3. 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 are 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.

4. 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 user ABC will be an orphan record in JAM after the refresh to the target.
• Recruiting Marketing: Refresh is not available for Recruiting Marketing. Please refer to 2883870 - RMK Instance Refresh Request - Recruiting Marketing.
• Onboarding 1.0: This module is not part of BizX, and you will be required to create a Support case with the Onboarding team for manual Onboaring refresh as per KBA 2278276.
• Onboarding 2.0: This module is part of the BizX refresh. However, if Source instance does not have Onboarding 2.0 enabled and the Target instance does have Onboarding 2.0, it will result in overwriting Onboarding on the target to a blank configuration. 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. 
• Canvas (Advanced Reporting data source) refresh is now part of the BizX refresh. However, Canvas Reports are not included in the refresh. Canvas reports are not copied into the Target instance. Please read KBA 2315083 for more details and this reference blog on Advanced reporting.
• SAP Build Work Zone, advanced edition and SuccessFactors Work Zone : Refresh is not available for SAP Build Work Zone, advanced edition and SuccessFactors Work Zone. However, if you have SuccessFactors instance integrated with Work Zone, then the refresh may have impact on the workzone user sync. Hence, post refresh we recommend you to do a full sync from SuccessFactors to IAS and SuccessFactors to Work Zone for HR Cards to work seemlessly in Work Zone.

Note: xKBA 2673792 provides instructions on how to export and import Canvas Reports from one instance to another.

4. What items to check before and after the refresh?

PRE-REFRESH CHECKS for System Administrators:

1. 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.
   
   
2. 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.
   
   
3. Take time to read the items listed under *IMPORTANT NOTES* on the attached BizX refresh form found at the bottom part of this KBA.
   
   
4. LMS Integrated instances must have a valid employee export job scheduled in target environment. Please ensure you have verified the job schedule in the target instance.
   
   
5. 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.
   
   
6. 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.
   
   

7. From 2011 Release, the 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. It is important to export the report stories from the Target instance prior to the Instance refresh. Further details are in KBA 2315083.

   For Support: To confirm if a customer has Embedded Edition of People Analytics on the instance, you can check this in Provisioning > Company Settings > SAP Analytics Cloud Application URL.
   
   

8. Starting b2005, attachments will not be copied for BizX Refreshes. For more details, please refer to KBA 2900061 - Attachments are empty post BizX Refresh.

9. 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?
   
   

10. 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
  
  
11. Career Site integration with IAS - If your Target instance has this configured, please take a backup of the setting in Target > Admin Center > Career Site Identity Provider (IDP) configuration. This is not included on the settings automatically reverted for BizX refreshes using IRT, hence you have to revert this manually in the Target post-refresh.
    
    
12. If the Source instance has a Single Sign-on (SSO) setup and the Target has a Non-SSO setup, make sure that a Non-SSO admin account is maintained in the Source instance before refreshing your Target instance. This admin account allows you to access the Target instance after refresh.
13. Business Process Engine (BPE) should be enabled in Source & Target instance Provisioning -> Company Settings page.
14. For Payroll enabled instances:
• “Enable Payroll Control Center” should be enabled in Provisioning -> Company Settings page.

• It is also necessary to verify that permissions have been set for the objects of PayrollSystemAssignment.
  Payroll System Assignment permission is in RBP category Payroll Integration Permission: Manage Permission Roles->Payroll Integration Permission. Make sure that the MDF objects PayrollSystemAssignment are permitted.

 POST-REFRESH CHECKS:

1. If there are any post-refresh issues, make sure to report these via Support cases so we can engage the right resources to resolve them.
2. If several modules are affected after the refresh, please open one case 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 case fixing one module at a time.
3. If changing the date of the refresh is needed after it’s been confirmed by CPS/Engineering, contact CIC or your CSM.
4. Modules and features that can be impacted by the refresh:

• IAS Integration: Please refer to KBA 2954491 for the refresh impact on IAS integration, and required actions.
• 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. Refer to 2313794 - Instance Refresh - Employee Central - How to Reschedule Daily HRIS Sync Job.
• WFA/ORD: If you have Workforce Analytics in the Source and Target instances, 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 to 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 follow steps on KBA 2315083.
• 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 case 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 case so that we can make sure your RMK integration configurations are restored after the refresh. Also, there is RMK refresh, 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’ email 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 email notifications. All other candidate information expect attachments (2900061 - Attachments are empty post BizX Refresh) will be copied to the Target instance.
  Also, after a system instance refresh, information such Job Requisitions history or Applicant history is lost. This is expected behavior. For further details, see KBA 2834508 - Job requisition history and applicant history lost after instance refresh.
  Please note that if RCM is not enabled in the Target instance nor planned to be, there could be issues in the future when purging users in the Target instance because of RCM data in the DB that will get copied over during the instance refresh, which will prevent users from being purged.
• 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. This is expected behavior. 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.
  
  
  
  
• Intelligent Services Center 
  ISC Flows containing custom connectors are not automatically restored post-IRT Refresh.
  
  
• OAuth Configurations
  

  OAuth Clients in the scope of Security Center will be auto-backed up and restored in Target. OAuth Clients in Admin Center -> Manage OAuth2 Client Applications will not be restored.

• Custom login Page
  If you have acustom login page configured in the Target, you will need to copy and backup the configuration  and restore it after the refresh is completed. This is because currently the backup and restore is not happening in IRT for Custom Login Page Settings.
  
  
• Jobs
  The list below contains the job types and how they are handled during automated refreshes. For any jobs not listed below, please open a separate case with the respective module team owner of the job if you wish those to be reinstated post-refresh.
  
  As an administrator, we highly advise that you check the Job Scheduler Manager tool from Admin Center for you to see which FTP jobs you currently have in the Target instance pre-refresh. Please refer to KBA 2906009 on how to use this tool.
  

  How COPY Works? - These are either background jobs that run as-is or were previously scheduled explicitly as per customer’s request and do not have any impact on any of the other integrated systems. Post refresh, there are no required changes for the jobs listed below.

  How RESTORE Works? - These jobs have an impact on integrated systems, e.g., FTP jobs. The listed jobs below are restored in the Target instance post-refresh according to its original configuration.
  
  Notes: 
  

• • Only “SUBMITTED” and recurring jobs listed below will be “RESTORED” in the Target instance post-refresh. Should you require any inactive/not submitted jobs to be reinstated in the instance, this will need to be manually backed up and re-configured in the Target post-refresh. Please use “scheduled job manager tool” to view the complete list of jobs.
  • As the data on the refreshed instance will have changed, the job owner for the mentioned scheduled jobs may need to be updated if the job owner no longer exists in the Target post-refresh.
  • Any jobs not listed below will not be restored nor copied. 
    
    

    Job Type	Action Type
    PurgeExpiredReportsJobType	COPY
    RegisterMissingAnalyticsArtifactsInActionSearchJobType	RESTORE
    AdhocReportExportJobType	RESTORE
    MigrateCareerPathV2ToJDM2RolesJobType	COPY
    AutoMatchForSupervisedProgramJobType	COPY
    GeoLearningActivityLoadJobType	COPY
    MentorUnavailabilityNotificationJobType	COPY
    UpdateCDPMentoringSACLabelJobType	COPY
    DevelopmentTemplateConversionJobType	COPY
    CatalogImportJobType	RESTORE
    LACmpMappingExportJobType	RESTORE
    LACmpMappingImportJobType	RESTORE
    MassEditImportJobType	RESTORE
    MentoringProgramJamGroupInviteJobType	COPY
    MentoringProgramLaunchJamActivityJobType	COPY
    MigrateDevGoalDataForAdhocReportBuilderJobType	COPY
    SendSignupEmailJobType	COPY
    TGMDevGoalImportFTPJobType	RESTORE
    UserReLMapImportJobType	RESTORE
    InstanceRefreshAuditTablesJobType	COPY
    UnifiedSuiteReportingConfigJobType	RESTORE
    InvokeSPCAPIToRefreshSACTenantDetailsJobType	RESTORE
    DeleteAllUserPhotoJobType	RESTORE
    BatchExportPhotoJobType	RESTORE
    DeleteDuplicateBackgroundDataJobType	COPY
    LiveProfileExportJobType	RESTORE
    LiveProfileImportJobType	RESTORE
    BatchUploadPhotoJobType	RESTORE
    JobServerRegularDataPurgeJobType	COPY
    IRAsyncPredictJobType	RESTORE
    JobInfoImportFollowUpProcessingJobType	COPY
    DeltaUserExportJobType	RESTORE
    UserExportJobType	RESTORE
    UserImportJobType	RESTORE
    SaveReportConfigChangesJobType	RESTORE
    IRPredictionReportJobType	RESTORE
    PurgeDynamicLoggerGlobalJobType	COPY
    NotificationPurgeJobType	COPY
    RDFReportExportJobType	RESTORE
    MigrateReportTilePreferencesJobType	RESTORE
    PicklistExportJobType	RESTORE
    PicklistImportJobType	RESTORE
    SnapShotLnrJobType	COPY
    SyncPIIDataJobType	COPY
    HrisPCGSumsSyncJobType	COPY
    ECAlertsAndNotificationsJobType	COPY
    WFAutoApprovalJobType	COPY
    WFAutoEscalationJobType	COPY
    WorkflowActionReminderJobType	COPY
    PayScalePayIncreaseJobType	COPY
    DeltaLiveProfileExportJobType	RESTORE
    PositionManagementRegularCleanUpJobType	COPY
    PositionManagementRegularCleanUpSchedulerJobType	COPY
    BizXDailyRulesProcessingBatchJobType	COPY
    CustomerInstanceDataExportJobType	RESTORE
    BulkUserImportJobType	RESTORE
    DeltaUserImportJobType	RESTORE
    HrisSyncJobType	COPY
    BIZXReportExportJobType	RESTORE
    MDFImportFTPJob	RESTORE
    MDFExportJob	COPY
    SchedulerServiceHelperTest	RESTORE
    SyncWfaAndBizxInstanceJob	RESTORE

    RefreshRBPRulesJob

    COPY

    
    Note: The RBP Refresh Rules is a legacy job for updating RBP.Tt is only used by a small number of customers. The majority of customers are using the Realtime refresh framework for updating RBP, which is copied and restored with the refresh. See KBA 2766870.
    
    
• 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?

1. Open a Support case to request a refresh.
   Use "LOD-SF-PLT-REF" component for BizX Refreshes.
   
   
2. Please fill out the BizX refresh-specific template which you may download at the "Attachments" section of this article, 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.

**NOTES for support, please see "Internal memo" section of this KBA for your reference.

=========================================================================
FAQ

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. Is it possible to request a refresh with a blank instance as Source? Is it possible to perform an instance clean up for a Target instance via Refresh?
   Yes, in that case please put "BLANK TENANT" in the refresh form for the Source Instance details. Do note that a refresh with a blank source will wipe all data and configuration from the Target instance.
   
   For a blank refresh request, please provide any one of the below tenants as source instance:

   Data Center	Company Id
   EU - Production stack	BLANKDC55PRD
   Non EU - Preview stack	BLANKDC66PRE
   EU - Preview stack	BLANKDC2PREV

   All tenants are equally blank in terms of data and configuration. The difference is only in the Data Center and Prod/Preview types.
   
   
4. Can a refresh be reverted post-completion?
   Any kind of refresh (Manual or through Instance Refresh tool) is not reversible post-completion, so please make sure to provide correct Source and Target details when requesting the refresh.
   
   
5. Will there be any downtime involved as part of the refresh?
   Downtime will only be observed on the Target instance. The Source instance will be available all throughout the refresh process.
   
   
6. 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 case is created prior to 20 days, CPS engineers have the right to close the case.
   
   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 case submitted date and the refresh scheduled date, Onboarding integration will not be reverted on the Target instance after the refresh.
   
   
7. 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.
   
   

8. Handling Priority
   Refresh requests are normally assigned as a "P3 - Medium" priority case.  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.
   
   

9. My Source and Target instances are on different versions. Is this supported, and 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).
   
   Example:
   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.
   
   
10. 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.
    
    We will stop scheduling any Preview to Production refreshes less than 48 hours before Preview release date since a manual refresh execution can take 24-48 hours to be completed with all steps combined.
    
    
    
11. 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.
    
    
12. Can I have the Target instance data scrambled? Does Manual Refresh support Data Anonymization?
    Data Anonymization can now be opted for during manual refresh. This feature includes a limited and fixed set of fields across BizX for data scrambling. Please refer to this guide for the complete list of fields that are covered for anonymization-> Instance Refresh Data Anonymization Fields | SAP Help Portal.
    
    
    
13. 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. Lastly, once re-indexing is done, CPS will restore all integration settings in the Target instance and then hand over the instance for customer use. Operational limitations could prevent refreshes, and all are subject to Operational approval and the 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 use on March 9th.
    
    
14. Is the company logo copied from the Source to the Target instance?
    The logo image is not copied, but the internal company logo Reference URL is copied from Source to Target. When Source and Target are in same Data Center, this can lead to the Source logo being displayed in Target post-refresh.
    
    
15. 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, the 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 case for CPS to work with Engineering team and copy the videos from Source to Target.
    
    
16. 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.
      
      
17. Are Custom Themes copied from the Source to the Target instance after a refresh?
    Yes.
    
    
18. 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 case. 
    
    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.
    
    
19. 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]
    
    
20. Are tiles (including custom tiles) copied from Source to Target?
    Yes. If you have custom tiles in the Target which you need to revert post-refresh, please ensure to save the tile settings pre-refresh.
    
    
21. Will the candidates (in RCM) be able to log in to the destination Career Site and not the SF system post-refresh? Will the agency users be able to log in to the agency portal in the destination post-refresh?
    The passwords are copied during the refresh and should work on the refreshed instance even if the URLs are different. This is true for both candidate profiles and agency users.
    
    
22. Will the IAS (KBA 2791410) Upgrade status be retained in Target post-refresh?
    Any IAS related configuration and status (21st March 2022 onward) in Target will be retained post-refresh.
    
    
23. Qualtrics Integration is not available in Target instance even though I have upgraded it in Source and Target instance before refresh.
    It is an expected behavior. See KBA 3230588.
    It is also expected that Qualtrics is automatically disabled in the Target instance to prevent your system from immediately starting up Qualtrics surveys before you're ready for them to begin. See Enabling Qualtrics After an Instance Refresh.
    
    
24. Running an Instance Refresh to a Production-type environment as target.
    Instance Refresh with Production-type tenants as Target is not a recommended practice from SAP SuccessFactors. If such a refresh is requested via support ticket, we may ask for a double confirmation on the choice of Target System, as well as business reason for requesting refresh to a Production-type tenant.
    Important: In this context, we are only referring to tenants with role "Production" as Production-type and not just all tenants hosted in any Production server stack (which can be Production-type or Test-type).

KBA on Data Processing agreements-> https://launchpad.support.sap.com/#/notes/2796649.

POST-REFRESH ISSUES

Investigation of "post-refresh" issues is possible within up to 30 days after the refresh completion. Any data or configuration issues identified in the Target after this period should be addressed via standard Support process by raising individual tickets to corresponding module teams.

• Instance Refresh Tool Admin Guide
• Community Blog Post
• For enabling the Instance Refresh Tool see KB article 2791468 - Instance Refresh Tool
• KB article 2088117 - Instance: New Instance Creation, Test Instance, Instance Refresh, Clone - Platform

sf, success factors, PLT, platform, biz x, rebuild, re build, refresh, job, Sync,EC,ANA , KBA , LOD-SF-PLT-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