setting up and using data protection and privacy

PUBLICDocument Version: 2H 2021 – 2022-03-23

Setting Up and Using Data Protection and Privacy

© 2

022

SAP

SE o

r an

SAP affi

liate

com

pany

. All r

ight

s re

serv

ed.

THE BEST RUN

Content

1 Data Protection and Privacy in SAP SuccessFactors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Prerequisites for Using Data Protection and Privacy Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1 New Data Model for Right to Return and Data Protection and Privacy. . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Caution About User ID Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Data Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1 Getting Started with Data Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Data Retention Time Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Prerequisites for Data Retention Time Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

HRIS Sync of Fields Required for Data Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Country/Region Names Required for Data Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4 Data Purge Use Cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40Purge of Inactive Users and All Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Purge of Specific Data for One SAP SuccessFactors Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Purge of Audit Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Purge of External Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Best Practice for Purging Data Targeting Large Number of Users. . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.5 DRTM Purge Request Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47DRTM Master Data Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54DRTM Audit Data Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61DRTM Inactive Candidate Purge Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Data Included in the DRTM Benefits Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Data Included in the DRTM Compensation/Variable Pay Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Data Included in the DRTM Employment Information Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Data Included in the DRTM Employee Profile Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Data Included in the DRTM Learning Data Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Data Included in the DRTM Mentoring Program Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Data Included in the DRTM Performance Reviews Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Data Included in the DRTM Person Information Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Data Included in the DRTM Succession Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82Data Included in the DRTM Time Management Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Data Included in the DRTM Workflows Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Data Included in the DRTM Onboarding Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Data Included in the DRTM Clock In Clock Out Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.6 Important Notes About Data Purge and Data Retention Time Management. . . . . . . . . . . . . . . . . . . . . . 92User's Current Country or Region Is Used for Data Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

2 PUBLICSetting Up and Using Data Protection and Privacy

Content

Purging the Personal Data in Workforce Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104SAP SuccessFactors Learning Data Retention Time Management (DRTM) Preview Report. . . . . . . . 105SAP SuccessFactors Learning Native-only Purge Exceptions to Data Retention Management. . . . . . 106Stages of User Data Removal in SAP SuccessFactors Learning. . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Instructors and Administrators must have Related User IDs and the IDs Must Match. . . . . . . . . . . . 109Alumni Data in SAP Jam Collaboration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Configuring Retention Period to Purge Import Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Veto Behavior in Data Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110Data Purge and Data Retention Times for Users with Multiple Employments. . . . . . . . . . . . . . . . . . . 111Maximum Number of Users in a Purge Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

3.7 Process for Setting Up Data Retention Time Management (DRTM). . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Enablement of Data Retention Time Management (DRTM). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Recommended Permission Settings for Data Purge Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Configuration of Data Retention Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

3.8 Process for Purging Data with Data Retention Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1593.9 DRTM Purge Request Set-Up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Purging Inactive Users with DRTM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Purging Specific Types of Data with DRTM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Purging Audit Data for Active and Inactive Users with DRTM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165Retrieving an Onboarding External User Report During a Data Purge. . . . . . . . . . . . . . . . . . . . . . . . 168

3.10 Submitting a DRTM Purge Request for Approval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1693.11 Generating Preview Report for a Scheduled Purge Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1713.12 Reviewing a Purge Preview Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1723.13 Approving or Declining a Purge Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1733.14 Verifying Final Purge Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743.15 Data Purge in Employee Central Integration with Other Systems Holding Employee Data. . . . . . . . . . . . 175

How the CompoundEmployee API Reacts to Data Purge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .176How the CompoundEmployee API Delta Transmission Mode Reacts to Data Purge. . . . . . . . . . . . . . 194How the Employee Central Data Replication Monitor Reacts to Data Purge. . . . . . . . . . . . . . . . . . . 196Purge of Employee Central Data Replicated to ERP Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .198Purge of Employee Central Data Replicated to Employee Central Payroll. . . . . . . . . . . . . . . . . . . . . 209

3.16 Legal Holds on Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214Permission to Edit the Purge Freeze List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Adding a User to the Purge Freeze List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216Adding Multiple Users to the Purge Freeze List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Editing an Existing Entry on the Purge Freeze List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Deleting an Existing Entry on the Purge Freeze List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

3.17 Check for Updates in Upgrade Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2213.18 Changing the Minimum Number of Approvers for Purge Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2223.19 Checking Job Status and Details for a Purge Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2233.20 Deleting Old Purge Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Setting Up and Using Data Protection and PrivacyContent PUBLIC 3

3.21 Deleting Old Purge Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2253.22 Non-Standard Purge Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Native-Only SAP SuccessFactors Learning Customer Configurations. . . . . . . . . . . . . . . . . . . . . . . 227Purge Process for Integrated Users of Learning Sites (External Users). . . . . . . . . . . . . . . . . . . . . . 249Purging SAP SuccessFactors Learning Background Jobs Automatically. . . . . . . . . . . . . . . . . . . . . 253Purging SAP SuccessFactors Learning Background Reports Automatically. . . . . . . . . . . . . . . . . . . 254Email Notification Archiving in SAP SuccessFactors Learning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255DRTM Data Purge for MDF Custom Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Configuring Retention Period to Purge Import Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Managing Data Retention Settings for Candidates and Client Administrators in Career Site Builder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

4 Data Blocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2664.1 Getting Started with Data Blocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2674.2 Important Notes About Data Blocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267

Setting Up a Simple Data Blocking View Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2694.3 Setting Up Data Blocking for Effective Dated Objects (EC Objects). . . . . . . . . . . . . . . . . . . . . . . . . . . 2704.4 Setting Up Data Blocking for MDF Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .270

5 Change Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2725.1 Getting Started with Change Audit for Personal Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2735.2 Important Notes About Change Audit for Personal Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

Change Audit Reporting on Shared Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2805.3 Enabling Change Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2815.4 Process for Generating Change Audit Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Creating a Change Audit Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Downloading a Change Audit Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Interpreting a Change Audit Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290Viewing or Deleting Recurrence Schedules for Change Audit Reports. . . . . . . . . . . . . . . . . . . . . . . 292Standard Data Included in All Change Audit Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

5.5 Data Privacy Auditing for Learning Native Only Customers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Auditing Changes Made to User Personal Information in SAP SuccessFactors Learning. . . . . . . . . . 296Auditing Changes Made by a Learning Administrator in SAP SuccessFactors Learning. . . . . . . . . . . 298

5.6 Creating a Change Audit Report for Career Site Builder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

6 Read Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3006.1 Getting Started with Read Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3006.2 Important Notes About Read Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3016.3 Read Access Logging and Shared Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3046.4 Setting Up Read Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Disabling or Enabling Read Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .306Configuring Read Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307Excluding User Accounts from Read Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332


Content

6.5 Read Audit Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333Creating a Read Audit Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333Read Audit Reports Include Sensitive Personal Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335Interpreting a Read Audit Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

6.6 Read Audit in the Employee Central Compound Employee API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338Basic Assumptions for Read Audit in the Compound Employee API. . . . . . . . . . . . . . . . . . . . . . . . 339Read Audit in Delta Transmission Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340Read Audit in Snapshot Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

6.7 Read Audit in Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341Read Audit in Table Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341Read Audit in Advanced Reports (Realms). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343Read Audit in Story Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344Protecting Personal Data in Spreadsheet Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345Disabling Sensitive Fields in List Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346Sensitive Label for Fields in the Canvas Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

7 Information Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3487.1 Getting Started with the Information Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3487.2 Important Notes About the Information Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3497.3 Configuring the Information Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352

Creating a Custom MDF Object for the Information Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Configuring a Custom MDF Object as Legislatively Sensitive Personal Data (LSPD). . . . . . . . . . . . . 354Adding Data to a Custom MDF Object for the Information Report. . . . . . . . . . . . . . . . . . . . . . . . . . 355

7.4 Running the Information Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356Running an Information Report with Workforce Analytics Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . 358Running an Information Report with a Custom MDF Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360Target Populations for Information Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

7.5 Downloading the Information Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3617.6 Creating an Information Report for Career Site Builder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3627.7 Auditing User Information Stored in SAP SuccessFactors Learning for Native Users. . . . . . . . . . . . . . . 3637.8 Downloading Information Reports for Compensation Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

8 Consent Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3668.1 Getting Started with the Consent Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3668.2 Important Notes About Consent Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3678.3 Creating Data Privacy Consent Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3698.4 Viewing and Editing Data Privacy Consent Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3718.5 Setting the Data Privacy Consent Statement Status. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3738.6 Deactivating User Consent in Performance Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3748.7 Enabling Data Privacy Consent for Onboarding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3758.8 Enabling the Data Segmentation Field of Recruiting Data Privacy Consent Statements. . . . . . . . . . . . . 375

Creating a Recruiting Data Privacy Consent Statement with the Data Segmentation Field. . . . . . . . . 376

Setting Up and Using Data Protection and PrivacyContent PUBLIC 5

Data Privacy Consent Statements for Career Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377

8.9 Setting Up and Using the Consent Statement Life Cycle in SAP SuccessFactors Learning. . . . . . . . . . . 383

Supported Configurations for Consent Agreements in SAP SuccessFactors Learning. . . . . . . . . . . .384

Adding Data Storage Consent Statements to SAP SuccessFactors Learning. . . . . . . . . . . . . . . . . . 385

Publishing Consent Statements in SAP SuccessFactors Learning. . . . . . . . . . . . . . . . . . . . . . . . . . 388

Enabling SAP SuccessFactors Learning Consent Statements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389

Reviewing SAP SuccessFactors Learning Consent Agreements. . . . . . . . . . . . . . . . . . . . . . . . . . . 390

Viewing and Revoking Personal Consent Statements in SAP SuccessFactors Learning. . . . . . . . . . . 391

9 Data Protection and Privacy in SAP SuccessFactors Learning. . . . . . . . . . . . . . . . . . . . . . . . . . . 392

10 Data Protection and Privacy in Metadata Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

11 Data Protection and Privacy in SAP SuccessFactors Recruiting Management. . . . . . . . . . . . . . . 395

11.1 Applications and Candidates Purge in Recruiting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

Prerequisites for Purging Applications and Candidate Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

Purging Applications in Recruiting Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Purging Candidate Profiles in Recruiting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

XML Fields That Do Not Support Anonymization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .410

12 Data Protection and Privacy in Time Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

13 Data Protection and Privacy in Employee Central Payroll. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

14 Data Protection and Privacy in SAP SuccessFactors Performance & Goals . . . . . . . . . . . . . . . . . .415

15 Data Protection and Privacy in Employee Central Integration with Other Systems Holding Employee Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

15.1 Data Protection and Privacy in SAP SuccessFactorsCompensation. . . . . . . . . . . . . . . . . . . . . . . . . . . 418

15.2 Data Protection and Privacy in SAP SuccessFactors Employee Central Imports. . . . . . . . . . . . . . . . . . .418

15.3 Data Protection and Privacy in SAP SuccessFactors Employee Central Apprentice Management. . . . . . 419

16 Data Protection and Privacy in SAP SuccessFactors Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 420

17 Data Protection and Privacy in SAP SuccessFactors Workforce Analytics. . . . . . . . . . . . . . . . . . . 421

18 Data Protection and Privacy in Career Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

19 Data Privacy & Security Settings for Career Site Builder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

20 Cookie Handling in SAP SuccessFactors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425

20.1 What Are Cookies?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

20.2 List of Cookies in SAP SuccessFactors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428


Content

Change History

Learn about changes to the documentation for Data Protection and Privacy features.

2H 2021

Type of Change Description More Info

March 18th, 2022

Changed We added the missing prerequisites for Application and Candidates purge in Recruiting.

Prerequisites for Purging Applications and Candidate Profiles [page 397]Data Protection and Privacy in SAP SuccessFactors Recruiting Management [page 395]

Changed We added limitations and examples of the access control over DRTM purge requests.

Enabling Access Control to Purge Reports of DRTM Purge Requests [page 132]

January 21st, 2022

Changed We added a note to prevent the deletion of objects in DRTM Onboarding Data.

Permissions Required to Configure Data Retention Times [page 139]Configuring Retention Times for Specific Types of Data [page 143]

November 26th, 2021

Changed We added a detailed note regarding the performance of generating Change Audit reports.

Process for Generating Change Audit Reports [page 282]Creating a Change Audit Report [page 283]

November 19th, 2021

Changed We added information about base date configurations for inactive and active users.

Configuring Retention Times for MDF Custom Objects [page 262]Base Dates for Retention Time Calculation [page 151]

November 5th, 2021

Changed We have improved the performance of generating Change Audit reports and updated the descriptions accordingly.

Important Notes About Change Audit for Personal Data [page 274]Creating a Change Audit Report [page 283]

October 8th, 2021

Setting Up and Using Data Protection and PrivacyChange History PUBLIC 7


Changed We removed all the instructions related to configuring the Data Privacy Consent Statement in Career Site Builder, as this setting has been removed. The DPCS you configure for Recruiting now applies to career sites.

Data Privacy Consent Statements for Career Sites [page 377]

Changed Under the Read Audit section, we updated the title Read Access Tracking and Shared Users to Read Access Logging and Shared Users.

Read Access Logging and Shared Users [page 304]

Changed We updated the configuration details of anonymize attribute for sensitive fields.

Important Considerations for Configuring Sensitive Fields in Recruiting [page 329]

Changed We deleted the note of data blocking only available in Employee Central and Reporting.

Data Blocking [page 266]

Changed We added prerequisites for setting up data blocking for MDF objects.

Setting Up Data Blocking for MDF Objects [page 270]

New We added a new purge request type DRTM Clock In Clock Out Purge.

DRTM Purge Request Types [page 47]Data Included in the DRTM Clock In Clock Out Purge [page 91]

Changed We add a note about how to interpret RAL entries from Data Retention Management.

Interpreting a Read Audit Report [page 336]

Added We added an additional point in the results about a scenario when the approval is granted after a scheduled time of a scheduled purge request.

Generating Preview Report for a Scheduled Purge Request [page 171]Approving or Declining a Purge Request [page 173]

Added We added information about email notifications during a purge workflow.

Submitting a DRTM Purge Request for Approval [page 169]Generating Preview Report for a Scheduled Purge Request [page 171]Approving or Declining a Purge Request [page 173]

Added We added a section about cookies in SAP SuccessFactors. The Career Site Builder cookie information previously available in a separate topic is moved to the central list.

Cookie Handling in SAP SuccessFactors [page 425]List of Cookies in SAP SuccessFactors [page 428]


Change History

1H 2021


August 6, 2020

New Configure read audit for SAP SuccessFactors Work Zone.

Configuring Read Audit in SAP SuccessFactors Work Zone [page 330]

May 21, 2021

New Data Purge - You can now configure validation options for Employee Central integration with ERP, to enable the ERP system to react to the purge of employee data in Employee Central.

Configuring Validation Options for the Replication of Employee Data Purge [page 199]

Use of the Purge Status Overview in the Replication of Data Purge [page 200]

Added We added a note about data purge in Performance and Goals.

Important Notes About Data Purge and Data Retention Time Management [page 92]

Added A new Application field is added to Read Audit reports to indicate where the sensitive personal data was read.

Interpreting a Read Audit Report [page 336]

Changed We updated descriptions referring to the UI of Purge Request Monitor.

Submitting a DRTM Purge Request for Approval [page 169]

Generating Preview Report for a Scheduled Purge Request [page 171]

Reviewing a Purge Preview Report [page 172]

Approving or Declining a Purge Request [page 173]

Verifying Final Purge Results [page 174]

Added We added a note to remind you of the unique purge behavior of DRTM Audit Data Purge.

DRTM Audit Data Purge [page 61]

Verifying Final Purge Results [page 174]

Changed We have added information about fields that can be configured as sensitive in the read audit reports.


Changed We deleted unused cookies and added new cookies used in Career Site Builder-generated career site pages.

Added Added the RAL enhancement for Onboarding 1.0 and Onboarding 2.0

Important Notes About Read Audit [page 301]

Added Added E-Verify and US Form I-9 as part of data getting purged in Master Data purge.


Setting Up and Using Data Protection and PrivacyChange History PUBLIC 9


Changed Updated the configuration of Onboarding 1.0 RAL fields centrally using Manage Audit Configuration.

Configuring Read Audit for Fields in Onboarding 1.0 [page 324]

Changed Renamed Onboarding 2.0 to Onboarding. DRTM Purge Request Types [page 47]

Configuring Field Objects for Read Audit in Onboarding [page 321]

Running the Information Report [page 356]


Change History

1 Data Protection and Privacy in SAP SuccessFactors

Learn about data protection and privacy capabilities available in the SAP SuccessFactors HXM Suite.

Companies store a wide range of personal data on people, ranging from basic details like name and date of birth, to more potentially sensitive information such as religion or medical history. In order to be compliant with data privacy laws, companies need to ensure that they process and protect this data correctly.

The following data protection and privacy functions enable a company to process personal data in a clear and compliant manner:

Capability Description More Information

Data Purge [page 15] Erase personal data once it's no longer needed and the required retention time has passed.

Getting Started with Data Purge [page 15]

Data Blocking [page 266] Restrict the visibility of personal data based on a user's role.

Getting Started with Data Blocking [page 267]

Change Audit [page 272] See who has created, modified, or deleted personal data.

Getting Started with Change Audit for Personal Data [page 273]

Read Audit [page 300] See who has accessed sensitive personal data.

Getting Started with Read Audit [page 300]

Information Report [page 348] Compile a report containing all the personal data stored about someone.

Getting Started with the Information Report [page 348]

Consent Agreements [page 366] Inform people that their personal data will be stored and get their consent to store it.

Getting Started with the Consent Agreements [page 366]

TipYou can post questions or suggestions about data protection and privacy capabilities in the community forum at http://community.successfactors.com/t5/General-Data-Protection/bd-p/Data-Privacy-and-Protection .

NoteSAP SuccessFactors values data protection as essential and is fully committed to help customers complying with applicable regulations – including the requirements imposed by the General Data Protection Regulation (GDPR).

By delivering features and functionalities that are designed to strengthen data protection and security customers get valuable support in their compliance efforts. However it remains customer’s responsibility to

Setting Up and Using Data Protection and PrivacyData Protection and Privacy in SAP SuccessFactors PUBLIC 11

http://help.sap.com/disclaimer?site=http%3A%2F%2Fcommunity.successfactors.com%2Ft5%2FGeneral-Data-Protection%2Fbd-p%2FData-Privacy-and-Protection

evaluate legal requirements and implement, configure and use the features provided by SAP SuccessFactors in compliance with all applicable regulations.


Data Protection and Privacy in SAP SuccessFactors

2 Prerequisites for Using Data Protection and Privacy Functions

To make use of the data protection and privacy functions, you need to verify that you have met the prerequisites:

● Role-based permission (RBP) is enabled and set up so that you can use it to control access to data protection and privacy functions.

● Activate Attachment Manager. This is a prerequisite for using the Metadata Framework (MDF). To do this, please contact Product Support.

● Activate the Metadata Framework (MDF). To do this, just go to the Upgrade Center and switch on the Extension Center. This activates MDF automatically.

● If you use Position Management in Employee Central, update to the right to return data model.● Data protection and privacy functions require a unique, stable identifier for each user in your system. We use

the platform User ID for this purpose, so changing the User ID disrupts data protection and privacy functions.We are working on a solution (Assignment ID) but it is not fully supported yet. Do not make any changes to Assignment ID at this time.

New Data Model for Right to Return and Data Protection and Privacy [page 13]It is always important to be compliant with your local data protection and privacy laws, so we strongly recommend that you migrate to the new data model.

Caution About User ID Conversion [page 14]If you use data protection and privacy functions, avoid User ID conversion.

2.1 New Data Model for Right to Return and Data Protection and Privacy

It is always important to be compliant with your local data protection and privacy laws, so we strongly recommend that you migrate to the new data model.

From the Q1 2018 release, there is a new data model available for Right to Return. Migrating to this new data model is optional, but it is a prerequisite for using data protection and privacy functions in Position Management.

To migrate, go to the Upgrade Center and from the Important Upgrades section, select Position Management - Migrate Data Model for Right to Return.

TipAs mentioned, we strongly recommend that you perform the migration. Also, when doing so, migrate to your test instance first and check everything's in order there before final migration to production.

Setting Up and Using Data Protection and PrivacyPrerequisites for Using Data Protection and Privacy Functions PUBLIC 13

2.2 Caution About User ID Conversion

If you use data protection and privacy functions, avoid User ID conversion.

Each user in your SAP SuccessFactors system has a unique user ID and, in some cases, you may want to convert the existing user IDs in their system to a new value. This process is called "User ID conversion" and requires a special migration effort.

Most data protection and privacy functions require a unique, stable identifier for each user in your system. The platform User ID is one such identifier. Changing the User ID disrupts important data protection and privacy functions, such as data purge and audit reporting. Therefore, if you have data protection and privacy requirements, you shouldn’t convert User IDs.

CautionWe are in the process of introducing a new field called Assignment ID, which allows you to change the user identifier that is displayed in the user interface, while the immutable User ID is still used in the background and in integrations. However, it isn’t yet fully supported across the HXM Suite. Therefore, it's also not recommended for use with data protection and privacy functions.

Do not make any changes to Assignment ID at this time. By default, assignment ID has the same value as user ID. To reduce complexity and avoid potential impacts to data protection and privacy, ensure that assignment ID and user ID are always the same.

Related Information

Important Notes About Data Purge and Data Retention Time Management [page 92]Knowledge Base Article on User ID Conversion


Prerequisites for Using Data Protection and Privacy Functions

http://help.sap.com/disclaimer?site=https%3A%2F%2Flaunchpad.support.sap.com%2F%23%2Fnotes%2F2088176

3 Data Purge

The SAP SuccessFactors HXM Suite stores a wide range of information about your employees. Generally speaking, historical data should not be stored any longer than is required. Once the required retention time has passed, data should be purged. A data purge is a means of permanently removing data from storage.

For the purpose of data protection and privacy, you may be required to purge user data from your system after a certain length of time. You may also choose to purge user data simply because it no longer serves any business purpose.

To meet this requirement, SAP SuccessFactors provides the ability to purge different types of data across the HXM Suite, on a recurring schedule and based on configurable retention times.

3.1 Getting Started with Data Purge

Before you set up and use the data purge function, there are some general prerequisites you need to complete.

Procedure

1. Familiarize yourself with your local data protection and privacy laws.2. Go through this checklist and understand the following:

Check Item Action

Data purge with data retention time management Data Retention Time Management [page 16]

Prerequisites Prerequisites for Data Retention Time Management [page 17]

Data purge use cases Data Purge Use Cases [page 40]

Available purge types DRTM Purge Request Types [page 47]

Important notes and limitations Important Notes About Data Purge and Data Retention Time Management [page 92]

3. After you have understood the list of items in the checklist, start setting up the data purge function in your SAP SuccessFactors system.

Setting Up and Using Data Protection and PrivacyData Purge PUBLIC 15

Related Information

Enablement of Data Retention Time Management (DRTM) [page 112]Configuration of Data Retention Times [page 137]

3.2 Data Retention Time Management

Data retention time management (DRTM) is the recommended data purge solution for data protection and privacy. You can use DRTM purge requests to purge data based on configurable data retention times.

A DRTM purge request is a request type in the Data Retention Management tool that supports data retention time management (DRTM). When you use a DRTM purge request, it considers the retention time configured for each type of data and only purges data after the required retention time has passed.

To set up the data purge function with data retention time management, there are two steps:

1. Configure data retention times for each type of data, by country/region or legal entity and by user status.2. Set up a recurring purge job for each type of data you need to purge.

NoteData retention time management (DRTM) is the newer and more comprehensive purge functions in Data Retention Management. While it is generally not recommended for customers who use DRTM, the legacy purge function can still be used in some scenarios. Be aware that the legacy data purge function may not meet your data protection and privacy requirements. It doesn't cover the entire HXM Suite and it doesn't permit you to configure retention times for different countries or legal entities.

Related Information

Data Purge Use Cases [page 40]Data Retention Time [page 138]Check for Updates in Upgrade Center [page 221]Getting Started with Data Purge [page 15]DRTM Purge Request Types [page 47]


Data Purge

3.3 Prerequisites for Data Retention Time Management

Understand the prerequisites for using the data purge function with data retention time management (DRTM).

Prerequisite More Information

Data Retention Management (DRM 2.0) Enabling Data Retention Management [page 114]

Metadata Framework (MDF) Go to the Upgrade Center and switch on the Extension Center. This activates MDF automatically.

Sync user data from HRIS HRIS Sync of Fields Required for Data Purge [page 17]

Ensure that country/region records have values that are supported by the DRTM data purge function.

Country/Region Names Required for Data Purge [page 23]

Understand the important notes and limitations that apply to your system.


3.3.1 HRIS Sync of Fields Required for Data Purge

Data purge with data retention time management (DRTM) requires certain data from your HRIS. Whether you use Employee Central or import user data from an external HRIS, you need to ensure that the required user data fields are synced from your system-of-record to the SAP SuccessFactors Platform.

The DRTM data purge function requires the following user data from your HRIS:

● Country/Region - This is used to define the target users of a purge request and the relevant data retention time.

● Status - This is used to restrict a purge request to users or employments with a given status.● Termination date - This is used to calculate the data retention time for some types of purge request, including

the full purge of inactive users.

The exact system prerequisites depend on how your system is configured, as described in the following table.


HRIS Field For users managed in Employee CentralFor users imported from an external HRIS

Country/Region In most cases, you don't need to do anything.

By default, the country or region listed in the corporate address in Employee Central has a hard-coded sync mapping and is automatically included in your HRIS sync.

NoteIf you use another address type, such as home address or the address of the legal entity, then you need to ensure that they are included in the HRIS sync to the standard user field for country/region.

In most cases, you don't need to do anything.

Ensure that the standard user field for country/region exists in your system and that this record is regularly synced with the relevant HRIS field in your system-of-record.

This is a standard part of most implementations, so is likely to already be set up in your system.

Status You don't need to do anything.

The status of an employment in Employee Central has a hard-coded sync mapping and is automatically included in your HRIS sync.


Ensure that the standard user field status exists in your system and that this record is regularly synced with the relevant HRIS field in your system-of-record.


Termination Date In most cases, you don't need to do anything.

Ensure that the standard user field companyExitDate exists in your system and that an HRIS sync mapping is set up between the end-date field in Employee Central and the companyExitDate field.


You may need to set this up.

Ensure that the standard user field companyExitDate exists in your system and that this record is regularly synced with the relevant HRIS field in your system-of-record.

This may not have been necessary for you previously but it is required by DRTM data purge. If it isn't set up in your system already, set it up before you continue.

Adding the CompanyExitDate Field to the User Record [page 19]Most customers already have the standard user field companyExitDate configured in the system. If you don't, you need to add it before you can use the DRTM data purge function.

Syncing the Termination Date Between Employee Central and Standard User Fields [page 20]


Data Purge

Set up HRIS sync mapping between Employee Central and the standard user field <companyExitDate> so that you can use the DRTM data purge function to purge inactive users from the system.

Importing the Required HRIS Fields from an External System [page 22]Import the required HRIS data from your external system into SAP SuccessFactors so that it can be used by the data purge function with data retention time management.

Related Information

Prerequisites for Data Retention Time Management [page 17]

3.3.1.1 Adding the CompanyExitDate Field to the User Record

Most customers already have the standard user field companyExitDate configured in the system. If you don't, you need to add it before you can use the DRTM data purge function.

Prerequisites

You are an administrator with access to the Business Configuration UI.

Context

Adding companyExitDate to your data model with the Business Configuration UI allows you to proceed with setting up the data purge function but it does not enable you to see this field in the employee profile or in the employee export file. Later, you can choose to add it to the profile or export file as you would any other user information field.

If you don't have access to the Business Configuration UI, ask Product Support to add the following element to your data model:

Sample Code

<standard-element id="companyExitDate"> <label>Company Exit Date</label> </standard-element>


Procedure

1. Go to Admin Center Manage Business Configuration .

2. Go to Employee Profile Standard companyExitDate in the navigation pane.

If the companyExitDate field is not yet enabled in your system, it is marked with an X. If it is already enabled, it is marked with a checkmark and you do not need to complete this task.

3. Add a default label in the Label field.4. If necessary, click the localization icon to open a dialog and add labels in other languages in your system.5. Set the Enabled setting to Yes.6. Click Save to save your change.

Next Steps

To complete the minimum prerequisite steps so that you can proceed to set up the DRTM data purge function, proceed to configure the required sync between your HRIS and the SAP SuccessFactors platform. If you use Employee Central, you can do this with the Business Configuration UI. If you need to import these dates frosm an external HRIS, please contact Product Support.

3.3.1.2 Syncing the Termination Date Between Employee Central and Standard User Fields

Set up HRIS sync mapping between Employee Central and the standard user field <companyExitDate> so that you can use the DRTM data purge function to purge inactive users from the system.

Prerequisites


The standard element <companyExitDate> is already enabled in your data model.

Context

HRIS sync mapping for the termination date is not hard-coded, so you have to map the relevant fields between Employee Central and the SAP SuccessFactors Platform. If this sync is not set up correctly, the data purge function cannot work correctly.

If the standard element <companyExitDate> is not present in your Employee Export file, it is not enabled in your system and you cannot complete this task. You need to add this field to your system first.


Data Purge

If you do not have access to the Business Configuration UI in your system, you can also submit a request to Product Support to have the following XML added to your data model in the Provisioning application:

Sample Code

<hris-element-ref refid="employmentInfo"> <hris-mapping > <hris-field-ref refid="end-date"/> <standard-element-ref refid="companyExitDate"/> </hris-mapping></hris-element-ref>

Procedure


2. Go to Employee Central HRIS Elements employmentInfo in the navigation pane.3. Under HRIS Fields, find the row with <end-date> in the Identifier column.

4. In the row for <end-date>, click Details and scroll to the HRIS Sync Mapping section in the dialog window.

5. Use the Standard Field search box to find and select <companyExitDate>.

If you do not see <companyExitDate> in the search box, it is not enabled in your system. You need to add it before you can complete this task.

6. Leave the Entity Type field blank.7. Select Done and then save your changes.

Results

The effectivedated end date of an employment in Employee Central is now mapped to the user's company exit date in the SAP SuccessFactors Platform. This ensures the employment end date in Employee Central is used to calculate data retention times.

Next Steps

After the sync mapping is added, make sure that the user (userId) used for HRIS Sync is granted View and Edit permissions for this field.


3.3.1.3 Importing the Required HRIS Fields from an External System

Import the required HRIS data from your external system into SAP SuccessFactors so that it can be used by the data purge function with data retention time management.

Context

Data purge employment status and country/region or legal entity to define the target users of all DRTM purge requests. It uses termination date to calculate retention times for purging inactive users. To use data purge with data retention time management, you need to ensure these standard user data fields are populated with accurate information from your HRIS.

NoteIf you are using Employee Central, do not complete this task.

Procedure

1. Go to Admin Center Tools Employee Export .2. Open the CSV export file and verify whether the following fields are included:

○ Status - This should be "active" or "inactive".○ Country/Region - This should be the country or region of the user's current work location.○ companyExitDate - This should be present for inactive users who have left the company.

3. Check that all users in your export file have an employement status (active/inactive) and a country/region record.

4. Check that inactive users in your export file have a record for companyExitDate.5. Determine your next steps:

○ If any of the required fields is missing from your export file or the record is blank, then your current employee import process is not sufficient.Please contact SAP Cloud Support to have the required fields added to your import process.

○ If all of the required fields are present and contain records, then your current employee import process should be sufficient. Data purge uses the values of these records to define target users and calculate retention times.


Data Purge

3.3.2 Country/Region Names Required for Data Purge

Data purge with data retention time management (DRTM) expects certain known values in the standard user field for country/region. You need to ensure that the user record matches these known values.

If a user's country or region record doesn't match the expected value, the system can't recognize the user's country or region to determine the appropriate retention time and the user cannot be included in a DRTM purge request.

ExampleHere are some examples of a mismatch that could cause problems:

● The user record says "United States of America" but the system is expecting "United States".● The user record has a generic value like "Other" but the system is expecting a specific country or region.● You've enabled data retention time management for a country or region that has not yet been added to

your picklist for country/region.

Countries in DRTM data purge are defined by the MDF object for country/region. Each individual user record for Country needs to match a country defined in this object. Therefore, you need to ensure that the values contained in the standard user data field for country/region match the default country names that are defined in the MDF object for country/region.

The best way to do this depends on how your system is configured, as described in the following table.


If country/region field is configured in this way…

For users managed in Employee Central...

For users imported from an external HRIS...

As a free text field You don't need to do anything.

Country/region records have a hard-coded HRIS sync mapping. The string value of the HRIS field for country/region in Employee Central is always synced to the standard user field, whether it is configured as free text or a picklist.

You need to make sure that each user in your system has a country/region record that matches the country or region names in the MDF object for country/region. To do this, we recommended changing the MDF object for country/region to match the values used in your system, rather than changing each individual user record in your User import.

NoteWhen the country/region record is set up to be a free text field, there is always risk of a mismatch that causes errors in the data purge function. We recommend standardizing the country/region values in your system with a picklist.

NoteIt is also possible to manually change the values of the country/region record for each user in your system—either in the UI or in your import file—so that they match the default values in the MDF object for country/region. This approach is not recommended, however, because it is error-prone and not scalable for most companies.

With a legacy picklist (in CSV import) You don't need to do anything.

Country/region records have a hard-coded HRIS sync mapping. The string value of the HRIS field for country/region in Employee Central is always synced to the standard user field, whether it is configured as free text or a picklist.

You need to make sure that the options in your picklist for country/region match the country or region names in the MDF object for country/region. To do this, compare the external code of each option in your legacy picklist for country/region with the external code of its corresponding country or region in the MDF object for country/region.

If you find any discrepancies, update your legacy picklist so that it matches the MDF object for country/region.


Data Purge

If country/region field is configured in this way…

For users managed in Employee Central...

For users imported from an external HRIS...

With a migrated picklist (in Picklist Center)


Employee Central uses the MDF object for country/region and its associated MDF picklists to define countries used in the system, so the values in the user record should automatically be consistent with MDF.

To be sure, however, you can check the external codes of countries in your MDF picklist for country/region to verify that they match the MDF object for country/region.

You need to make sure that the options in your picklist for country/region match the country or region names in the MDF object for country/region. To do this, compare the external code of each option in your migrated MDF picklist for country/region with the corresponding external code in the MDF object for country/region.

In most cases, you don't need to do anything. After picklist migration, the external codes in the MDF picklist for country/region and the MDF object for country/region should be consistent.

To be sure, you can check the external codes of countries in your migrated MDF picklist for country/region to verify that they match the MDF object for country/region.

With the MDF picklist for ISO countries or regions.


The label in the MDF picklist for ISO countries or regions and the MDF object for country/region should be identical.

To be sure, however, you can check the external codes and labels of countries in the MDF picklist for ISO countries or regions to verify that they match the MDF object for country/region.

N/A

Checking Configuration of the Standard User Field for Country/Region [page 26]Check configuration of the standard user field for country/region to determine whether it is a free text field or a picklist and to identify the relevant picklist ID.

Checking If Picklists Have Been Migrated Yet [page 27]Check to see if picklists in your system have been migrated or not.

Match the MDF Object for Country/Region with Country/Region Values Used in Your System [page 28]As a prerequisite for using the DRTM data purge function, you may need to change the default value of country names in the MDF object for country/region so that they match the free text values that exist in your system.

Match a Legacy Picklist for Country/Region with MDF Object for Country/Region [page 29]As a prerequisite for using the DRTM data purge function, you may need to update your legacy picklist for country/region so that it matches the MDF object for country/region.


Match a Migrated Picklist for Country/Region with MDF Object for Country/Region [page 36]As a prerequisite for using the DRTM data purge function, you may want to verify that the external codes in your migrated MDF picklist for country/region match the external codes in the MDF object for country/region.

3.3.2.1 Checking Configuration of the Standard User Field for Country/Region

Check configuration of the standard user field for country/region to determine whether it is a free text field or a picklist and to identify the relevant picklist ID.

Prerequisites


Context

As a prerequisite to setting up the DRTM data purge function, you need to ensure that your system uses the required values. To do this, you need to know whether the user data field for country/region is configured as a free text field or as a picklist.

Data field configuration can be viewed using the Business Configuration UI or in the data model XML. If you do not have access to the Business Configuration UI in your system, you can also submit a request to Product Support to check this in your data model XML.

Procedure


2. Go to Employee Profile Standard in the navigation pane and select the field for country/region.3. Note the value in the Picklist configuration field.

○ If the value is No Selection, then it is a free text field.○ If there is a selected value, then it is a picklist. The selected value is the ID of the picklist.

4. Click Cancel to ensure that you don't actually make changes to your system configuration.


Data Purge

Next Steps

If the user data field for country/region is a free text field, proceed to match the MDF Country object with the country name values used in your system.

If the user data field for country/region is a picklist, determine whether it is a legacy picklist or if it has already been migrated to MDF.

3.3.2.2 Checking If Picklists Have Been Migrated Yet

Check to see if picklists in your system have been migrated or not.

Prerequisites

You either have permission to manage picklists or permission to access Platform Feature Settings.

Procedure

1. Go to Admin Center Picklist Center and look for a message at the top of the page.

○ Before migration, it says Legacy picklists have not been migrated yet and provides a link to Picklists Management page.

○ After migration, for the first 7 days, it says Congratulations, you can now manage all your picklists in Picklist Center. After that, there's no message. The Picklists Management page is no longer available.

○ If you can't see Picklist Center at all, you either lack the required permission or the Metadata Framework (MDF) isn't enabled yet. If MDF is not enabled, picklists have not been migrated yet.

2. If you don't have permission to manage picklists, go to Admin Center Platform Feature Settings and find the Unified Picklist Management checkbox.

○ If the checkbox is checked, picklists have been migrated.○ If it's unchecked, picklists have not been migrated yet.

NoteManually checking or unchecking the Unified Picklist Management checkbox has no effect. Although the UI appears to let you change it, no change is saved. When you reload the page, the checkbox resets to the accurate state, based the migration status.


3.3.2.3 Match the MDF Object for Country/Region with Country/Region Values Used in Your System

As a prerequisite for using the DRTM data purge function, you may need to change the default value of country names in the MDF object for country/region so that they match the free text values that exist in your system.

If the standard user field for country/region is configured as a free text field, there is always risk of a mismatch that causes errors in data purge. We recommend standardizing values using a picklist for country/region.

If you choose to use a free text field, you need to make sure that each user in your system has a user record that matches the country or region names in the MDF object for country/region. To do this, update the MDF object for country/region to match the values used in your system, rather than changing each individual user record.

NoteFor users managed in Employee Central, this should not be necessary. Employee Central always uses MDF to define countries or regions in the system and always syncs records with the platform, whether or not the standard user field is configured as free text or a picklist.

1. Updating the Default Name Value in the MDF Object for Country/Region [page 28]Update the default value of a country or region name in the MDF object for country/region so that it matches the free text values that are used in your system.

3.3.2.3.1 Updating the Default Name Value in the MDF Object for Country/Region

Update the default value of a country or region name in the MDF object for country/region so that it matches the free text values that are used in your system.

Prerequisites

● Your standard user field for country/region is configured as a free text field, not a picklist.● You have exported data in the MDF object for country/region and found externalName.defaultValue

values that don't match the ones used in your system.● You have permission to edit MDF object for country/region with the MDF Manage Data tool.

Context

Do not complete this task if you use a picklist to define value options in the standard user field for country/region. If you use a picklist, do not change default name values. Compare and match external codes instead.


Data Purge

Procedure

1. Go to Admin Center Tools Manage Data .2. Use the first search box to find and select the MDF object for country/region.3. For each country or region where there is a mismatch, use the second search box to find and select the country

or region you want to edit.

For example, if the current default value in the MDF object for country/region is United States but you use USA in your system, find United States in the menu.

4. Click Insert New Record to enter edit mode.5. In the dialog, select the effective date (the date on which you want the change to take effect) and then click

Proceed.6. Click the translation icon next to the country/region field to open the translation dialog.7. In the translation dialog, update the entry in the Default Value field so that it matches the country or region

name used in your system.

For example, if the current default value is United States but you want to use the name "USA", enter USA in the Default Value field.

8. Click Save to save your changes.9. Repeat steps for each country or region in the system where the default value doesn't match the values you

use.

Results

The default value of the country or region name is updated in the MDF object for country/region. The DRTM data purge function now expects users in this country or region to have a user record that matches the new value.

Task overview: Match the MDF Object for Country/Region with Country/Region Values Used in Your System [page 28]

3.3.2.4 Match a Legacy Picklist for Country/Region with MDF Object for Country/Region

As a prerequisite for using the DRTM data purge function, you may need to update your legacy picklist for country/region so that it matches the MDF object for country/region.

You need to make sure that the external code for each option value in your picklist for country/region is the same as the external code for its corresponding country or region in the MDF object for country/region. This ensures that user records in the system, as defined by the legacy picklist, match the values that are expected by the DRTM data purge function.


NoteFor users managed in Employee Central, this should not be necessary. Employee Central always uses MDF to define countries in the system and always syncs country/region records with the platform, whether the standard user field is configured as free text or a picklist.

1. Exporting Data in the MDF Object for Country/Region [page 30]Export data about each country or region defined in the MDF object for country/region so that you can compare it to the values used in the system and make sure that they match.

2. Checking External Codes for Country/Region in a Legacy Picklist [page 32]Check the external code for each country or region configured in a legacy picklist so that you can match them with external codes in the MDF object for country/region, as a prerequisite for using the DRTM data purge function.

3. Updating the Legacy Picklist for Country/Region to Match the MDF Object for Country/Region [page 34]Update the external codes in your legacy picklist for country/region so that they match the external codes used in the MDF object for country/region, to ensure that the standard user field for country/region can be recognized by the DRTM data purge function.

Related Information


3.3.2.4.1 Exporting Data in the MDF Object for Country/Region

Export data about each country or region defined in the MDF object for country/region so that you can compare it to the values used in the system and make sure that they match.

Prerequisites

You have the MDF object for country/region configured in your instance and permission to import and export its data.

Context

Matching the country or region values in your system with data in the MDF object for country/region is a prerequisite for using the DRTM data purge function. The exact data you need to match depends on how your system is configured.


Data Purge

If your standard user field for country/region is configured as a free text field, you need to match the default country or region name values in the MDF object for country/region with the country or region values used in the system.

If your standard user field for country/region is configured as a picklist, you need to match external codes in your Country picklist with external codes in the MDF object for country/region.

Procedure

1. Go to Admin Center Tools Import and Export Data .2. In Select the action to perform, select Export Data.3. In Select Generic Object, find and select the MDF object for country/region.4. Set Include dependencies to No.

5. Click Export.

6. Go to Admin Center Tools Monitor Job .

When the export job completes, it will appear on the job monitor.7. Find the export job for the MDF object for country/region and click Download Status to download the CSV

export file.8. Find the relevant columns in your export file so that you can compare them to the country or region values

used in your system.○ If your standard user field for country/region is configured as a picklist, match values in the code column

with external codes in your picklist. The code value is the external code for that country and by default it is the standard 3-character ISO code for that country.

○ If your standard user field for country/region is configured as a free text field, match the values in the externalName.defaultValue column with the values of the Country field in your system. This is the name of the country that is used to identify users and retention times during a data purge.

ExampleIn this example, you can see the external code for Argentina is ARG and the externalName.defaultValue is Argentina.


Next Steps

Compare the values of the code and externalName.defaultValue columns in your export file with the values in the Country field, however those are defined in your system, and make sure that they match.

Task overview: Match a Legacy Picklist for Country/Region with MDF Object for Country/Region [page 29]

Next task: Checking External Codes for Country/Region in a Legacy Picklist [page 32]

3.3.2.4.2 Checking External Codes for Country/Region in a Legacy Picklist

Check the external code for each country or region configured in a legacy picklist so that you can match them with external codes in the MDF object for country/region, as a prerequisite for using the DRTM data purge function.

Prerequisites

● The standard user field for country/region is configured to use a legacy picklist.● Your picklists have not yet been migrated to MDF.● You have identified the legacy picklist that is used to define options in the standard user field for country/

region.● You have permission to manage picklists.● You have exported data from the MDF object for country/region and found the external codes that your picklist

needs to match.

Context

If your legacy picklists have been migrated to MDF, you cannot complete this task. Use Picklist Center to check the migrated MDF picklist instead.

Procedure

1. Go to Admin Center Tools Picklists Management .2. Select Export all picklist(s).3. Click Submit to export legacy picklists.4. Click Download export to download and save the CSV export file.


Data Purge

The Download export button only appears when the export job is complete. If you have a large number of picklists, the export is run as a batch process. If you don't see the download option immediately, wait a few minutes and click Refresh. If you prefer not to wait, return to this page and proceed later.

5. Locate the ID of your picklist for country/region in the picklistId column of the export.

NoteThe exact ID of your legacy picklist for country/region is specific to your company and may vary. You may also have more than one picklist for countries configured in your system for different purposes. You want to locate the picklist that is associated with the standard user field for country/region. If you don't know which picklist this is, check configuration of the country/region field in the Business Configuration UI or in your data model XML.

6. Take note of the value in the external_code column for each row in the picklist for country/region so that you can compare them to the MDF object for country/region.

ExampleIn this example, you can see the external code of the picklist option for Argentina is ARG.

Next Steps

Compare the exported external codes for each option in the legacy picklist for country/region with the exported external codes in the MDF object for country/region to make sure that they match.

If you find any discrepancies, proceed to update the legacy picklist for country/region.


Previous task: Exporting Data in the MDF Object for Country/Region [page 30]

Next task: Updating the Legacy Picklist for Country/Region to Match the MDF Object for Country/Region [page 34]


3.3.2.4.3 Updating the Legacy Picklist for Country/Region to Match the MDF Object for Country/Region

Update the external codes in your legacy picklist for country/region so that they match the external codes used in the MDF object for country/region, to ensure that the standard user field for country/region can be recognized by the DRTM data purge function.

Prerequisites

● You have identified the legacy picklist used to define options in the standard user field for country/region.● You have exported your legacy picklist for country/region and the MDF object for country/region, compared the

relevant external codes, and identified discrepancies.

Procedure

1. Open your legacy picklist CSV export file.2. For each case in the legacy picklist file where there is a discrepancy between your picklist for country/region

and the MDF object for country/region, update your legacy picklist in the CSV file so that it matches the MDF object.

Here are types of discrepancy you may find:○ The external_code value of an option in the picklist for country/region differs from the code value of the

corresponding country or region in the MDF object for country/region.○ An option exists in your legacy picklist for country/region that doesn't correspond to a country or region in

the MDF object for country/region.○ A country or region exists in the MDF object for country/region that doesn't correspond to an existing

option in your legacy picklist for country/region.

ExampleHere are some examples of discrepancies and how to correct them.

First, the external code of the picklist for country/region option for Austria is AT and should be updated to the 3-character code AUT as defined in the MDF object.

Second, the legacy picklist for country/region includes an option Asia/Pacific Other that doesn't correspond to an actual country or region. You need to specify an actual country or region for each user to include them in a data purge request. For example, if a user with the record Asia/Pacific Other is actually based in American Samoa, add a row in the picklist file for American Samoa instead, using the external code ASM as defined in the MDF object.

Third, the legacy picklist for country/region does not include a row for Andorra but you want to enable DRTM for that country or region. You need to add a row in your picklist file for Andorra using the external code AND as defined in the MDF object for country/region.


Data Purge

Invalid External Codes in Legacy Picklist for Country/Region

Correct External Codes in MDF Object for Country/Region

Corrected Legacy Picklist for Country/Region

3. Import the updated picklists to your system.

Results

The options in your legacy picklist for country/region now match the MDF object for country/region. This ensures that users in this country or region have a record that can be recognized by the DRTM data purge function.


Previous task: Checking External Codes for Country/Region in a Legacy Picklist [page 32]


3.3.2.5 Match a Migrated Picklist for Country/Region with MDF Object for Country/Region

As a prerequisite for using the DRTM data purge function, you may want to verify that the external codes in your migrated MDF picklist for country/region match the external codes in the MDF object for country/region.

In most cases, you don't need to do anything. After your legacy picklists are migrated to MDF, the external codes in the MDF picklist for country/region and the MDF object for country/region should be consistent. To be sure, you can check the external codes of countries in your migrated MDF picklist for country/region to verify that they match the MDF object for country/region.

NoteFor users managed in Employee Central, this should not be necessary. Employee Central always uses MDF to define countries in the system and always syncs Country records with the platform, whether the standard user field is configured as free text or a picklist.

1. Checking and Updating a Migrated Picklist for Country/Picklist [page 36]Check the "non-unique external code" for each country or region in your migrated picklist for country/region, to be sure that they match the external codes in the MDF object for country/region, as a prerequisite for using the DRTM data purge function.

3.3.2.5.1 Checking and Updating a Migrated Picklist for Country/Picklist

Check the "non-unique external code" for each country or region in your migrated picklist for country/region, to be sure that they match the external codes in the MDF object for country/region, as a prerequisite for using the DRTM data purge function.

Prerequisites

● Your standard user field for country/region is configured as a legacy picklist.● You have identified the legacy picklist that is used to define options in the standard user field for country/

region.● Your picklists have been migrated to MDF so they can be managed in Picklist Center.● You have permission to access Picklist Center.● You have permission to manage picklists.● You have exported data from the MDF object for country/region and found the external codes that your picklist

needs to match.


Data Purge

Context

Complete this task if the standard user field for country/region is configured to use a picklist for country/region that has been migrated to MDF. If you use a free text field for this record, update the default country or region name values in the MDF object for country/region instead.

In most cases, these values are synced during your picklist migration and should already match, so it is likely that no additional action is required. However, to be sure, you can verify this in Picklist Center.

Procedure

1. Go to Admin Center Tools Picklist Center .2. In the Picklist Search field, find and select the name of your migrated MDF picklist for country/region.

NoteThe exact name of your migrated picklist for country/region as it appears in the search box is specific to your company and may vary. You may also have more than one picklist for countries configured in your system for different purposes. You want to locate the picklist that is associated with the standard user field for country/region. If you don't which picklist this is, check configuration of the field for country/region in the Business Configuration UI or in your data model XML.

3. Take note of the value in the Non-unique External Code column for each row in the picklist for country/region so that you can compare them to the MDF object for country/region.

The Non-unique External Code is the external code of a legacy picklist that was migrated to MDF and it is still used by some applications as the identifier of the migrated picklist, so it needs to match the MDF object for country/region.

ExampleIn this example, you can see the Non-unique External Code of the picklist option for Argentina is ARG.

Non-Unique External Codes in a Migrated Picklist for Country/Region

4. Identify cases where there is a discrepancy between your migrated picklist for country/region and the MDF object for country/region.

Here are types of discrepancy you may find:


○ The Non-unique External Code value of an option in the picklist for country/region differs from the code value of the corresponding country or region in the MDF object for country/region.

○ An option exists in your migrated picklist for country/region that doesn't correspond to a country or region in the MDF object for country/region.

○ A country or region exists in the MDF object for country/region that doesn't correspond to an existing option in your migrated picklist for country/region.

ExampleHere are some examples of discrepancies and what you would need to do to correct them.

First, the external code of the picklist for country/region option for Austria is AT and should be updated to the 3-character code AUT as defined in the MDF object.

Second, the legacy picklist for country/region includes an option Asia/Pacific Other that doesn't correspond to an actual country or region. You need to specify an actual country or region for each user to include them in a data purge request. For example, if a user with the record Asia/Pacific Other is actually based in American Samoa, add a row in the picklist file for American Samoa instead, using the external code ASM as defined in the MDF object.

Third, the legacy picklist for country/region does not include a row for Andorra but you want to enable DRTM for that country or region. You need to add a row in your picklist file for Andorra using the external code AND as defined in the MDF object for country/region.

Corrected Legacy Picklist for Country/Region

5. For each discrepancy you identified, update the picklist accordingly so that it matches the MDF object for country/region.a. Click Insert New Record to enter edit mode.b. In the dialog, select the effective date (the date on which you want the change to take effect), then click

Proceed.c. Update the Non-unique External Code of any existing option, as needed.

ExampleFor example, change the Non-unique External Code for Austria from AT to AUT.

d. To add a new picklist option, scroll down to the blank row at the bottom of the page, click Details, and fill out the required fields as needed so that they match the corresponding country or region in the MDF object for country/region. Then click Done.

ExampleFor example, you might add a new picklist option for Andorra as shown here.


Data Purge

Adding a New Option to the MDF Picklist for Country/Region

e. Click Save to save your changes to the picklist.

Results

The options in your migrated picklist for country/region now match the MDF object for country/region. This ensures that users in this country or region have a user record that can be recognized by the DRTM data purge function.

Task overview: Match a Migrated Picklist for Country/Region with MDF Object for Country/Region [page 36]


3.4 Data Purge Use Cases

Here are the primary use cases for using data purge in SAP SuccessFactors and our recommendations for how to set them up.

Data purge with data retention management (DRTM) enables you to:

● Purge inactive users, along with all their data, based on a single, common retention time● Purge specific data, for one SAP SuccessFactors solution and for either active and inactive users, based on a

specified retention time for that type of data.● Purge all audit data for all users, both active and inactive, based on a different retention time for each SAP

SuccessFactors solution.● Purge external users in one SAP SuccessFactors solution. Different solutions handle external users differently,

so the data purge method varies.

Purge of Inactive Users and All Data [page 40]For data protection and privacy, you may be required to completely purge inactive users from your system along with all their data, based on a single, common retention time.

Purge of Specific Data for One SAP SuccessFactors Solution [page 42]For data protection and privacy, you may be required to purge a specific type of data, in one SAP SuccessFactors solution, based on a different retention time.

Purge of Audit Data [page 44]For data protection and privacy, you may be required to purge all data stored in the audit logs after it's no longer needed for audit purposes.

Purge of External Users [page 46]Some SAP SuccessFactors solutions store data by or about people who are external to your organization. You can't purge all external users with the standard data purge solution. The data purge process varies for each type of external user.

Best Practice for Purging Data Targeting Large Number of Users [page 47]The planning of implementation projects involving data purge should consider time spent on purging data targeting large number of users.

3.4.1 Purge of Inactive Users and All Data

For data protection and privacy, you may be required to completely purge inactive users from your system along with all their data, based on a single, common retention time.

Use Case: I want to do a full purge of inactive users and their data.

Your data protection and privacy policy may require you to periodically purge inactive users from your system, after the required retention time has passed.

In this scenario, you want to make sure that all personal data is eventually purged from the system when it is no longer needed. You want to purge users and user accounts, along with any data across the HXM Suite that is


Data Purge

associated with those users, based on a single, common retention time. You do not need to purge different types of data for inactive users at different times.

Recommendations

● Use the full master data purge so that you can purge data across the HXM Suite with a single process.● Configure a retention time for the master data purge, for all countries in your system, even if not required to do

so by local law. This simplifies your implementation with the use of a single tool (DRTM) and ensures that you are ready to meet future data purge requirements as they arise.

● Configure a retention time for the master data purge that it is longer than the retention times for all other types of data. This ensures that module data is purged first and that module retention times are not overridden by the master data purge.

Here's what you need to do:

Steps Description Details

Meet prerequisites. Data retention is built on fundamental technology in SAP SuccessFactors. Before you can begin, you must make sure that you meet the basic prerequisites.


Understand non-standard purge processes.

Most customers and most configurations can follow the standard purge process using data retention time management (DRTM). However, some customers and some configurations have non-standard purge processes.

Before you begin, review these exceptions to see if they apply to you.

Non-Standard Purge Processes [page 226]

Understand master data purge. The master data purge is a powerful purge function that affects data across the HXM Suite. Before you begin using it, be sure to understand how it works.

DRTM Master Data Purge [page 54]

Enable data retention time management (DRTM).

For this use case, enable the DRTM Master Data Purge object during the set-up process.

Enablement of Data Retention Time Management (DRTM) [page 112]

Configure retention times. Configure a retention time for the master data purge of inactive users, for each country/region or legal entity in your system.

Configuration of Data Retention Times [page 137]



Set up purge roles and permissions. Design your purge process and use role-based permissions to ensure transparency and limit access to this powerful data purge function.

Recommended Permission Settings for Data Purge Functions [page 128]

Use master data purge. You are now ready to begin testing and using the full master data purge, with data retention time management.

Check for Updates in Upgrade Center [page 221]

Legal holds If necessary, you can place a legal hold on the data for a specific user so that it is not purged.

Legal Holds on Data [page 214]

Related Information

Data Purge Use Cases [page 40]

3.4.2 Purge of Specific Data for One SAP SuccessFactors Solution

For data protection and privacy, you may be required to purge a specific type of data, in one SAP SuccessFactors solution, based on a different retention time.

Use Case: I want to purge a specific type of data, for active or inactive users, based on a retention time specific to that type of data.

Your data protection and privacy policy may require you to periodically purge some types of data based on a specific retention time for that type of data. You may need to do this even when users are still active.

In this scenario, you only want to purge a certain type of data, not the users themselves. You do not want to delete the underlying user account and you do not want to remove other types of data. You just want to include a specific type of data and a specific group of users in your data purge.

Recommendations

● If you have this requirement for any type of data, enable it for all types of data in your system. Later, you can use purge request rules to remove the specific data you need to purge.


Data Purge

● Configure retention times for all countries in your system, even if not required to do so by local law. This simplifies your implementation with the use of a single tool (DRTM) and ensures that you are ready to meet future data purge requirements as they arise.

● Configure retention time for each type of data that it is shorter than the retention time of your master data purge. This ensures that retention times you configure for each type of data are not overridden by the master data purge.

Here's what you need to do:


Meet prerequisites. Data retention is built on fundamental technology in SAP SuccessFactors. Before you can begin, make sure that you meet the basic prerequisites.


Understand non-standard purge processes.

Most customers and most configurations can follow the standard purge process using data retention time management (DRTM). However, some customers and some configurations have non-standard purge processes.

Before you begin, review these exceptions to see if they apply to you.

Non-Standard Purge Processes [page 226]

Enable data retention time management (DRTM).

For this use case, you should enable all of the DRTM objects available in your system. Doing this now, during set-up, prepares you for future data purge requirements, for any type of data.

Later, when you set up purge requests, you can control which types of data you actually want to purge and when.


Configure retention times. Configure a retention time for the specific type of data you want to purge, for each country/region or legal entity in your system.


Set up purge roles and permissions. Design your purge process and use role-based permissions to ensure transparency and limit access to this powerful data purge function.




Use data purge. You are now ready to begin testing and using data purge for specific types of data, with data retention time management. You can create and run separate purge requests for each type of data you want to purge.

Check for Updates in Upgrade Center [page 221]

Legal holds If necessary, you can place a legal hold on the data for a specific user so that it is not purged.

Legal Holds on Data [page 214]

Related Information


3.4.3 Purge of Audit Data

For data protection and privacy, you may be required to purge all data stored in the audit logs after it's no longer needed for audit purposes.

Use Case: I want to purge audit data when it is no longer needed, for both active and inactive users.

You may be required to enable audit logging of personal data for data protection and privacy. Audit logging allows you to generate audit reports when required, about transactions in your system.

However, you may only be required to provide these audit reports for a certain period of time. Your data protection and privacy policy may also require you to periodically purge audit data after it is no longer needed.

In this scenario, it doesn't matter to you whether users are active or inactive. You want to purge all audit data for all users, regardless of employment status. You no longer need to keep this data for the purpose of generating audit reports, so you want to purge it from your system.

NoteIn context of the DRTM audit data purge, "audit data" refers to personal data captured in Change Audit and Read Audit reports for data protection and privacy. It does not include any other kinds of audit data or functionality in other parts of the HXM Suite.

CautionAfter audit data is purged, you can no longer use it to generate audit reports.


Data Purge

To purge audit data, you have two options:

Audit Data Purge Option Description Details

Purge audit data for inactive users only To purge all audit data for inactive users only, use the DRTM Master Data purge. Audit data, like all other types of data, is included in the master data purge.

Choose this option if your only requirement is to make sure audit data is eventually removed, along with all other personal data. This is the simplest option.

You do not need to configure a different retention time for audit data.

Purge of Inactive Users and All Data [page 40]

Purge audit data for both active and inactive users

To purge audit data only, for both active and inactive users, use the DRTM Audit Data purge.

Choose this option only if the master data purge of inactive users is insufficient. This may be the case for two reasons. First, you may specifically want to include audit data for active users in your purge. Second, you may want to specify different retention times for different types of audit data. If either of these is true, use this option.

To use the DRTM Audit Data purge, you need to configure a retention time for audit data in each SAP SuccessFactors solution (Learning, Compensation, Recruiting, etc.).

Purging Audit Data for Active and Inactive Users with DRTM [page 165]

NoteYou cannot run a purge of audit data for active users only.

You cannot run a purge of audit data for just inactive users with a different retention time than the master data purge. The only way to purge audit data just for inactive users only is to use the master data purge, with a single, common retention time for all data.

Related Information

Data Purge Use Cases [page 40]Purge of Audit Data [page 44]


DRTM Audit Data Purge [page 61]Configuring Retention Times for Audit Data [page 146]Purging Audit Data for Active and Inactive Users with DRTM [page 165]Audit Data Purge Objects [page 149]

3.4.4 Purge of External Users

Some SAP SuccessFactors solutions store data by or about people who are external to your organization. You can't purge all external users with the standard data purge solution. The data purge process varies for each type of external user.

Different solutions handle external users differently, so the data purge method varies. Here's the process for different solutions that store external user data.

Solution Purge Process

Performance Management For external feedback, the responder's e-mail address is the only identification data. Currently, you can NOT purge their identification data.

We only purge "Ask for Feedback" responses from external users, not their e-mail address.

NoteExternal users in Performance Management are not created as platform users in the system and they do not have a username.

Learning If you have learning sites with external users and if you are integrated with Platform, then you cannot run a partial data purge of the external users by yourself. Please create a support ticket.

If you are not integrated with Platform, the native-user processes allow you to purge data. You do not need a support ticket.

If you are integrated with Platform and you want to do a full data purge of external users, you can use the master data purge. You do not need a support ticket.

360 Reviews As the feedback from external raters in 360 Degree Multi-rater is captured within the application, the feedback comments from external users are purged using the 360 Reviews purge object. The personal data of external users is purged using the "DRTM Master Data Purge" function.


Data Purge

Solution Purge Process

Recruiting The Recruiting Management allows you to purge the external candidates.

Onboarding Onboarding allows you to purge pre-day one and non pre-day one onboardees.

Pre-day one users will be marked as Inactive and later will be purged as part of the Master/Inactive user purge.

SAP Jam Alumni Data in SAP Jam Collaboration [page 109]

Related Information


3.4.5 Best Practice for Purging Data Targeting Large Number of Users

The planning of implementation projects involving data purge should consider time spent on purging data targeting large number of users.

When the number of target users exceeds 100,000, you need to plan ahead to avoid implementation project delays caused by longer than expected purge process. In addition, a complex data structure affects the performance of purge functions. For example, the purge process takes much longer to complete when your instance is integrated with SAP SuccessFactors Learning.

To ensure that the implementation project is delivered on time, you need to perform a test batch purge targeting 10,000 users. When planning the schedule of the implementation project, use the time spent on the test purge as a benchmark and reserve enough time for purge jobs.

3.5 DRTM Purge Request Types

Find the DRTM purge request types that are available to you, based on the SAP SuccessFactors solutions you use.


Each DRTM purge request includes one or more purge objects. A purge object defines a specific type of data that is included, or that can be included, in the purge request. You can configure a different retention time for each purge object.


NoteMDF Custom Objects do not have a dedicated purge request type. Instead, each can be registered as member of a particular module purge group and then purged together with the other objects for in that group. For example, if you register an object as a member of the Time Management purge group, the data in that object is purged with the DRTM Time Management purge request type. DRTM Data Purge for MDF Custom Objects [page 258]

Data Purge Request Types

Solution Purge Request Type More Information

All DRTM Master Data DRTM Master Data Purge [page 54]

All DRTM Audit Data DRTM Audit Data Purge [page 61]

NoteAudit data is also included in the master data purge. If you only need to purge audit data for inactive users, along with all their other data, use the DRTM Master Data purge instead.

Calibration DRTM CalibrationPurge includes: Subject in session, Subject Name, Subject Rank, Subject Calibration Rating, Subject Comment, Subject discussion flag.Purges subjects from finalized calibration sessions, and from deleted sessions that were finalized.

Purges subjects from finalized calibration sessions, and from deleted sessionsDB level: the row in cal_session_subject/feedback/cal_audit_trail/cal_subject_rank for the subject for the session which meets data retention time

Compensation DRTM Compensation/Variable Pay

Data Included in the DRTM Compensation/Variable Pay Purge [page 65]


Data Purge


Compensation DRTM Rewards and Recognition

Purges all fields, which are stored in the SpotAwards MDF Object.

NoteThis purge request type supports MDF custom objects. You can associate an MDF custom object with this purge request type so that personal data contained in that object is included in the purge.

Employee Central DRTM Benefits Management Data Included in the DRTM Benefits Purge [page 64]


Employee Central DRTM Employment Information

Data Included in the DRTM Employment Information Purge [page 65]


Employee Central DRTM Person Information Data Included in the DRTM Person Information Purge [page 81]



Employee Central DRTM Time Management Data Included in the DRTM Time Management Purge [page 84]


Employee Central DRTM Workflows Data Included in the DRTM Workflows Purge [page 85]

Employee Central Payroll DRTM Payroll Results Purges payroll results of employees, which are stored in MDF object (EmployeePayrollRunResults).

Purge includes: All fields of MDF object EmployeePayrollRunResults

Employee Central Payroll DRTM Payroll Data Maintenance Task

Purges payroll data maintenance task objects of employees, which are stored in MDF object (PayrollDataMaintenanceTask).

Employee Profile DRTM Employee Profile Data Included in the DRTM Employee Profile Purge [page 66]

Learning DRTM Learning Data Included in the DRTM Learning Data Purge [page 67]


Data Purge


Onboarding 1.0 DRTM Onboarding 1.0 Purge Purges candidate information.

Purge includes:

● Onboarding Data Dictionary fields (HRData) including custom fields

● Documents stored in Document Center

● MDF Objects and the fields under it

● OnboardingCandidateInfo● OnboardingProcess and

all the MDF objects under it

● New Hire Activities

Onboarding DRTM Email Services Data Purge

Purges all the email messages which are triggered by the Email framework and are older than the input value Number of days.

Onboarding DRTM Onboarding Purge Data Included in the DRTM Onboarding Purge [page 88]

Performance and Goals DRTM 360 Reviews Purges the completed 360 forms for either active or inactive users.

Performance and Goals DRTM Continuous Performance Purge

Purges all information stored in Activity, Achievement, Other Topic, Coaching Advice, Feedback, and Meeting Snapshot.




Performance and Goals DRTM Goal Management Purge

Purges all goals and sub-goals fields for either active or inactive users.

Performance and Goals DRTM Performance Reviews Data Included in the DRTM Performance Reviews Purge [page 79]

Recruiting DRTM Inactive Candidate Purge

Candidates are purged in the Recruiting Management using DRTM based on the Application status.

DRTM Inactive Candidate Purge Criteria [page 63]

Recruiting DRTM Inactive Application Purge

Applications are purged in the Recruiting Management using DRTM based on their status.

Application Purge Behavior [page 402]

Recruiting DRTM Recruiting Read Access Log Purge

Purges read access log data for external candidates.

Succession and Development DRTM Career Worksheet Purges target roles and data related to the target roles.

Succession and Development DRTM Learning Activity Purge Purges all data contained in a user's learning activities and all references to development objectives associated with them if there is any.

NoteThis purge type only covers learning activity in Development. Other parts of SAP SuccessFactors also have learning activity data. For example, Learning can add the learning activity information and has the DRTM Learning Data purge which is used to purge personal data from the users' learning profiles and users' learning activities.


Data Purge


Succession and Development DRTM Development Objective Purges goals and references to learning activities for all goal plans belonging to the user.

NoteWhen the autosync attribute is set to "false" in the Goals section of the Performance Review template, and the Development goals are purged using DRTM Development Objective, the development goals will NOT be removed from the Performance Review form.

The development goals will be removed from the Performance Review form when the "autosync" attribute is set to "true" in the Goals section of the Performance Form template, and the Development goals are purged using DRTM Development Objective.

If you use the legacy Learning system, both the development goals and the associated learning activities will be purged.



Succession and Development DRTM Mentoring Program Data Included in the DRTM Mentoring Program Purge [page 78]


Succession and Development DRTM Succession Data Included in the DRTM Succession Purge [page 82]

Time Tracking DRTM Clock In Clock Out Purge

Data Included in the DRTM Clock In Clock Out Purge [page 91]

Related Information

Data Retention Time Management [page 16]Data Retention Time [page 138]DRTM Purge Permissions [page 130]Base Dates for Retention Time Calculation [page 151]DRTM Purge Permissions [page 130]Base Dates for Retention Time Calculation [page 151]

3.5.1 DRTM Master Data Purge

Use the DRTM Master Data purge type to purge inactive users and their associated data based on a single, common retention time.

A master data purge removes inactive users from your instance, along with their associated data across the HXM Suite, including audit data.

A master data purge is set up, approved, and run in much the same way as any other purge request. However, the resulting purge behavior differs from that of other DRTM purge types in some important ways.


Data Purge

Caution● The master data purge is a full purge of data across the SAP SuccessFactors HXM Suite, in addition to

standard user information and the underlying user account. All data that is purged by any of other DRTM purge types is also purged by a DRTM Master Data purge.

● The master data purge is based on a common retention time for all types of data in the purge. The configured retention time for DRTM Master Data overrides the retention time that is configured for any other DRTM purge objects.

● During a master data purge, some system identifiers are retained or anonymized and are not fully purged. These identifiers are essential to the proper functioning of the system and cannot be purged.

System Prerequisites for Using the Master Data Purge

● Inactive users have a termination date on record, either in Employee Central or imported from your system-of-record to the companyExitDate field.

● You have enabled the DRTM Master Data object in Upgrade Center.● If you use SAP SuccessFactors Learning the user who submits the purge request must have a matching admin

ID and user ID in Learning.The SAP SuccessFactors platform user_sysid must match the admin ID and the user (learner) ID exactly. For example, if your SAP SuccessFactors platform user is jdoe, then you must have an admin id jdoe (exact match) and a user ID jdoe in Learning. This is because the master data purge calls an API for both the get report and the delete (purge) user APIs. Learning takes the user_sysid from the SAP SuccessFactors platform and plugs it into the permissions to call the API in Learning. So a jdoe in SAP SuccessFactors platform calls the API as a jdoe in Learning.

User Permissions Required to Use the Master Data Purge

To successfully complete a DRTM Master Data purge, the user who creates and submits the purge request, must have the following permissions.

● Manage Users permission for the target population that is included in the purge.For example, to run a master data purge of all inactive users in Germany, the user who initiates the purge request must be assigned to a permission role that includes the Manage Users permission and has a target population that includes inactive users in Germany.

● Security workflows in SAP SuccessFactors LearningIf you use SAP SuccessFactors Learning, the matching user must have permission to the security workflows View Student and Delete Student. Security workflows are the LMS equivalent of role-based permissions (RBP), but you set them up in the LMS.

Retention Time

Retention time for the master data purge is calculated from the inactive user's termination date.


Because it overrides the configured retention times for all other types of data, the retention time for the DRTM Master Data purge should always be longer than the retention time for any other DRTM purge request types.

Data Included in the Master Data Purge

The master data purge is a full purge of data across the SAP SuccessFactors HXM Suite.

When setting up a DRTM Master Data purge request, you cannot select which purge objects or types of data to include. All purge objects and all types of data are always included in the purge.

A DRTM Master Data purge includes the following data.

Data Type More Information

User identifiers and user account User Identifiers Included in the DRTM Master Data Purge [page 57]

Standard user data (like name, job title, and phone number) User Data Included in the DRTM Master Data Purge [page 57]

Person and Employment identifiers in Employee Central Employee Central Identifiers Included in the DRTM Master Data Purge [page 58]

Some Employee Central objects and data that are not included in other DRTM purge types

Employee Central Data Included Only in the DRTM Master Data Purge [page 60]

Some Compensation objects and data Compensation Data Included in the DRTM Master Data Purge [page 60]

All purge objects and data in all other DRTM purge types See details provided about data included in each DRTM purge type.

User Identifiers Included in the DRTM Master Data Purge [page 57]Learn how essential User identifiers are handled during a master data purge.

User Data Included in the DRTM Master Data Purge [page 57]Learn how standard User data is handled during a master data purge.

Employee Central Identifiers Included in the DRTM Master Data Purge [page 58]Learn how essential system identifiers in Employee Central are handled during a master data purge.

Employee Central Data Included Only in the DRTM Master Data Purge [page 60]Learn about types of Employee Central data that are included only in the master data purge.

Compensation Data Included in the DRTM Master Data Purge [page 60]Learn about types of Compensation data that are included in the master data purge.


Data Purge

3.5.1.1 User Identifiers Included in the DRTM Master Data Purge

Learn how essential User identifiers are handled during a master data purge.

Some unique system identifiers are used to define users in the system and are required for proper functioning of the application. These cannot be entirely removed by a data purge. Instead, during a master data purge these fields are either retained or anonymized.

System Identifier Result of Master Data Purge

users_sys_id Record retained and unchanged.

users_sys_internal_id Record retained and unchanged.

users_sys_username Record anonymized. Replaced with "PURGED_RECORD", plus a unique internal ID code.

users_sys_firstname Record anonymized. Replaced with "Purged User".

users_sys_lastname Record anonymized. Replaced with "Purged User".

assignment_id_external Record retained and unchanged.

Parent topic: DRTM Master Data Purge [page 54]

Related Information

User Data Included in the DRTM Master Data Purge [page 57]Employee Central Identifiers Included in the DRTM Master Data Purge [page 58]Employee Central Data Included Only in the DRTM Master Data Purge [page 60]Compensation Data Included in the DRTM Master Data Purge [page 60]

3.5.1.2 User Data Included in the DRTM Master Data Purge

Learn how standard User data is handled during a master data purge.

All standard user data fields in the users_sysinfo table that are not required as system identifiers are permanently purged. Most records are set to NULL. If a field cannot be nullified, data is replaced with a generic placeholder value, such as "Unknown" or "N/A".

The following User tables are also entirely purged:

● user_account● users_info


● user_customfields● user_rel_map● sm_user_info● ext_profile_inf


Related Information

User Identifiers Included in the DRTM Master Data Purge [page 57]Employee Central Identifiers Included in the DRTM Master Data Purge [page 58]Employee Central Data Included Only in the DRTM Master Data Purge [page 60]Compensation Data Included in the DRTM Master Data Purge [page 60]

3.5.1.3 Employee Central Identifiers Included in the DRTM Master Data Purge

Learn how essential system identifiers in Employee Central are handled during a master data purge.

Some unique system identifiers are used to define users in the system and are required for proper functioning of the application. These identifiers can’t be entirely removed by a data purge. Instead, during a master data purge these fields are either retained or anonymized.


Person NoteThis entity is used with Employee Central only.

The following fields in the per_person table are retained and unchanged:

● person_id● person_id_external● per_person_uuid● users_sys_id● created_by● created_date● last_modified_by● last_modified_date

All other fields in the per_person table are purged and set to NULL.


Data Purge


Personal Info NoteThis entity is used with Employee Central only.

The following fields in the emp_personal_info table are retained and unchanged:

● person_id● person_info_id● users_sys_id● created_by● created_date● last_modified_by● last_modified_date

All other fields in the emp_personal_info table are purged. Most records are set to NULL. If a field can’t be nullified, data is replaced with a generic placeholder value, such as "Anonymous".

Employment Info NoteThis entity is used with Employee Central only.

The following fields in the emp_employment_info table are retained and unchanged:

● employment_id● person_id● users_sys_id● created_by● created_date● last_modified_by● last_modified_date● assignment_id_external (This record is present for all

users, with or without Employee Central.)

The following fields are anonymized.

● start_date is set to current date.● is_ec_system_of_record is set to 0.

All other fields in the emp_employment_info table are purged and set to NULL.



Related Information

User Identifiers Included in the DRTM Master Data Purge [page 57]User Data Included in the DRTM Master Data Purge [page 57]Employee Central Data Included Only in the DRTM Master Data Purge [page 60]Compensation Data Included in the DRTM Master Data Purge [page 60]

3.5.1.4 Employee Central Data Included Only in the DRTM Master Data Purge

Learn about types of Employee Central data that are included only in the master data purge.

The following Employee Central objects can only be purged with a DRTM Master Data purge request:

● Work Permit● Job Information● National ID● Work Orders● Biographical Information

The data in these objects is not included in any other Employee Central purge request and cannot be purged separately based on a different retention time.


Related Information

User Identifiers Included in the DRTM Master Data Purge [page 57]User Data Included in the DRTM Master Data Purge [page 57]Employee Central Identifiers Included in the DRTM Master Data Purge [page 58]Compensation Data Included in the DRTM Master Data Purge [page 60]

3.5.1.5 Compensation Data Included in the DRTM Master Data Purge

Learn about types of Compensation data that are included in the master data purge.

The following objects are purged with a DRTM Master Data purge request,

● Data in the comp_entry table● Statements associated with the user


Data Purge

● Compensation Guideline Models● Forecast data● Employee history● Folder map entries of in progress forms

NoteWe advise you to move in progress forms associated with users in the purge requests to active users before you proceed with the purge. This prevents unintended data loss. If you continue to purge, without transferring data, users in the forms are purged and you can no longer access the forms.


Related Information

User Identifiers Included in the DRTM Master Data Purge [page 57]User Data Included in the DRTM Master Data Purge [page 57]Employee Central Identifiers Included in the DRTM Master Data Purge [page 58]Employee Central Data Included Only in the DRTM Master Data Purge [page 60]

3.5.2 DRTM Audit Data Purge

The DRTM Audit Data Purge removes data from audit logs for that are used to generate personal data audit reports for data protection and privacy.

You may only be required to provide audit reports on personal data for a certain period of time. After this time has elapsed and you are no longer required to produce these reports, you can purge the unnecessary audit data.


To purge audit data for both active and inactive users, based on specific retention times for each type of audit data, use the DRTM Audit Data Purge.

To purge audit data for inactive users only, along with other associated data across the HXM Suite, use the DRTM Master Data Purgeinstead.



RememberUnlike other purge processes, targeted audit data may still be available in the system when the purge request is shown as completed in Purge Request Monitor. This is because we run purge jobs for audit data collectively on weekends. When you complete a DRTM Aduit Data or DRTM Master Data Purge on a weekday, you should validate the purge result of audit data next week.

Data Included in the DRTM Audit Data Purge [page 62]Use the DRTM Audit Data purge type to purge audit data used to produce audit reports on personal data for data protection and privacy.

Related Information

Purge of Audit Data [page 44]DRTM Audit Data Purge [page 61]Configuring Retention Times for Audit Data [page 146]Purging Audit Data for Active and Inactive Users with DRTM [page 165]Audit Data Purge Objects [page 149]

3.5.2.1 Data Included in the DRTM Audit Data Purge

Use the DRTM Audit Data purge type to purge audit data used to produce audit reports on personal data for data protection and privacy.

When setting up a DRTM Audit Data purge request, you can’t choose which purge objects to include. All purge objects are always included in the purge.

The data in each audit data purge object is purged based on its own configured retention time, for both active and inactive users.


Module Audit data type

Succession Change audit

Calibration Change audit and read audit

People Profile Change audit and read audit

Employee Central (Employment, Global Benefit, and Time Management)

Read audit

Document Management Read audit


Data Purge

Module Audit data type

Compensation Change audit

Career Development & Planning Change audit and read audit

Goal Management Change audit

360 Reviews Change audit and read audit

Performance Management Change audit and read audit

User Management Change audit and read audit

Reporting Read audit

Workforce Analytics Read audit

Data Retention Management Read audit

Parent topic: DRTM Audit Data Purge [page 61]

3.5.3 DRTM Inactive Candidate Purge Criteria

Candidates are purged in Recruiting based on the Application status.

You must consider the following criteria to purge candidates in Recruiting:

● When the profile is deleted by the candidate or by the administrator.● The candidates who have not logged in for the configured retention time (Inactivity Time Unit).● The candidates who have not accepted the DPCS for the set retention time (Period of Non-Acceptance of

DPCS).● When the DRM 2.0 Candidate Purge: Do not purge Candidate Profile if there are existing applications in the

system for that candidate option is disabled, candidate profile is purged regardless of the status of the applications that exist for the candidate.If the DRM 2.0 Candidate Purge: Do not purge Candidate Profile if there are existing applications in the system for that candidate option is enabled, then candidate profile is purged based on the status of the application that exists for the candidate in the following table:

If the Application Status is ... Candidate profile ...

In-Progress Not purged

Draft, Closed, Withdrawn, Disqualified Purged

Requisition Closed Purged if the Manage Recruiting Settings Consider job applications with the status "Requisition Closed" for

purging option is enabled


If the Application Status is ... Candidate profile ...

Hired On Other Requisition Purged if the Manage Recruiting Settings Consider job applications with the status "Hired On Other Requisition" for

purging option is enabled

Note● Before you purge an originator of a pre-approved, approved, or closed job requisition as a part of the

Master data purge, you should reassign the job requisitions to another originator. Go to Admin Center Recruiting Reassign Job Requisitions to reassign the job requisitions to an active originator.

● You can also configure your system to send an advance notification to inactive candidates to remind them to take action before their profiles are purged. This functionality does not apply to candidate purge scenarios where, candidates who have not accepted the DPCS for the set retention time are purged on the scheduled date.

Related Information

Purging Candidate Profiles in Recruiting [page 406]

3.5.4 Data Included in the DRTM Benefits Purge

Use the DRTM Benefits purge type to purge benefit enrollment, claim and benefit program enrollment data.

When setting up a DRTM Benefits purge request, you can choose to include one or more of the following purge objects.

Purge object Data purged with this object

<Dynamic Object for Benefits Enrollment>

Purges enrollment records of benefits.

All fields of the MDF objects Benefit Enrollment, Benefit Savings Plan Enrollment Contribution Detail, Insurance Plan Enrollment, Fund Contribution Details, Benefit Deductible Allowance Enrollment, Benefit Pension NonDependent Nominees, Benefit Pension Dependent Nominees, Benefit Company Car Enrollment, Benefit Company Housing Enrollment, Benefit Insurance Dependent Detail, Benefit Documentation, Benefit contact for the selected benefit type(s)


Data Purge


<Dynamic Object for Benefits Claim> Purges reimbursement claims.

All fields of the MDF objects Benefit Employee Claim, Benefit Employee Claim Detail, Benefit Dependent Detail, Benefit Documentation, Benefit Contact, Benefit Fuel Reimbursement Claim, Benefit Leave Travel Reimbursement Claim, Benefit Fuel Reimbursement Claim Detail, Benefit Employee Car Claim, Benefit Claim Accumulation, Balance Carry Forward Detailsfor the selected benefit type(s)

<Dynamic Object for Benefit Program Enrollment>

Purges enrollment records of benefit programs.

Benefit Program Enrollment, Benefit Documentation, Benefit Program Enrollment Detail for the selected benefit type(s)

3.5.5 Data Included in the DRTM Compensation/Variable Pay Purge

Use the DRTM Compensation/Variable Pay Purge type to purge data associated with multiple Compensation templates.

When setting up a DRTM Compensation/Variable Pay Purge request, you can choose to include one or more of the following purge objects.


Worksheet Data All configured worksheet data fields which represents Merit or Promotion details of an employee on a manager's worksheet for the Compensation template. The tem

plates can be accessed from Admin Centre Compensation Home Plans .

Statements All data elements configured for statements, which are generated after a Compensation planning cycle is completed, and made available to employees, managers, HR Business Partners and so on.

3.5.6 Data Included in the DRTM Employment Information Purge

Use the DRTM Employment Information purge type to purge employment-related data.

When setting up an DRTM Employment Information purge request, you can choose to include one or more of the following purge objects.



Apprenticeship Purges apprenticeship data, which means, all fields of the MDF object Apprentice.

Compensation Purges compensation data in Employee Central, which means, all fields of the HRIS Elements ‘Pay Component Information’ (compInfo) and ‘Pay Component Recurring’ (payComponentRecurring).

Cost Distribution Purges cost distribution data in Employee Central, which means, all fields of the MDF object Alternative Cost Distribution.

Deductions Purges one-time and recurring deduction data in Employee Central, which means all records based on the effectivedate.

Income Tax Declaration Purges income tax declaration data in Employee Central, which means all fields of the MDF object Income Tax Declarations.

Job Relationships Purges job relationship data in Employee Central, which means all fields of the HRIS Element ‘Job Relationships’ (jobRelationsInfo).

Non-Recurring Pay Purges non-recurring pay data in Employee Central, which means all fields of the HRIS Element ‘One-time Payments’ (payComponentNonRecurring).

Payment Information Purges payment information in Employee Central, which means all fields of the MDF objects PaymentInformation V3 and Payment Information Details.

Position Right of Return Purges the entire MDF object Position Right of Return.

Advances Purges advances requests, which means all fields of the MDF objects Advance, Advance Installments and Accumulation for Advances for the selected advances type(s).

Employee Dismissal Protection Purges dismissal protection types, which means all fields of the MDF object Employee Dismissal Protection Detail for the selected dismissal protection type(s).

3.5.7 Data Included in the DRTM Employee Profile Purge

Use the DRTM Employee Profile purge type to purge employee profile data, such as background information and rating data.

When setting up a DRTM Employee Profile purge request, you can choose to include one or more of the following purge objects.


Background Purges extended user information data in custom background elements.

All fields in all custom background elements, including attachments.


Data Purge


Feedback Purges extended user information data in custom feedback (or "trend") elements.

All fields in six types of feedback (or "trend") elements:

● sysOverallPerformance● sysOverallPotential● sysOverallObjective● sysOverallCompetency● sysOverallCustom1● sysOverallCustom2

If FB_SOURCE = 2, then attachments are also included.

Introduction Purges additional profile information, including:

● My Name audio and phonetic spelling● About Me text and video● Badges● Tags

Photo Employee photo and profile background image

3.5.8 Data Included in the DRTM Learning Data PurgeUse the DRTM Learning Data purge type to purge personal data from the users' learning profiles and users' learning activities.


User Personal Information Learning personal audit data purges rows from the learning audit tables (the PH tables) to eliminate personal data that is older than the threshold you set.

Learning Activity When you purge learners' learning activity as part of your data privacy and protection process, you purge the personal information out of the historical record of what they learned, when they learned it, and any comments they had on courses.

Information Purged With Learning Activity [page 68]When you purge learners' learning activity as part of your data privacy and protection process, you purge the personal information out of the historical record of what they learned, when they learned it, and any comments they had on courses.

Tables Affected by Learning Activity Purge [page 70]We purge from specific tables when we purge learning activities. Some customers who have built extensions or who custom reports need to know the list of tables.

Information Purged With Personal Audit Data [page 74]Learning personal audit data purges rows from the learning audit tables (the PH tables) to eliminate personal data that is older than the threshold you set.

Tables Affected by Personal Audit Data Purge [page 76]


We purge from specific tables when we purge personal audit data. Some customers who have built extensions or who custom reports need to know the list of tables.

3.5.8.1 Information Purged With Learning Activity

When you purge learners' learning activity as part of your data privacy and protection process, you purge the personal information out of the historical record of what they learned, when they learned it, and any comments they had on courses.

Learning Activity Purge Summary

NoteThis information applies to Learning only. Other parts of SAP SuccessFactors can also affect Learning data. For example, Succession & Development can add learning activity information and has its own purge type. Please check all purge options to assure that you are purging data that you want to purge from all modules that add Learning data.

When you purge learning activities, you purge information that could help someone understand what courses a user was involved with past the purge threshold. We want to erase the learning activity records so that someone cannot reconstruct users' learning activity:

● Completed internal events are the core of the purge, and they include any learning history for completed courses when the event history date is past the purge threshold.○ For internal events, we know the event history date in PA_CPNT_EVTHIST, which gives you the preview

count in the purge report○ From the event history date, we can purge completed learning items, but we purge other entities in the

report based on other dates. For example, we want to purge pending learning events because someone could reconstruct learning activities from pending events, but pending events, by definition, do not have an event history date.

○ We handle incomplete courses in removed assignments.● Completed external events are like internal events, but have a different table for count because we store it

separately in PA_XCPNT_EVTHST.● Removed item, curricula, and program assignments include activity that learners were assigned at some

point, which created a record in the history tables (PH_). But learners are no longer assigned the activity and they did not complete it, so they do not exist in the PA_ tables. The counts, therefore, are in the PH_ tables.○ We purge the assignments, even if they could be used to reconstruct learning activity○ Recommendations that are older than the threshold date are also purged, even if they are not completed,

because they could indicate learning activity.○ We do not purge items that are currently assigned to an active curriculum because they are reassigned.

● Item ratings by learners could reconstruct learning activity because learners can only rate courses that they have completed.

● Scheduled offering registrations for closed or canceled classes where the date is past the threshold in PA_SCHED show someone the courses that users were interested in (or classes that they were registered for).


Data Purge

Learning Activity Purge Details

Data Entity Sub-Entity Criteria for Purge Preview Count From

Completed Internal Events Completed programs Based on completion date in PA_STUD_CPNT for programs

None

Completed Internal Events Completed learning events Based on completion date in PA_CPNT_EVTHST that includes programs

PA_CPNT_EVTHST

Completed Internal Events Completed items and program items

Based on completion date in PA_STUD_CPNT for items and program items of completed programs

None

Completed Internal Events Completed online data Based on completion date in PA_CBT_STUD_CPNT

None

Completed Internal Events Pending learning events Based on completion date in PA_PENDING_CPNT_EVTHST

None

Completed Internal Events Competency assessments Based on assessment date in PA_STUD_CPTY_ASSESSMENT, assessment date in PH_STUD_CPTY_ASSESSMENT

None

Completed Internal Events Accomplishments Based on effective date in PA_STUD_ACCOMPLISHMENTS

None

Completed Internal Events Surveys Based on item completion date in PA_STUD_SURVEY

None

Completed Internal Events Approvals For COMPLETION STATUS ESIG, EXTERNAL EVENT ESIG, LEARNING EVENT ESIG, INTERNAL EVENT RECORD LEARNING, EXTERNAL EVENT RECORD LEARNING – based on completion date in PA_TAP_INSTANCE except Pending ones.

For ONLINE COMPONENT – based on last update timestamp in PA_TAP_INSTANCE except Pending ones and item does not exist in PA_STUD_CPNT

None

Completed External Events Completed External Events Based on completion date in PA_XCPNT_EVTHST and completion date in PH_XCPNT_EVTHST

PA_XCPNT_EVTHST



Removed Program Assignments


Un-assigned incomplete programs in PH_STUD_CPNT

PH_STUD_CPNT

Removed Item Assignments Removed Item Assignments Un-assigned incomplete items including program items in PH_STUD_CPNT

PH_STUD_CPNT

Removed Item Assignments Recommendations Recommendation date in PA_P2P_RECOMMENDATION and recommendation date in PA_P2P_RECOMMENDED_USER

None

Item Ratings Item Ratings Last completion date in PA_STUD_ITEM_RATING, last completion date in PH_STUD_ITEM_RATING

PA_STUD_ITEM_RATING

Removed Curricula Assignments


Un-assigned curricula in PH_STUD_QUAL

PH_STUD_QUAL

Scheduled Offering Registrations

Scheduled Offerings Registrations

Registrations in PA_ENROLL_SEAT and PA_VLE_ENROLL_SEAT for canceled or closed scheduled offerings in PA_SCHED

PA_ENROLL_SEAT

Parent topic: Data Included in the DRTM Learning Data Purge [page 67]

Related Information

Tables Affected by Learning Activity Purge [page 70]Information Purged With Personal Audit Data [page 74]Tables Affected by Personal Audit Data Purge [page 76]

3.5.8.2 Tables Affected by Learning Activity Purge

We purge from specific tables when we purge learning activities. Some customers who have built extensions or who custom reports need to know the list of tables.

NoteThis information applies to Learning only. Other parts of SAP SuccessFactors can also affect Learning data. For example, Succession & Development can add learning activity information and has its own purge type. Please


Data Purge

check all purge options to assure that you are purging data that you want to purge from all modules that add Learning data.

Tables Affected by Learning History Purge

Data Entity Sub-Entity Table Name

Completed Internal Events

Completed programs PA_STUD_CPNT and related PA child tables

PH_STUD_CPNT

PA_STUD_PROGRAM

PH_STUD_PROGRAM

PH_STUD_PROGRAM_SECTION

PH_STUD_PROGRAM_SEC_ENTRY

PH_STUD_PROGRAM_CUSTOM_ENTRY


Completed learning events PA_CPNT_EVTHST and related PA child tables

PH_CPNT_EVTHST

PH_GVT_RPT_CPNT_EVTHST

PH_GVT_RPT_CPNT_EVTHST_PRG

PH_STUD_CPTY_ASSESSMENT

PH_CPNT_COMPLIANCE_DATA

PH_CPNT_EVTHST_CUSTOM_CREDIT


Completed items and program items

PA_STUD_CPNT and related PA child tables,

PA_STUD_CHKLST

PH_STUD_CPNT




Completed online data PA_CBT_STUD_CPNT and related PA child tables,

PA_CBT_STUD_CPNT_MOD_AUDIT

PA_CBT_STUD_CPNT_OBJ

PH_CBT_STUD_CPNT

PH_CBT_STUD_CPNT_MOD

PH_CBT_STUD_EXAM

PH_CBT_STUD_EXAM_OBJ

PH_CBT_STUD_EXAM_QUESTION

PH_CBT_STUD_EXAM_MSG

PH_CBT_STUD_EXAM_QST_ANSR

PH_CBT_STUD_CPNT_MOD_OBJ

PH_CBT_STUD_CPNT_MOD_BKMRK


Pending learning events PA_PENDING_CPNT_EVTHST and related PA child tables


Competency assessments PA_STUD_CPTY_ASSESSMENT and related PA child tables

PH_STUD_CPTY_ASSESSMENT


Accomplishments PA_STUD_ACCOMPLISHMENTS and related PA child tables


Surveys PA_STUD_SURVEY and related PA child tables


Approvals PA_TAP_INSTANCE and related PA child tables

PH_TAP_INSTANCE

PH_TAP_ACTION

Completed External Events

Completed External Events PA_XCPNT_EVTHST and related PA child tables

PH_GVT_RPT_XCPNT_EVTHST

PH_GVT_RPT_XCPNT_EVTHST_PRG

PH_XCPNT_EVTHST_CUSTOM_CREDIT


Data Purge



Removed Program Assignments PH_STUD_CPNT

PH_STUD_PROGRAM

PH_STUD_PROGRAM_SECTION

PH_STUD_PROGRAM_SEC_ENTRY

PH_STUD_PROGRAM_CUSTOM_ENTRY

Removed Item Assignments

Items PH_STUD_CPNT

PH_CBT_STUD_CPNT

PH_CBT_STUD_CPNT_MOD

PH_CBT_STUD_EXAM

PH_CBT_STUD_EXAM_OBJ

PH_CBT_STUD_EXAM_QUESTION

PH_CBT_STUD_EXAM_MSG

PH_CBT_STUD_EXAM_QST_ANSR

PH_CBT_STUD_CPNT_MOD_OBJ

PH_CBT_STUD_CPNT_MOD_BKMRK

Removed Item Assignments

Recommendations PA_P2P_RECOMMENDATION

PA_P2P_RECOMMENDATION_USER

Item Ratings Item Ratings PA_STUD_ITEM_RATING

PH_STUD_ITEM_RATING


Removed Curricula Assignments PH_STUD_QUAL

PH_STUD_QUAL_CPNT

PH_STUD_QUAL_REQ

Class Registrations Class Registrations PA_ENROLL_SEAT

PH_ENROLL_SEAT


Related Information

Information Purged With Learning Activity [page 68]


Information Purged With Personal Audit Data [page 74]Tables Affected by Personal Audit Data Purge [page 76]

3.5.8.3 Information Purged With Personal Audit Data

Learning personal audit data purges rows from the learning audit tables (the PH tables) to eliminate personal data that is older than the threshold you set.

Personal Audit Data Purge Summary

NoteThis information applies to Learning only. Other parts of SAP SuccessFactors can also affect Learning data. For example, Succession & Development can add learning activity information and has its own purge type. Please check all purge options to assure that you are purging data that you want to purge from all modules that add Learning data.

When you purge personal data from audit (PH) tables, you purge the data when timestamps of the audit record are older than your threshold. We do not purge from PA tables because PA tables are transactional tables.

Data exists in the PA tables, by definition, because you still need it for the user. For example, the PA_STUD_PHON table contains the current phone numbers of the user. When you do not need a phone number for a user, you remove it and it no longer appears in PA_STUD_PHON (it is already purged). We keep a copy of the old phone number, however, in PH_STUD_PHON. When the last updated timestamp for the record in PH_STUD_PHON is older than the threshold, we purge it from PH_STUD_PHON.

The preview count, therefore, is based on the history record's (PH) last timestamp for the history tables that store personal information.


Data Purge

Personal Audit Data Purge Details


User Information Audit Tables User Based on the history record's last update timestamp in the table

PH_STUDENT

PH_STUD_PHON

PH_STUD_ALTERNATE_JP

PH_STUD_EMPLOYMENT

PH_STUD_USER

PH_STUD_ASSGN_PRFL

PH_STUD_TP

PH_STUD_EDUCATION

PH_STUD_EXT_WORK_HISTORY

PH_STUD_PUBLIC_PROFILE

PH_STUD_AWARD

PH_STUD_SECURITY_CLEARANCE

PH_STUD_PROJECT

PH_STUD_IM_DETAIL

PH_STUD_INTEREST

PH_STUD_LANGUAGE_SKILL

PH_STUD_NOTES

PH_STUD_DELEGATE_STUD

PH_STUD_DELEGATE_DELEG

PH_STUD_DELEGATE_PERMISSION_STUD

PH_STUD_DELEGATE_PERMISSION_DELEG

PH_STUD_LRN_ITEM_BOOKMARK



Related Information

Information Purged With Learning Activity [page 68]Tables Affected by Learning Activity Purge [page 70]Tables Affected by Personal Audit Data Purge [page 76]

3.5.8.4 Tables Affected by Personal Audit Data Purge

We purge from specific tables when we purge personal audit data. Some customers who have built extensions or who custom reports need to know the list of tables.

NoteAll tables in the partial purge of personal information are PH tables: they are history tables. The process does not purge data from the transactional (PA) tables. For example, the process purges old phone numbers out of the audit history but keeps users' current phone numbers in the PA tables they are still correct and in use. For a full purge of both PA and PH tables, use a full purge. This information applies to Learning only. Other parts of SAP SuccessFactors can also affect Learning data. For example, Succession & Development can add learning activity information and has its own purge type. Please check all purge options to assure that you are purging data that you want to purge from all modules that add Learning data.


Data Purge

Tables Affected by Personal Audit Data Purge


User Information Audit Tables User PH_STUDENT

PH_STUD_PHON

PH_STUD_ALTERNATE_JP

PH_STUD_EMPLOYMENT

PH_STUD_USER

PH_STUD_ASSGN_PRFL

PH_STUD_TP

PH_STUD_EDUCATION

PH_STUD_EXT_WORK_HISTORY

PH_STUD_PUBLIC_PROFILE

PH_STUD_AWARD

PH_STUD_SECURITY_CLEARANCE

PH_STUD_PROJECT

PH_STUD_IM_DETAIL

PH_STUD_INTEREST

PH_STUD_LANGUAGE_SKILL

PH_STUD_NOTES

PH_STUD_DELEGATE_STUD

PH_STUD_DELEGATE_DELEG

PH_STUD_DELEGATE_PERMISSION_STUD

PH_STUD_DELEGATE_PERMISSION_DELEG

PH_STUD_LRN_ITEM_BOOKMARK

PH_USER_PRFL

PH_INST



PH_USER_PRFL_ROLE

PH_INST_COST

PH_AUTH_CPNT

PH_INST_USER


Related Information

Information Purged With Learning Activity [page 68]Tables Affected by Learning Activity Purge [page 70]Information Purged With Personal Audit Data [page 74]

3.5.9 Data Included in the DRTM Mentoring Program Purge

Use the DRTM Mentoring Program purge type to purge all data pertinent to a user's participation in mentoring programs.

When setting up a DRTM Mentoring Program purge request, you can choose to include one or more of the following purge objects.


Mentoring Program Mentees Purges records of the user having been a mentee in any mentoring program. Also purges any matching and sign-up form data associated with the user.

The purged data pertinent to a user's participation in mentoring program as a mentee includes the following:

● MentoringProgramMentee● MentoringProgramMenteeSignupForm● MentoringProgramActivity● MentoringProgramMentorRequest● MentoringProgramMatchedParticipant


Data Purge


Mentoring Program Mentors Purges records of the user having been a mentor in any mentoring program. Also purges any matching and sign-up form data associated with the user.

The purged data pertinent to a user's participation in mentoring program as a mentor includes the following:

● MentoringProgramMentor● MentoringProgramMentorSignupForm● MentoringProgramActivity● MentoringProgramMentorRequest● MentoringProgramMatchedParticipant● (if there is any) Attach_content

Mentoring Program Owners Purges records of the user having been a program owner in any mentoring program.

3.5.10 Data Included in the DRTM Performance Reviews Purge

Use the DRTM Performance Reviews Purge type to purge only completed forms for either active or inactive users.

Note● With this purge type, you can purge only completed forms for either active or inactive users.

With DRTM Master Data purge, you can purge both complete and incomplete forms for inactive users. Forms that are incomplete are shown in the preview report; you can then decide whether to approve the purge incomplete forms of an inactive user.

● An active user can own an active form, which uses an inactive form template. In that case, you can continue to purge the performance data as it is, independent of the template status.

● Data Retention Time Management (DRTM) does not allow you to purge data based on the form templates.

When setting up a DRTM Performance Reviews Purge request, you can choose to include the following purge object.



Performance Reviews Performance Goal Section:

● Ratings on Goals (including others ratings)● Overall Performance goal section rating● comments on Goals (including others comment)● comments on Goals section (including others section comment)

Development Goals Section:

● Ratings on Development Goals (including others ratings)● Overall Development goal section rating● Comments on Development Goals (including others comment)● comments on Development Goals section (including others section comment)

Competency Section:

● Ratings on competencies (including others ratings)● Comments on Competencies (including others comment)● comments on Competencies section (including others section comment)● Ratings on behavior (including others ratings)● Overall Competency section rating● Comments on behavior (including others comment)

Signature Section：

● Signature section comments

Objective / Competency Section:

● Obj/Comp section comments & label● Overall Obj/Comp rating (manual, calculated, adjusted & label)● Overall Performance Rating(OCOC)

Performance & Potential Section:

● Potential rating & Label● Performance Rating & Label● Perf/Potential section comments & Label

Performance Summary Section：

● Overall performance rating - calculated rating & label● Overall performance rating & label● Overall performance rating - unadjusted calculated rating & label

Form Attachment Name

Form auditTrailComment

Form AskForFeedback


Data Purge

3.5.11 Data Included in the DRTM Person Information Purge

Use the DRTM Person Information purge type to purge all person-related data.

When setting up a DRTM Person Information purge request, you can choose to include one or more of the following purge objects.


Addresses Purges all addresses in Employee Central, which means, all fields of the HRIS Element ‘Addresses’.

Dependents Purges dependents in Employee Central, which means, all fields of the HRIS Element ‘Dependents’ (personRelationshipInfo) including all fields of the HRIS Elements 'Addresses', 'National ID', and 'Personal Information' that refer to the Dependent.

NoteIf the same dependent is listed multiple times in the system or is themselves also an employee, then their data will not be purged.

Email Purges email information in Employee Central, which means, all fields of the HRIS Element ‘Email Information’ (emailInfo).

NoteFor active users, this information will not be purged.

Emergency Contact Information Purges emergency contact information in Employee Central, which means, all fields of the HRIS Element ‘Primary Emergency Contact’ (emergencyContactPrimary).


Global Information Purges global information data in Employee Central, which means, all fields of the HRIS Element 'Global Information' (globalInfo).

National ID Card Purges national ID card information data in Employee Central, which means, all fields of the HRIS Element 'National ID' (nationalIDInfo).

Personal Details Purges personal details in Employee Central, which means, all fields of the HRIS Element ‘Personal Information’ (PersonalInfo).

NoteThe system will delete all but the last time slice for personal details for a user. In the Master Data purge, the data is kept but anonymized.



Phone Purges phone information in Employee Central, which means, all fields of the HRIS Element ‘Phone Information’ (phoneInfo).


Social Account Purges social account information in Employee Central, which means, all fields of the HRIS Element ‘Social Accounts Information (imInfo).


NoteThe UI will always be empty for person information, whether the purge objects have been set up or not. If you do not want to purge specific objects, you can delete those from the DRTM Person Info Purge Objects, otherwise, all the listed ones will be purged. The purge is also dependent on the time of the purge request run. For example, if a customer schedules a request for 5 days later. Before reaching the 5 days, if the customer adds or removes a country or region, the purge will be done on the basis of the retention times available in those purge objects on the day request is running.

3.5.12 Data Included in the DRTM Succession Purge

Use the DRTM Succession purge type to purge nomination and incumbent data.

When setting up a DRTM Succession purge request, you can choose to include one or more of the following purge objects.

NoteDRTM Succession is only relevant for formless nominations. Form-based nominations are not supported.


Data Purge


Succession Nominations Purges a user's succession nominations for all succession and talent pool nomination methods. Also purges a user's nomination history for all nomination methods.

Purged nomination data includes the following:

● Successor Status● Successor Readiness● Successor Rank● Successor Note

Records in the SM_NOMINATION, SM_NOMINEE, and SM_NOMINEE_HIST tables.

Succession Nominations: inactive nominations only

Purges just the succession nominations that have one of the following inactive statuses: removed, rejected, or succeeded.

Purged nomination data includes the following:

● Successor Status● Successor Readiness● Successor Rank● Successor Note

Records in the SM_NOMINATION, SM_NOMINEE, and SM_NOMINEE_HIST tables.

Position Incumbent NoteIncumbent data is not purged for active users.

Legacy Positions

For legacy position-based nominations, the position incumbent field is used to record the user ID of the person holding the position, regardless of whether or not position management of Employee Central is used.

For inactive users, the request purges user data from the position incumbent field for legacy positions.

MDF Positions

For MDF position-based nominations, the position incumbent field is only relevant for customers who are not using position management of Employee Central.

For inactive users, the request purges user data from the position incumbent field for all effective dated records for MDF positions.

For MDF position-based nominations where position management of Employee Central is used, the position incumbent field is not relevant, so there is no data to purge.

Incumbent field for legacy position: INCUMBENT field in POSITION table.

Incumbent field for MDF position: SF_FIELD5 field in GENERIC_OBJECT_T table.


3.5.13 Data Included in the DRTM Time Management Purge

Use the DRTM Time Management purge type to purge Time Off data in Employee Central.


Alerts Purges time management alerts.

All fields of MDF object TimeManagementAlert

Accrual Calculation Base Purges accrual calculation bases.

All fields of MDF object AccrualCalculationBase

Temporary Time Information Purges temporary time information, plus individual work schedules provided these are assigned only to the temporary time information.

All fields of MDF object TemporaryTimeInformation and all fields of MDF object WorkSchedule, which were only referenced by the deleted TemporaryTimeInformation

Time Account Payout Purges time account payouts and related time account detail postings.

All fields of MDF object TimeAccountPayout

Time Account Purchase Purges time account purchases and related time account detail postings.

All fields of MDF object TimeAccountPurchase

Time Sheet The following objects are purged if time sheet is enabled:

● Employee Time Sheet● Time Account● Time Account Detail● External Time Data● External Time Record● Time Collector● Attendance Request● Time Valuation Alert

All fields of MDF objects EmployeeTimeSheet, EmployeeTimeSheetEntry, Time Collector, Allowance, EmployeeTimeValuationResult, ExternalTimeRecord, ExternalTimeSegment, EmployeeTime based on an Attendance Time Type

<Dynamic Group for Time Account Type: TimeManagementRetentionGroup>

● Time Account Type: Account Retention Group - Purges complete time accounts without overlap with new retention period

● Time Account Type: Account Detail Retention - Consolidates time account details on account before new retention date

All fields of MDF objects TimeAccount, TimeAccountDetail, TimeAccountSnapshot, AccrualCalculationAccountTypeBase based on the Time Account Type


Data Purge


<Dynamic Group for Time Type: TimeManagementRetentionGroup>

Time Type: Absence Retention group - Purges Employee Times without overlap with new retention period.

All fields of MDF objects EmployeeTime, EmployeeTimeCalendar, EmployeeTimeGroup, EmployeeTimeGroupItem, EmployeeTimeESP, EmployeeTimeDEU, EmployeeTimeMEX based on the Time Type

3.5.14 Data Included in the DRTM Workflows Purge

Use the DRTM Workflows purge type to purge Employee Central Workflows.

When setting up a DRTM Workflows Purge, you can choose to include one or more of the following purge objects:


All Workflows Pending workflow information data that is stored in workflow data tables is purged. Includes all the following workflow types:

● Employee Self-Service (ESS)● Manager Self-Service (MSS)● Metadata Framework (MDF)

For the following workflow statuses:

● Pending● Completed● Sent Back● Rejected● Canceled

Completed Workflows Completed workflow data that is stored in workflow data tables is purged. Includes all the following workflow types:

● Employee Self-Service (ESS)● Manager Self-Service (MSS)● Metadata Framework (MDF)

For the following workflow statuses:

● Completed● Rejected● Canceled

NoteFoundation Object workflows aren't purged since they're not person-based. For MDF workflows, only person-based object workflows are purged.


You can download detailed purge reports by going to Admin Center Purge Request Monitor Approved Requests View Result Download Complete Report . The downloaded archive contains two or three CSV files. In the file "DRTMWorkflowGroupObjectType.csv", please note that the status will always be "EXCLUDED", which is not meant to indicate the purge results of workflows but just to suggest that countries (or legal entities) themselves are not applicable for the purge process. In other files, you can check purge results by looking at the status (either PURGED or EXCLUDED) at the end of each line.

Tables Affected by Workflow Activity Purge for Employee Central Workflows [page 86]We purge from specific tables when we purge pending and completed workflow activities for Employee Central workflows.

Tables Affected by Workflow Activity Purge for MDF Workflows [page 87]We purge from specific tables when we purge pending and completed workflow activities for MDF Workflows.

3.5.14.1 Tables Affected by Workflow Activity Purge for Employee Central Workflows

We purge from specific tables when we purge pending and completed workflow activities for Employee Central workflows.

NoteAll tables for pending and completed workflows are WF tables: they are workflow tables. Only information after the data change that triggers the workflow is purged, but not the data before the change. If you want to purge the old data, you must use a different purge type.

Tables Affected by Workflow Purge For Employee Central Workflows

Data Entity Table Name

Workflow Tables WF_REQUEST

EMP_WF_REQUEST

WF_REQUEST_STEP

WF_REQUEST_ATTRIBUTES

WF_REQUEST_PARTICIPATOR

WF_REQUEST_COMMENTS

WF_REQUEST_DELEGATE

TODO_ENTRY

Parent topic: Data Included in the DRTM Workflows Purge [page 85]


Data Purge

Related Information

Tables Affected by Workflow Activity Purge for MDF Workflows [page 87]

3.5.14.2 Tables Affected by Workflow Activity Purge for MDF Workflows

We purge from specific tables when we purge pending and completed workflow activities for MDF Workflows.

NoteAll tables for pending and completed workflows are WF tables: they are workflow tables. Only information after the data change that triggers the workflow is purged, but not the data before the change. If you want to purge the old data, you must use a different purge type.

Tables Affected by Workflow Purge For MDF Workflows

Data Entity Table Name

Workflow Tables WF_REQUEST

EMP_WF_REQUEST

WF_REQUEST_STEP

WF_REQUEST_ATTRIBUTES

WF_REQUEST_PARTICIPATOR

WF_REQUEST_COMMENTS

WF_REQUEST_DELEGATE

TODO_ENTRY

Workflow Tables GO_WF_REQUEST

GO_WF_PENDING_HISTORY

GENERIC_OBJECT_T

Parent topic: Data Included in the DRTM Workflows Purge [page 85]

Related Information

Tables Affected by Workflow Activity Purge for Employee Central Workflows [page 86]


3.5.15 Data Included in the DRTM Onboarding Purge

Use the DRTM Onboarding Purge type to purge all data related to Onboarding captured during the Onboarding process.

When setting up a DRTM Onboarding purge, you can purge all data captured during the onboarding process, for internal as well as external users. Internal users are those who have been converted to employees whereas external users are those who haven’t yet been converted to employees.

There are three types of Data purge:

● Data Retention Time Management (DRTM) Onboardingpurge: The DRTM Onboarding purge is used to remove all data related to Onboarding, which has been captured during the Onboarding process.

● Data Retention Time Management (DRTM) Audit Data purge: The DRTM Audit Data purge removes data from audit logs that are used to generate personal data audit reports for data protection and privacy. You can use DRTM to purge audit data for external onboarding users. When you include external onboarding users in a DRTM Audit Data purge request, all of the audit data for the external users can be successfully purged.

● Data Retention Time Management (DRTM) Master data purge: The DRTM Master Data purge is used to fully purge inactive users and their associated data based on a single, common retention time.

NoteYou can purge the new hires whose status is either Cancelled or Completed. The new hire is in Cancelled state when the onboarding process for the new hire has been cancelled.

The new hire is in Completed state, when the process closure job is executed, and the onboarding process status is changed to Completed state based on the conditions set in the business rule. For more information on how to configure the closure rule, refer to the "Configuring Business Rules for Closing the Onboarding/Offboarding Processes" topic in the Related Information section.

You can create a purge request by navigating to Admin Center Data Retention Management and selecting theDRTM Onboarding Purge group.

The following objects are included under the DRTM Onboarding Purge request type:

Object Description

Data Collection Extension Purging all the information of User collected as part of Custom Data Collection and its Notifications.

Documents All the documents of user and specific notifications are purged.

In Onboarding, compliance forms in PDF format are included in the Master Data Purge.

NoteIt’s recommended that customers with US compliance forms (I-9 and tax forms) shouldn’t perform master data purge to avoid purging US compliance forms. Also, the ability to configure the retention of the US compliance forms isn’t yet supported.


Data Purge

Object Description

Process and User Data Purging all userspecific data like Employee Data, MDF Data, BPE Data, email notifications.

Tasks/Activities New Hire activities data and specific email notifications are purged.

If the onboarding process is canceled, then the new hire is marked as Inactive. In this case, the data purge happens in two stages:

1. You must purge data captured during the onboarding process by creating a purge request under Admin Center Data Retention Management tool using the DRTM Onboarding Purge group.

2. You can purge the inactive user by creating a purge request under Admin Center Data Retention Management tool using the DTRM Inactive User Purge purge group.

For more information about purging inactive users and all data, refer to the Related Information section.

Manage data retention and purge activities for documents stored in DocuSign directly through DocuSign.

For detailed information about how data purge works in the SAP SuccessFactors HXM Suite, refer to the Related Information section.

Data Retention TimeIn Onboarding, you can configure different retention times for different objects of the onboarding process. The exact end date of the retention period is determined by a base date, which is the date from which retention time is calculated. In Onboarding, the base date is the new hire's start date.

ExampleIf you configure the retention time for new hire data to be seven years, the retention time for a given form would be seven years after the respective new hire's start date.

NoteFor canceled onboarding scenarios, the base date would be the date when onboarding is canceled.

For more information about configuring data retention times, refer to the Related Information section.

Related Information

Retrieving an Onboarding External User Report During a Data Purge [page 90]Configuring Business Rules for Closing the Onboarding/Offboarding Processes


https://help.sap.com/viewer/c94ed5fcb5fe4e0281f396556743812c/latest/en-US/4831b195f90245f689029fe96ce3eb30.html

3.5.15.1 Retrieving an Onboarding External User Report During a Data Purge

Generate or extract external user IDs based on PersonType while performing a data purge.

Context

When the Onboarding process is cancelled for an external user, you must purge the external user's personal data. To purge external user data, upload a list of external user IDs in an inactive user purge.

To upload the .csv file to the inactive data purge, remove all information from the file except the user ID. The inactive user purge excludes any users not in an inactive status.

CautionUsers who have a legal holding must be excluded from a data purge, otherwise known as a purge freeze. It is important that these users are manually excluded from the inactive user file.

Procedure

1. Go to Admin Center Integration Center My Integrations and click Create to create a new integration such as a Scheduled Simple File Output Integration to retrieve a report through an SFTP transfer.

2. In Create New Scheduled CSV File Output Integration, type "PerPersonal" in the Search for Entities by Entity Name field, to access the Personal Information (Per Personal) entity.

3. Select the initial necessary personal information attributes to distinguish the user record in Data Preview such as First Name, Middle Name, Last Name, and Gender and then click Select.

NotePerson ID External and Start Date are enabled by default.

4. In Create New Scheduled CSV File Output Integration, under Options, provide the file name for your new integration, output file type, file delimiter, header type, and footer type.

5. Click Next to go to Configure Fields, where you can view your selected entities from Data Preview as columns in your CSV File Output Integration table.

6. In Configure Fields, click Add Add Field .7. To add personType in PersonTypeUsage column to the Personal Information (PerPersonal) table, perform the

following actions:

a. In Configure Fields, click Add Add Field .b. In Find Field Starting From Personal Information, create an additional column to filter the record based on

PersonTypeUsage by entering personType in PersonTypeUsage in the search field.c. Click Add Association "User ID".

8. To add User ID-Employee Details column to the Personal Information (PerPersonal) table, perform the following actions:


Data Purge


PersonTypeUsage by entering personType in PersonTypeUsage in the search field.c. In Entity Tree View, navigate to select personNav, employmentNav, and User ID.d. Click Add Association "User ID".

User ID is part of the employment data.

You now have some personal information associated with the User ID.9. Click Next.

10. In Filter & Sort Advanced Filters , add the condition on the personType-PersonTypeUsage field to be equal to the Onboardee value and click Next.

11. Click Save and select Download Preview to view the CSV File Export preview file.12. Click Next to advance to Destination Settings.13. In Destination Settings, provide details such as SFTP Server Host Address, SFTP User Name, SFTP Password,

File Name Prefix, and File Folder in the File Server Settings.14. Click Next to advance to Scheduling.

15. In Scheduling Scheduled Version Occurs , determine how often you generate the report, such as once, daily, weekly, monthly, or yearly.

You also have the Suspended/Not Scheduled option to stop generating the report.16. If you select Weekly, you can determine the day of the week, the Start Time, Ending on Date, and designate e-

mail recipients of the report in the Email To field.17. Click Save.18. Click Set Schedule.19. In Confirm, click Save and Continue.20.In Save Integration, provide the integration name and a brief description.21. Click Save.

3.5.16 Data Included in the DRTM Clock In Clock Out Purge

Use the DRTM Clock In Clock Out Purge purge type to purge Clock In Clock Out data for both active and inactive users.

NoteEnsure to enable the DRTM Clock In Clock Out Data Purge permission in Data Retention Management under User Permissions. DRTM Clock In Clock Out Data Purge should be upgraded from the Upgrade Center. For more information, go to the Related Information section.

Purged Object Data Purged with this Object

Time Events Time events for the employee that have met the retention time. Time events are purged irrespective of their pairing status or workflow status.


Related Information

Purge of Specific Data for One SAP SuccessFactors Solution [page 42]

3.6 Important Notes About Data Purge and Data Retention Time Management

Before you start using data retention time management (DRTM), understand the following important notes and how they impact your SAP SuccessFactors system.

Limitations and Notes

Solutions Affected Notes and Limitations More Information

All DRTM data purge is based on the user's current country or region only. You can’t purge data based on a user's previous country or region.

User's Current Country or Region Is Used for Data Purge [page 103]

All DRTM data purge expects certain known values in the standard user field for country/region. You need to ensure that country/region records for users in your system have values that are supported by the DRTM data purge function.

Country/Region Names Required for Data Purge [page 23]

All Retention time for audit data purge is limited to a minimum of 6 months, according to SAP security policy.

Configuring Retention Times for Audit Data [page 146]

All DRTM Master Data purge can’t purge data stored by a solution or feature that has been disabled. If you previously used a particular solution or feature that stored personal data and then disabled it in your instance, that data can no longer be purged. The only way to purge it would to temporarily re-enable the solution or module and then run a master data purge.

N/A


Data Purge


All A maximum of 10,000 users can be included in single purge request.

For large organizations that are running the data purge for the first time, it may be necessary to purge more than 10,000 at once. If you need to purge a large number of users, set up multiple purge requests and use subject criteria to select fewer people in each request.

After your initial run, it's unlikely that you'll need to purge that many users at once, so a single recurring purge is likely to be sufficient.

Maximum Number of Users in a Purge Request [page 112]

All Data on the latest home page is purged after a predefined retention time. At this time, the latest home page doesn't support DRTM data purge or the configuration of data retention time.

Retention time is calculated using either the due date or the last modification date as the base date, whichever is more recent. The exact length of retention time is predefined and varies for different types of data.

N/A

Employee Central When configuring retention times for employee data, consider that purging data that is required for integration with other systems might lead to an unintended data loss in the replication target system. In particular, consider the full transmission start date (FTSD) defined for data replication to other systems when defining retention times: The FTSD should be after the latest retention date of any SAP SuccessFactors entity that is contained in data replication. In other words, no integration-relevant data should be purged after the FTSD. Otherwise, data can no longer be replicated for the employee in question. And if the employee's data was completely purged, this employee can never be replicated again – even if they’re rehired later.

N/A



Employee Central When setting up retention times for audit data, consider that the delta transmission mode and the snapshot mode of Compound Employee API will only expose records if the last_modified_on date or the snapshot_date is within the audit retention time of the relevant entity.

N/A

Employee Central For users with multiple employment records in the system, retention times may vary between countries/regions or legal entities of those employment and personal data records.

Data Purge and Data Retention Times for Users with Multiple Employments [page 111]

Identity Authentication If you use SAP Cloud Platform Identity Authentication, be sure to review the latest documentation to ensure that it meets your data protection and privacy requirements. For more information, see here.

N/A

Learning If you have learning sites with external users and if you are integrated with Platform, then you can’t run a partial data purge of the external users by yourself. Please create a support ticket.



Purge Process for Integrated Users of Learning Sites (External Users) [page 249]

Learning If you are a native-only customer of Learning, your purge process as limitations.

SAP SuccessFactors Learning Native-only Purge Exceptions to Data Retention Management [page 106]

Learning If you are a Learning customer and you have not adopted platform, you follow a separate process for purge.

Native-Only SAP SuccessFactors Learning Customer Configurations [page 227]


Data Purge

https://help.sap.com/viewer/6d6d63354d1242d185ab4830fc04feb1/Cloud/en-US/7a7f3aefeb7a4740b0c1490284a0a626.html


Learning When you run a preview report for Learning, the report downloads differently because the data is coming from Learning as opposed to platform. Although this creates an additional step, the report works the same as platform reports.

SAP SuccessFactors Learning Data Retention Time Management (DRTM) Preview Report [page 105]

Learning Learning allows some customers to preserve a small amount of data after a purge has run. This is extremely uncommon. It is for a small set of customers whose learning compliance time is longer than their purge time.

Enabling the SAP SuccessFactors Learning Audit Purge Log [page 236]

Learning When Learning runs the partial purge job, Learning assignment profiles and connector jobs do not run at the same time.

N/A

Learning A few customers have configured Learning to allow instructor and administrators records without an associated learner. These configurations are not supported for purge. All instructors and administrators must have related learner IDs.

Instructors and Administrators must have Related User IDs and the IDs Must Match [page 109]

SAP Jam SAP Jam has a separate process for purging inactive users

Alumni Data in SAP Jam Collaboration [page 109]

Workforce Analytics Workforce Analytics does not offer capabilities to purge individual user records. The source systems handle data purge, and then the changes are reflected in Workforce Analytics on the next monthly refresh.

Purging the Personal Data in Workforce Analytics [page 104]

Workforce Analytics on SAP HANA Workforce Analytics on SAP HANA automatically synchronizes the data from the source modules. When data is purged from the source module, it is also purged from Workforce Analytics on SAP HANA.

We recommend that you align the retention period in the source periods with the years of history in Workforce Analytics on SAP HANA.

N/A



Employee Central Retention time for purging import jobs is based on the number of days defined on the Company System and Logo Setting page.

Configuring Retention Period to Purge Import Jobs [page 263]

Onboarding All PDF Onboarding Compliance documents for United States of America, United Kingdom, and Australia and any compliance-related information captured as a part of Onboarding is purged when performing Master Data Purge. US Form I-9 and E-Verify related information captured as part of Onboarding is also purged when performing Master Data Purge.

NoteYou must configure the Master Data Purge with caution, as all the compliance documents and compliance-related information will get purged as part of the Master Data Purge.

NoteIt’s recommended that customers with US compliance forms (I-9 and tax forms) shouldn’t perform master data purge to avoid purging US compliance forms. The ability to configure the retention of the US compliance forms is currently not supported.

Onboarding All local documents in Onboarding 1.0, which are not uploaded to the Document Center are linked with an "HRDataId". Therefore, if the HRData is purged through DRTM purge and the document remains orphaned in the system, it can’t be purged.

N/A


Data Purge


Onboarding In Onboarding 1.0, when the Purge Selection job runs, configured rules are executed and it creates a package of maximum 1000 entries that get purged in the next run of the Purge job.

N/A

Onboarding In Onboarding 1.0, following Audit Trail Events are logged related to the document purge, which enables the customer to check whether the job execution was successful or not:

● Audit Trail Event PURGE_SELECT is logged when the configured purge rules are executed, and a package with selected documents is created.

● Event “PURGE_SELECT_FAI” is logged when the execution of purge rules fails due to some error.

● “PURGE_PROCESSING” is logged when the purge job purges one of the packages created by the purge selection job.

N/A

Recruiting Management As a system background job, the existing orphan attachments are deleted from the system. Also, if an application has been anonymized, Jobs Applied portlet will not be accessible.

N/A



Recruiting Management ● During inactive user purge, folder map entries of the user who is not a part of any requisition are deleted.

● The form data originator and the form data subject of all the forms in soft deleted Job Requisitions are updated with the system admin id, also known as the v4admin.

● The form data originator and the form data subject of all the forms in Offers are updated with the system admin id, also known as the v4admin.

● Unrated interviews that belong to applications of soft deleted Job Requisitions are deleted.

● Rated interviews that belong to applications of soft deleted Job Requisitions are reassigned to the system admin, also known as the v4admin.

● Interviews that belong to applications of soft deleted Job Requisitions are not resulted in veto.

● For the users where the Recruiting is disabled, soft purge does not check for job requisition data.

Performance & Goals In Performance Management: currently we are ONLY purging "Ask for Feedback" responses from the external users.

We are NOT purging external users identification data. For external users, e-mail address is the only identification data.

External users in Performance Management are not created as platform users in the system, they do not have a user name.

N/A

Performance & Goals While not a limitation, be aware that in Performance Management: data purge applies to PM v11, old PM v12, and PM v12 Acceleration forms.

N/A


Data Purge


Performance & Goals While not a limitation, be aware that in Performance Management and 360 Degree Multirater, an active user can own an active form, which uses an inactive form template. In that case, you can continue to purge the performance data as it is, independent of the template status.

In Data Retention Time Management (DRTM), data is purged based on the users and not based on the templates.

NoteYou can still purge Performance data based on the templates using the legacy “Purge PM or SM Data” function, as long as you are aware of and accept its limitations.

You can use module data purge to purge completed forms of both active and inactive users. You will NOT be able to use module data purge to purge incomplete forms of an inactive user or an active user. You need to use Master Data purge to purge incomplete forms of an inactive user. Forms that are incomplete will be shown in the preview report; you can then decide whether to purge incomplete forms of an inactive user. You can download the preview report from the Purge Request Monitor before you approve the purge request.

N/A

Performance & Goals While not a limitation, be aware that every employee in the system for whom the Performance Review form is launched, is considered as a Data Subject in Performance Management context.

All the form element data in the Performance Form is considered as the “Performance data”. It includes ratings, comments, attachments, feedback, and so on.

N/A



Performance & Goals While not a limitation, be aware that every employee in the system for whom the 360 Review form is launched, is considered as a Data Subject in 360 Degree Multi-rater context.

All the form element data in the 360 Review form is considered as the 360 Review data. It includes ratings, comments, and so on.

N/A

Performance & Goals While not a limitation, be aware that when a form is purged from the system, the attachments included in the form are deleted from the system as well. You can't find the attachments in the Manage Documents admin tool.

N/A

Performance & Goals The latest version of Continuous Feedback supports DRTM Continuous Performance Purge objects.

Calibration You can’t purge an inactive facilitator from a finalized session. However, you can purge the session.

N/A

Mobile Data on SAP SuccessFactors Mobile and the Mobile server will be deleted when a user is deactivated. If this process can’t be completed due to some unforeseen error or interruption, some data might remain on the Mobile server. However, this data is never visible in SAP SuccessFactors Mobile.

N/A

Mobile Any data that is purged using the SAP SuccessFactors desktop application, might not be immediately purged from Mobile because the app may not be launched or online at that time. As soon as Mobile is launched and online, the data will be purged from SAP SuccessFactors Mobile.

N/A

All As of Q1 2018, the person-based MDF object Education can’t be purged by DRTM. This object is intended specifically for Russian reporting requirements and shouldn't be used for other purposes.

N/A


Data Purge


All Changing user IDs may impact data purge functions.

Caution About User ID Conversion [page 14]

Employee Central Payroll When configuring retention times for employee data, consider that purging data required for integration with Employee Central Payroll might lead to an unintended data loss in the replication target system. In particular, consider the full transmission start date (FTSD) defined for data replication to Employee Central Payroll when defining retention times: The FTSD should be later than the latest retention date of any Employee Central entity that is contained in data replication. In other words, no integration-relevant data should be purged after the FTSD. Otherwise, data can no longer be replicated for the employee in question. And if the employee's data was completely purged, this employee can never be replicated again – even if they are rehired later.



All ● For inactive users in Metadata Framework (MDF) Custom Object module purge, termination date is considered while calculating cutoff date.

● MDF provides a Service Command script that populates the owner ID and owner type for attachments. If the object type is LSPD configuration relevant, the script sets the owner ID and owner type based on the Data Subject Field of the object on all the linked attachments. If the object type is non-LSPD configuration relevant, the script sets the owner ID as noOwner and the owner type as NOT_PROVIDED on all the linked attachments. All the remaining Generic Object attachments are set as NOT_IN_USE in the Status column.

● For MDF objects, the Audit data is Purged from concerned MDF audit tables.

● During creation of MDF instance, if a user uploads attachments multiple times into a new MDF instance (for a field of type attachment), MDF does not leave orphaned attachments, in case the user cancels creation operation of the new MDF instance.

N/A

Succession & Development, Performance & Goals

When the Data Sync setting is turned on in the performance review template, data purge for Development Objectives also deletes the relevant development goals from performance review forms. If the setting is off, the development goals, although deleted from SAP SuccessFactors

Career Development Planning, are still visible in the performance review forms. To purge the goals as part of the forms, run DRTM Performance Reviews.

N/A


Data Purge


Compensation While configuring retention times to purge Compensation audit data on the Manage Data page, the Read Access Log Period field will no longer appear as this field is inapplicable to Compensation data. To hide this field, you need to upgrade the DRTM Compensation/Variable Pay option from Upgrade Center.

Adding DRTM Objects to Your Instance [page 119]

Compensation In Compensation, while you're purging inactive users using Purge inactive users option, users who belong to the deleted worksheets will not be purged. Hence, we recommend you first purge the deleted Compensation and Variable Pay worksheets, and then purge the inactive users from the system. Use the Only purge deleted forms option from Purge Compensation/Variable Pay Data to purge deleted worksheets of users.

NoteFor user belonging to an active worksheet, you need to first remove the user from that worksheet and then remove the user.

N/A

Performance & Goals While not a limitation, be aware that when a form is purged from the system, the data relevant to the Customized Weighted Rating section in the form are deleted from the system as well.

N/A

3.6.1 User's Current Country or Region Is Used for Data Purge

Data purge in Data Retention Management is based on a user's current country or region only.

Without Employee CentralWhen you define the target users of a purge request by country or region, the purge includes all users who are currently based in that country or region and considers the retention times configured for that country or region. If a user has changed countries in the past, you cannot retain or purge data based on retention times configured for their previous country or region.

If you use an external HRIS and import users from your external system into SAP SuccessFactors, a user can only have one country/region record at a time. If a user changes country or region and you update the user's country/region record in SAP SuccessFactors, the previous value cannot be used by data purge. All future purge requests are based on the user's new country or region.


With Employee Central

If you use Employee Central as your system-of-record, you can meet this requirement by using multiple employments.

RememberIn Employee Central, a person can have more than one employment and each employment is assigned to a different platform user account. When a person changes country or region, it should typically be considered a different employment and therefore data is associated with a different platform user account. Therefore, if you use Employee Central and you need to purge any type of data based on the retention time for an employee's previous country or region, you should use multiple employments. In this way, you can purge data associated with different employments in different countries, based on different retention times.

Related Information


3.6.2 Purging the Personal Data in Workforce Analytics

Workforce Analytics does not offer capabilities to purge individual user records. We rely on the source systems to handle data purge, and then those changes are reflected in Workforce Analytics on the next monthly refresh.

Context

The only exception to this is if you have “static data” in your data cubes. “Static data” refers to data which is not refreshed during the monthly refresh process. Sometimes this implementation model is referred to as “delta loads” because we only receive the new data but keep the data for past years static.

There are a few reasons why customers have historically decided for this implementation model:

● Delta extracts due to issues with file sizes.● Customers with static systems that are no longer active and just used for historical reporting. They might be

systems that have been since shut down.

NoteAs a customer, you must review your implementation to see if you have any static data and avoid having static data going forward.


Data Purge

Procedure

1. If the static data you have is very old, you could consider deleting these historic years of data – particularly if they are from an old outdated system.

2. If you want to keep the full history, you must take ownership of all the data and send us the full dataset each month as new system extracts.This ensures that any data purge done in the source systems is reflected in Workforce Analytics.

3. If you keep a setup with static data, then you must ensure that the defined retention periods for the source data are aligned with the number of years you have the data in Workforce Analytics.For example, if the retention period for all HR data is five years, then you should not configure Workforce Analytics to show more than five years of history as this will imply that you are not honoring the data retention period.

Related Information


3.6.3 SAP SuccessFactors Learning Data Retention Time Management (DRTM) Preview Report

When you open a Data Retention Time Management (DRTM) preview report for SAP SuccessFactors Learning, you see a link to a separate report, which is generated directly from Learning.

Unlike other purge preview reports for DRTM in SAP SuccessFactors, when you look at a preview report for, Learning you see a deep link to the Learning system. Click the link to open the full preview. This is expected behavior.

NoteThis report is available only in DRTM processes, not in native-only environments.

Related Information



3.6.4 SAP SuccessFactors Learning Native-only Purge Exceptions to Data Retention Management

A few SAP SuccessFactors Learning customers cannot take advantage of Data Retention Management (DRM) because they do not use SAP SuccessFactors platform.

Native Users are Exempted from DRM

Data Retention Management (DRM) runs in the SAP SuccessFactors platform. Most Learning customers use platform, but a few customers do not. If you do not have the platform, then DRM does not run for you, so you need a separate process to trigger the deletion of native user records. A native user is one that exists only in SAP SuccessFactors, not in platform.

Native users can enter Learning in many ways: Directly from a connector from an HRIS system, self-registration, or Learning Sites. Regardless of how they enter Learning, they if they are present only in Learning then they are not a part of the platform data retention management system.

Because SAP SuccessFactors values data privacy, we accommodate the data privacy policies of customers who have not yet adopted platform. We have a process that mimics DRM for native users (those users for customers without platform). The Native User Deletion process looks for inactive native users and, based on a set of rules that you define, it deletes them from the transactional tables. The next stage, the purge process, then picks up the deleted users as if they were deleted by DRM.

If you are using the platform, then we recommend that you ignore the Native User Deletion process.

Native Users are Exempted from DRTM

Data Retention Time Management (DRTM) runs in the SAP SuccessFactors platform. Most Learning customers use platform, but a few customers do not. If you do not have the platform, then DRTM does not run for you, so you need a separate process to trigger the deletion of native user records. A native user is one that exists only in SAP SuccessFactors, not in platform.

Because SAP SuccessFactors values data privacy, we accommodate the data privacy policies of customers who have not yet adopted platform. We have a process that mimics DRTM for native users (those users for customers without platform). The Native User Data Retention process looks for inactive native users and, based on a set of rules that you define, it deletes them from the transactional tables. The next stage, the purge process, then picks up the deleted users as if they were deleted by DRTM.

If you are using the platform, then we recommend that you ignore the Native User Data Retention process.

Audit Tables are not Handled by DRM

SAP SuccessFactors Learning has special audit tables that keep the actions that users, instructors, and administrators perform in their learning tasks. The tables keep an audit trail of users' learning, instructors' teaching, and administrators' work with the system. The DRM process does not affect the audit tables.


Data Purge

Instead, audit tables are purged by the Purge Deleted User Audit History Learning automatic process. It looks for deleted users and then purges their audit history. You can exclude personal information from the audit history purge.

Single Retention Time for All Countries or Regions Configured

Unlike Data Retention Time Management (DRTM), which is used by platform customers, native-only customers must select a single retention time and apply it to all countries that they configure.

Related Information


3.6.5 Stages of User Data Removal in SAP SuccessFactors Learning

SAP SuccessFactors Learning has a process for irrevocably deleting user data. It begins with inactivation, requires deletion, and finishes by purging user data from the audit history tables.

SAP SuccessFactors Learning follows a deliberate process for irrevocably deleting user data. At the end of it, user data is removed from the system and can’t be recovered. You follow this process as part of your data privacy practice.

Transactional

The transactional stage of user data is the precursor to any data removal. In this stage, users are active employees or, in the case of external users, active users. We maintain their personal data in the transactional tables. During this stage, you can set up a partial purge to remove old data like learning history and assignments, or personal information logged in the audit tables, but the current personal history of the users remains in Learning.

Inactivation or Termination

Inactivation or termination is the first stage in data removal. Before this stage, users are in the transactional stage, but when they’re inactivated or terminated, we begin the process of purging their data completely.

● You can inactivate internal or external users directly in SAP SuccessFactors Learning Administration in the user record or you can inactivate users through a connector. You can still search for inactive users and their data is still in the transactional tables. You can easily activate them again at any time.


● You can terminate Learning native-only users in the user record or through a user connector.

NoteWhen a record is inactive, most of the system does not include that record in searches or reports. Some searches and reports allow administrators to include inactive records. Deactivating (instead of deleting it) hides it from view but keeps it for historical record. Because you cannot restore a deleted record, we recommend that you delete a record when you make a mistake (for example, if the record ID is simply incorrect) or as part of your data privacy practice.

Deletion

Deletion is the second stage of data removal. When users are deleted, the users' data is removed from the transactional tables (PA tables), but the data is preserved in the audit history tables (PH tables). At this stage, learning administrators can’t look up the user data but the users can appear on audit reports. You should delete users only when you intend to remove them completely from the system because the next stage, the purge process, looks for deleted users and removes their data irrevocably.

Deletion can happen in many different ways. Users who are deleted from the SAP SuccessFactors central user management system through standard Data Retention Management (DRM) are marked deleted in Learning. Administrators can delete users directly from the administration environment. And an automatic process can delete native users who have been inactive for a set period of time.

Purge

Purged users are irrevocably removed from the system. Their data is removed from both transactional tables and audit history tables. Users are purged through an automatic process that looks for deleted users and removes the last of their saved data from the audit history tables. After the purge process runs, the user data is no longer in the SAP SuccessFactors Learning database.

Related Information



Data Purge

3.6.6 Instructors and Administrators must have Related User IDs and the IDs Must Match

In legacy configurations, we allowed customers to create instructors and administrators without related user IDs, and this configuration still works, but it isn’t supported for purge processes and therefore not recommended. Additionally, one person's end-user ID, instructor ID, and administrator ID must match.

NoteIf you have adopted platform, then it would be very rare for you to have instructors and administrators without related user IDs. Native-only customers who haven’t adopted platform are at higher risk of having this configuration.

In legacy, native-only configurations, you could create instructors and administrators with different ID values, but in an integrated environment, one person's learner ID (end-user ID), instructor ID, and administrator ID must match. For example, all must be jsmith. In legacy, native-only configurations, it was also common to create instructors and administrators without related user IDs:

● You could go to People Instructors and add a new instructor with an empty Related User.

● You could go to System Administration Security Administrators and add a new administrator with an empty Related User.

We no longer recommend empty related users because purge requires learner user IDs ( People Users ). It cascades from the learner user ID to instructor and administrator data. You can’t operate SAP SuccessFactors Learning if learner (end-user), instructor, and administrator ID values don’t match.

Related Information

Finding Instructors Without Related Users [page 232]Configuring Search Selectors to Find Empty Related Users [page 231]Finding Learning Administrators Without Related Users [page 234]Assigning a Related User to a Learning Administrator [page 235]Important Notes About Data Purge and Data Retention Time Management [page 92]

3.6.7 Alumni Data in SAP Jam Collaboration

SAP Jam Collaboration provides options for removing the personal data of alumni users.

When a person leaves your company, their SAP Jam account is flagged as being that of an "alumni user". This change replaces their name with "Alumni" and retains their contributed content and comments. SAP Jam provides additional options to restrict viewing of an alumni's profile or to remove alumni profiles entirely, according to your data protection and privacy requirements.

For more information about these options, please refer to the SAP Jam Collaboration Administrator Guide.


https://help.sap.com/viewer/1cabd8ccb75644a4974b6be684ee7fad/LATEST/en-US/880587a1bf3f409e871d17e9d975d535.html

Related Information


3.6.8 Configuring Retention Period to Purge Import Jobs

The system automatically purges all the completed import jobs listed on the Monitor Job page depending on the retention period.

Prerequisites

Ensure that the Bizx Daily Rules Processing Batch job is created in Provisioning. You'll need to contact our Product Support to complete this task.

Procedure

1. Go to the Admin Center.2. In the Tools Search field, type Company System and Logo Setting.3. On the Company Logo page, in the Scheduled Jobs Retention Period in days field, enter the number of days by

when you'd want to purge the import jobs.

By default, it is set to 180 days.4. Click Save Company System Setting.

3.6.9 Veto Behavior in Data Purge

A veto prevents data from being purged from the system.

Module Veto Description

All Purge Freeze If an administrator adds a user to the purge freeze list, the user is not purged even if the user or users data matches the criteria for purge. This is useful, for example, in the case of labor disputes.

Employee Central Pensioner Pensioner data is not deleted during master purge

Employee Central Beneficiary Beneficiary data is not deleted during master purge


Data Purge

Module Veto Description

Employee Central Home Assignment If the user has multiple assignments and the home assignment is included in the master purge, the home assignment is not deleted

Employee Central Main Assignment If the user has multiple assignments and the primary employment is included in the master data purge before secondary assignments, the main assignment is not deleted

Recruiting Management Internal User Any user (Job Requisition Approver, Interviewer, Offer Approver) who is active in Recruiting process results in User Veto.

Performance Management Calibration A Performance Management form that is being used in a Calibration session cannot be purged.

Compensation Calibration A Compensation form that is being used in a Calibration session cannot be purged.

Related Information


3.6.10 Data Purge and Data Retention Times for Users with Multiple Employments

For users with multiple employment records in multiple countries and/or multiple legal entities, there may be confusion as to which rules to follow when setting the retention times.

Since the purge object for certain countries checks whether records must be deleted by a certain time point or even whether they may be deleted at all, not knowing which country/region or legal entity setting takes precedence for a user with a global assignment or concurrent employment may cause an admin to err.

For the DRTM Employment Information purge object, the retention time for the employment data is always based on the country/region of the legal entity of the employment.

For the DRTM Person Information, the country/region with the longest retention time for that data is the one to be used.

For example, if an employee in Germany (where the retention time is two years) had a global assignment in the UK (where the retention time is three years), then that data will only be purged after three years.

If a user has an employment record in a country or region where data retention is not legally required, then the retention time for the data is set to the longest retention found in the system.


3.6.11 Maximum Number of Users in a Purge Request

A maximum of 10,000 users can be included in single purge request.

For large organizations that are running the data purge for the first time, it may be necessary to purge more than 10,000 at once. If you need to purge a large number of users, set up multiple purge requests and use subject criteria to select fewer people in each request.

After your initial run, it's unlikely that you'll need to purge that many users at once, so a single recurring purge is likely to be sufficient.

3.7 Process for Setting Up Data Retention Time Management (DRTM)

Set up data retention time management so that you can purge data based on configurable data retention times.

Setting up data retention time management (DRTM) is a multi-step process. Here are the major steps.

1. Set up the data purge function so that it can use data retention time management (DRTM).2. Set up role-based permissions to ensure control and oversight of your data purge process.3. Set up data retention times for each type of data and each country/region or legal entity in your system.

Enablement of Data Retention Time Management (DRTM) [page 112]Here's an overview of the process for setting up data purge with data retention time management (DRTM).

Recommended Permission Settings for Data Purge Functions [page 128]Understand key concepts about role-based permission to design a purge process that restricts data purge capabilities to the appropriate roles.

Configuration of Data Retention Times [page 137]Here's on overview of how to configure data retention times used by the DRTM purge function.

3.7.1 Enablement of Data Retention Time Management (DRTM)

Here's an overview of the process for setting up data purge with data retention time management (DRTM).

Step Description More Information

Ensure prerequisites Before you get started, confirm that your system meets the prerequisites for using this function.



Data Purge


Enable Data Retention Management To check if this is already enabled, search admin tools for Data Retention Management. If it is not, follow steps to enable it.

Enabling Data Retention Management [page 114]

Decide if you want to use legal-entity based data retention

If you have Employee Central, you have the option to purge data based on the user's legal entity instead of their country or region. If you want to do this, decide which criteria (legal entity or country/region) you want to use for each target population.

TipFor any one target population, we recommend that you use either the legal entity-based or the country/region-based purge option. Trying to use both of these options for the same target population is over-complicated and can lead to conflicting purge rules that either remove or retain personal data incorrectly.

CautionIf you enable this option, be sure that you don't set up multiple purge requests for the same data and the same group of users, based on both legal entity and country/region.

Enabling Legal Entity-Based Data Retention [page 116]

Grant permissions to purge data with data retention time management

You need to grant new permissions to access the new data retention time management (DRTM) function for data protection and privacy.

Permissions for the legacy data purge function are granted separately, so if you already use Data Retention Management, you can continue to use your current process while you set up DRTM.

Allowing People to Create and Approve DRTM Purge Requests [page 117]



Enable DRTM objects The new data retention time management (DRTM) is built with MDF extension objects. You need to enable the objects that apply to the SAP SuccessFactors solutions you use.

Adding DRTM Objects to Your Instance [page 119]

Enable DRTM for each country or region To simplify your implementation, you should enable data retention time management (DRTM) for all countries in your system, using the MDF object for country/region.

Enabling Data Retention Time Management for Each Country or Region [page 120]

Set up data purge for MDF custom objects

If you use MDF custom extensions, you need to set up data purge for these objects separately. You can identify which business process the data relates to and include the custom MDF data in the relevant DRTM purge for that business process.

DRTM Data Purge for MDF Custom Objects [page 258]

Configure retention times After Data Retention Management is enabled, you need to configure data retention times for each type of data in your system.


Parent topic: Process for Setting Up Data Retention Time Management (DRTM) [page 112]

Related Information

Recommended Permission Settings for Data Purge Functions [page 128]Configuration of Data Retention Times [page 137]

3.7.1.1 Enabling Data Retention Management

Enable the Data Retention Management feature so that you can create and submit purge requests to purge employee data from your system.

Prerequisites

You have the Company System and Logo Settings permission.


Data Purge

Procedure

1. Go to Admin Center Tools Company System and Logo Settings .2. Select Data Retention Management.3. In Minimum # of approvers, specify the required minimum number of users who must approve a purge request.

For example, if you type 3, then anyone who sets up a purge request must specify three or more Approvers before they can save or submit the purge request.

4. Click Save Company System Setting to save your changes.

Results

The Data Retention Management and Purge Request Monitor pages can now be used by people with the appropriate permissions.

The data retention time management (DRTM) function recommended for data protection and privacy is not available by default. You need to set it up.

Next Steps

To use legal entity-based data retention with Employee Central, enable that next, while you're on the Company System and Logo Settings page. Then proceed with additional set-up steps.

Use role-based permissions to control access to Data Retention Management functions.

● Most customers only use one purge function, either DRTM or legacy. If you choose to use both, set up role-based permissions carefully to avoid conflicting purge rules.

● For data retention time management (DRTM), use Create DRTM Data Purge Request and Manage and Approve DRTM Data Purge Request permissions.

● For the legacy data purge function, use Create Legacy Data Purge Request and Manage and Approve Legacy Data Purge Request permissions.

● Ensure permission roles who can purge inactive users also have Manage Users permission for the appropriate target population.

Related Information

Enabling Data Retention Management [page 114]Enabling Legal Entity-Based Data Retention [page 116]Allowing People to Create and Approve DRTM Purge Requests [page 117]Enablement of Data Retention Time Management (DRTM) [page 112]


3.7.1.2 Enabling Legal Entity-Based Data Retention

Enable the ability to purge data based on the user's legal entity in Employee Central, rather than their country or region. If enabled, you can select users by legal entity when you set up a purge request.

Prerequisites

Employee Central is enabled in your system.

Data Retention Management is enabled in your system.


Context

CautionFor any one target population, we recommend that you use either the legal entity-based or the country/region-based purge option. Trying to use both of these options for the same target population is over-complicated and can lead to conflicting purge rules that either remove or retain personal data incorrectly.

If you enable this option, be sure that you haven't set up multiple purge requests for the same data and the same group of users, based on both legal entity and country/region.

Procedure

1. Go to Admin Center Tools Company System and Logo Settings .2. Select Enable legal entity-based data retention .3. Click Save Company System Setting to save your changes.

CautionDo not repeatedly toggle the legal entity-based purge option on and off in your Production system. Doing so might cause conflicting purge rules that either remove or retain personal data incorrectly.

NotePlease allow up to 30 minutes for the legal entity-based purge option to take effect before you begin to test or use it.

4. If you use Onboarding 1.0, you must make an additional setting to enable legal entity-based data retention. To do so, go to Onboarding Features and select the option Legal Entity based Data Retention under the Misc section.


Data Purge

Next Steps

Related Information

Enabling Data Retention Management [page 114]Enabling Legal Entity-Based Data Retention [page 116]Allowing People to Create and Approve DRTM Purge Requests [page 117]

3.7.1.3 Allowing People to Create and Approve DRTM Purge Requests

Give people permission to create and approve purge requests with Data Retention Time Management (DRTM).

Prerequisites

Before you grant permissions, both enable Data Retention Time Management and check the recommendations for purge roles.

You must grant permissions to users for both Learning security workflows and standard Role-Based Permissions (RBP), so any administration user must be in both Learning and Platform.

Procedure

1. To allow people in a permission role to use Data Retention Time Management (DRTM), grant the following permissions:

○ Create DRTM Data Purge Request○ Manage and Approve DRTM Data Purge Request

2. To allow people in a permission role to use the DRTM Master Data purge, ensure that the role also has the Manage Users permission for the appropriate target population.

3. Save your changes to role-based permissions.

4. If you use Learning, go to Learning Administration, and then go to System Admin Security Role Management .

5. Find the learner role that needs permission to purge and then edit it.

You might have a learner role that is reserved for users who are associated with administrators. Add it to that role.


6. Go to Workflows, and then click add one or more from list.7. Add the Run User Data Purge Request Report workflow.

NoteThe Run User Data Purge Request Report workflow is a learner role workflow, not an administrator role workflow. The administrator who runs the report must have a related user (learner) in System AdminApplication Admin Admin Management Summary Related User . That related user must:○ Have the same ID as the administrator ID (it must be spelled exactly the same).○ Be in a role that has the Run User Data Purge Request Report security workflow.

8. Click Apply Changes.9. Search Role Management again to find the administrator role that needs permission to purge, and then edit it.10. Go to Workflows, and then click add one or more from list.11. Add the View User workflow.

NoteThe View User workflow is an administrator role workflow.

12. Click Apply Changes.

Results

People in with Create DRTM Data Purge Request permission can create DRTM purge requests.

People with Manage and Approve DRTM Data Purge Request permission can review, approve, and decline DRTM purge requests.

People with Run User Data Purge Request Report permission can access the Learning purge request report and the final purge report.

Next Steps

The administrator who has the roles Create DRTM Data Purge Request and Manage and Approve DRTM Data Purge Request must be associated with a Learning user who has the role with the workflow Run User Data Purge Request Report. Check that the association between administrator and Learning user is correct.

Related Information

Enabling Data Retention Management [page 114]Enabling Legal Entity-Based Data Retention [page 116]Allowing People to Create and Approve DRTM Purge Requests [page 117]


Data Purge


3.7.1.4 Adding DRTM Objects to Your Instance

Add preconfigured MDF objects for data retention time management (DRTM) to your instance, using the Upgrade Center, so that you can use them to configure data retention times.

Prerequisites

● Metadata Framework (MDF) is enabled.● You have access to the Upgrade Center.● To enable the DRTM Compensation and Variable Pay object, you also need the Enable Feature Upgrades

permission.

Context

We recommend that you complete all available DRTM upgrade, even if you don't necessarily need to configure different retention times for each type of data. Later, you can use Data Retention Management to control which types of data you actually want to purge.

NoteTo ensure proper functioning, DRTM upgrades can’t be undone.

TipIt’s a good practice to repeat these steps periodically to ensure that you have all the latest available DRTM objects in your system. Since your initial set-up of DRTM, some object configurations may have changed or we may have delivered new objects. We recommend that you regularly visit the Upgrade Center to double-check that you’ve completed all the available DRTM upgrades.

Procedure

1. Go to Admin Center Upgrade Center .2. In the Filter By menu, select All Modules to ensure that you’re seeing all of the available upgrades.3. Scroll through the available upgrades to locate all upgrades that begin with DRTM, for Data Retention Time

Management.4. For each DRTM upgrade, do the following:


a. Click Learn More & Upgrade Now.b. Read the information provided.c. Click Upgrade Now to add the DRTM object described to your instance.

NoteIf the Upgrade Now button is disabled, either you don’t have the appropriate permissions or your instance doesn’t meet the feature prerequisites.

5. Scroll through the available upgrades again and confirm that there are no more items that begin with DRTM.6. Go to View Recently Completed Upgrades to review recent upgrades and confirm that none of the DRTM items

are labeled Feature Disabled or Upgrade Failed.

○ If you see a disabled or failed DRTM upgrade, click Retry Upgrade Now to try again.○ If you don’t, all of the available DRTM objects are successfully enabled.

Results

You can now use the enabled DRTM objects to configure data retention times, as needed.

Next Steps

Proceed to grant MDF permissions for each of these objects to users who are responsible for configuring data retention times in the system.

Related Information


3.7.1.5 Enabling Data Retention Time Management for Each Country or Region

Enable data retention for each country or region where it is required so that you can configure data retention times and create DRTM purge requests for that country or region.

Prerequisites

You have the MDF permission Manage Data and permission to edit data in the MDF object for country/region.


Data Purge

Procedure

1. Go to Admin Tools Manage Data .2. Use the first search box to find and select the MDF object Country/Region.3. For each country or region you want to enable data retention time management for, use the second search box

to find and select the country or region you want to edit.4. Open the edit screen for the selected object.

○ To configure retention times for the first time or to set a new effective date, click Insert New Record.

○ To edit an existing configuration without changing the effective date, click Take Action Make Correction .

5. In the dialog, select the effective date (the date on which you want the change to take effect), then click Proceed.

6. Set the Data Retention Enabled field to Yes.7. Click Save to save your changes.8. Repeat steps for each country or region you want to enable data retention time management for.

Results

You can now configure retention times and create DRTM purge requests for countries with Data Retention Enabled set to Yes. Countries with this configuration appear in the Manage Data tool when you configure retention times and in the Define Subject Criteria section of the purge rule set-up.

Next Steps

Proceed to setting up retention times for various purge objects, using the Manage Data tool.

Related Information

Enablement of Data Retention Time Management (DRTM) [page 112]Configuring Retention Times for Specific Types of Data [page 143]


3.7.1.6 Data Retention Management Exceptions for Benefits, Advances, and Dismissal Protection

The purge process for benefits, advances, and dismissal is different because your benefit patterns, advance requests, and dismissal protection are unique to your organization.

Objects for benefits, advances, and dismissal protection are customer-specific data. They can vary based on your benefit patterns, your advance requests, and your dismissal protection types. Because they are custom to your organization, you need to create a data retention object to handle your unique case.

3.7.1.6.1 Enabling Purge for Benefits

Enable purge for advances if you use benefits and you want to purge personal data.

Context

The purge process for benefits is unique because the data in benefits is unique to your organization. The unique process requires you to manually enable the data retention groups and manually enable the purge objects.

Procedure

1. Go to Admin Center Manage Data .2. Click Create New, select Benefits Data Retention Configuration Group, and then complete the fields.

In this field or section... Enter this information...

Group ID Type your group ID.

Group Name Type a group name. You select this group name in the second stage of enabling purge for dismissal protection.

Benefits for Enrollment Add benefits of type enrollments. Based on your configuration, enrollment records of employees created under the benefits added here will be purged.

Benefits for Claim Add all the benefits of type reimbursement. Based on your configuration, claim records of employees created under these benefits added here will be purged.

Benefits Programs for Enrollment Add benefit programs. Based on your configuration, records of benefit program enrollment of the employees under the benefit programs added here will be purged.


Data Purge

3. Click Save.

You have completed the first stage of enabling purge for dismissal protection. You created an Advances Data Retention Configuration Group.

4. Go to Admin Center Manage Data .5. Click Create New, go to DRTM Benefit Purge Objects, and then complete the form.


Purge Object Select the Group Name that you created in the first stage.

Validity Start Of Retention Time Choose a start date.

Purge Object Group This field is a read-only field that defaults to DRTM Employment Information.

Country Choose the country or region.

Unit Choose a unit for calculation such as month or year.

Retention Time For Active Employees Enter a retention period for active employees.

Retention Time For Inactive Employees Enter a retention period for inactive employees.

6. Click Save.

You have completed the second stage of enabling purge for advances. You created retention times.

Next Steps

Create a purge request for advances in the standard way.

Related Information

Configuration of Data Retention Times [page 137]Enabling Data Retention Time Management for Each Country or Region [page 120]


3.7.1.6.2 Enabling Purge for Advances

Enable purge for advances if you use advances and you want to purge personal data.

Context

The purge process for advances is unique because the data in advances is unique to your organization. The unique process requires you to manually enable the data retention groups and manually enable the purge objects.

Procedure

1. Go to Admin Center Manage Data2. Click Create New, select Advances Data Retention Configuration Group, and then complete the fields.




Advances Add the advance types. The records of employees created under these advances are purged.

3. Click Save.

You have completed the first stage of enabling purge for dismissal protection. You created an Advances Data Retention Configuration Group.

4. Go to Admin Center Manage Data .5. Click Create New, go to DRTM Employment Info Purge Objects, and then complete the form.









Data Purge



6. Click Save.

You have completed the second stage of enabling purge for advances. You created retention times.

Next Steps

Create a purge request for advances in the standard way.

Related Information


3.7.1.6.3 Enabling Purge for Dismissal Protection

Enable purge for dismissal protection if you use dismissal protection and you want to purge personal data.

Context

The purge process for dismissal protection is unique because the data in dismissal protection is unique to your organization. The unique process requires you to manually enable the data retention groups and manually enable the purge objects.

Procedure

1. Go to Admin Center Manage Data2. Click Create New, select Dismissal Protection Data Retention Configuration Group, and then complete the fields.






Dismissal Protection Add the dismissal protection types. The records of employees created under these dismissal protections are purged.

3. Click Save.

You have completed the first stage of enabling purge for dismissal protection. You created a Dismissal Protection Data Retention Configuration Group.

4. Go to Admin Center Manage Data .5. Click Create New, go to DRTM Employment Info Purge Objects, and then complete the form.









6. Click Save.

You have completed the second stage of enabling purge for dismissal protection. You created retention times.

Next Steps

Create a purge request for dismissal protection in the standard way.

Related Information



Data Purge

3.7.1.7 Testing the Initial Set-Up of Data Retention Time Management

1. Checking Data Purge Tools Are Enabled Correctly [page 127]Check that you have successfully enabled Data Retention Management.

2. Checking Countries or Regions Are DRTM-Enabled [page 128]Check that you have successfully enabled data retention time management for each country or region in your system.

3.7.1.7.1 Checking Data Purge Tools Are Enabled Correctly

Check that you have successfully enabled Data Retention Management.

Procedure

1. Log in as a user with Create DRTM Data Purge Request permission.

2. Confirm that you can go to Admin Center Tools Data Retention Management .3. Click Create New Purge Request then Select a purge request type and confirm that you can see the purge

request types beginning with DRTM in the dropdown menu.4. In the Add approvers search box, confirm that you can only find and add users who have been granted Manage

and Approve DRTM Data Purge Request permission.5. Do not add the required minimum number of approvers and try to save your request. Confirm that you cannot

save and instead see an error message indicating the required minimum number of approvers.

6. Confirm that you can go to Admin Center Tools Purge Request Monitor .

Task overview: Testing the Initial Set-Up of Data Retention Time Management [page 127]

Next task: Checking Countries or Regions Are DRTM-Enabled [page 128]


3.7.1.7.2 Checking Countries or Regions Are DRTM-Enabled

Check that you have successfully enabled data retention time management for each country or region in your system.

Procedure

1. Go to Admin Center Tools Data Retention Management and click Create New Purge Request.2. Click Select a purge request type and select one of the DRTM purge requests in the dropdown menu.3. Click Select user status and countries, then Countries.4. Confirm that you can find and select each country or region in your system in the Data Retention Management

tool.

Task overview: Testing the Initial Set-Up of Data Retention Time Management [page 127]

Previous task: Checking Data Purge Tools Are Enabled Correctly [page 127]

3.7.2 Recommended Permission Settings for Data Purge Functions

Understand key concepts about role-based permission to design a purge process that restricts data purge capabilities to the appropriate roles.

Data purge is a powerful tool that irreversibly removes data from the system. Use role-based permission carefully to ensure that the purge process has the necessary oversight and to reduce the potential for accidental deletion.

Restrict Users from Using All Purge Functions Simultaneously

The Data Retention Management tool includes three types of purge: DRTM purge function, non-DRTM purge function, and legacy purge function. While all have valid uses, we recommend that you don't give the same permission role access to all purge functions.

You can grant permission to create and approve DRTM purge requests and non-DRTM purge requests (legacy purge requests included) separately. If you've configured the DRTM purge function, it's probably necessary for your data protection and privacy requirements. You want to ensure that no one accidentally uses a similarly named legacy purge type instead.

The simplest and surest way to avoid this is to use DRTM only.

However, some customers choose to use the legacy purge as well, for certain specific purge processes. If you have to use both purge functions simultaneously, keep them separate using role-based permission. Create a different permission role for each purge function and assign it to different groups. Then ensure that people in each role know


Data Purge

which purge requests they can use. Or, alternatively, use DRTM most of the time, for most purge use cases, and only grant access to the legacy purge function temporarily when the need arises. Then remove access again.

Ensure Oversight

To reduce risk, we recommend a purge process that ensures no one person can complete the full purge process on their own.

You can ensure oversight in two ways:

● Require multiple approvers for each purge request.● Set up different permission roles for purge request creation and purge request approval.

The simplest way to ensure that oversight is to create one purge role with both permissions to both create and approve purge requests, but require multiple approvers. Or, alternatively, you can separate these actions into different permission roles assigned to different people.

Restrict Access to Purge Information of DRTM Purge Requests

Any user with the permission to access Data Retention Management have access to all purge requests submitted in your company's instance. To strengthen data protection and privacy, we recommend restricting access to purge reports of DRTM purge requests based on countries or regions with DRTM enabled.

Assign a Target Population for Purging Inactive Users

Role-based permissions to create or approve purge requests don’t require a target population, but purging inactive users does. To completely remove user accounts and basic user information from the system, the user who initiates the purge request needs to have Manage Users permission for the target population that is included in the purge set-up.

The simplest way to set up target permission is to create one purge role that can purge all inactive users and give that role a target population of Everyone. Or, alternatively, if required by your business, you can set up more robust data purge controls using multiple permission roles and permission groups, with different target populations.


Related Information

Enablement of Data Retention Time Management (DRTM) [page 112]Configuration of Data Retention Times [page 137]

Permission to Edit the Purge Freeze List [page 215]


Setting Up a Simple Purge Role for Data Retention Time Management [page 133]DRTM Purge Permissions [page 130]Prerequisites for Data Retention Time Management [page 17]

3.7.2.1 DRTM Purge Permissions

To successfully purge data, the purge admin user needs to have all of the relevant permissions required to delete the types of data included in the purge.

For example, as an administrator, to delete basic user information you need to have the Manage Users permission. The DRTM Master Data purge request deletes this basic user information for inactive users. So, as a purge user submitting a Manage Users purge request, you need to have the Manage Users permission in order to successfully execute the purge.

Purge Request Type Permissions

Create DRTM Data Purge Request Grants the ability to create and submit a DRTM purge request.

This permission has no target population, so someone with this permission can submit a request to purge anyone's data.

Manage and Approve DRTM Data Purge Request - Grants the ability to approve a DRTM purge request.

This permission has no target population, so someone with this permission can approve a request to purge anyone's data.

Remove Preview and Complete Reports for DRTM Data Purge Request

Grants the ability to manually delete preview reports and final complete reports from storage.

Additional access control based on DRTM-enabled countries or regions

Grants the ability to access purge reports or approve DRTM purge requests when the target data of a DRTM purge request is limited to countries or regions with DRTM enabled.

NoteThis permission is only required when you have enabled Additional access control based on DRTM-enabled

countries or regions in Admin Center Company

System and Logo Settings Data Retention

Management .


Data Purge

Purge Request Type Permissions

Manage Users To completely remove user accounts and basic user information from the system, the user who initiates the purge request needs to have Manage Users permission for the target population that is included in the purge set-up.

ExampleFor example, to run a master data purge of all inactive users in Germany, the user who initiates the purge request needs to be a member of a permission role that: (1) includes the Manage Users permission; (2) includes inactive users in Germany within its target population. If the user who initiates the purge does note have Manage Users permission for users in Germany, the purge will fail and appear as an error in the purge report.

Run Learning data purge For master data purge, the matching user in Learning must have permission to the security workflows: View Student and Delete Student.

Security workflows are the LMS equivalent of RBP, but you set them up in the LMS.

For DRTM Learning purge, no special security workflows are necessary on the Learning side to run this purge.

RememberIn Learning, you must have a platform user_sysid that matches the admin id and the user (learner) id exactly. For example, if your platform user is jdoe, then you must have an admin id jdoe (exact match) and a user id jdoe in Learning. This is for the user who runs the purge after approving. This is because the master data purge calls an API for both the get report and the delete (purge) user APIs. We take the user sysID from platform and plug it into the permissions to call the api in learning. So a jdoe in platform calls the api as a jdoe in Learning.

View Learning purge reports Student workflow: Run User Data Purge Request Report

Related Information



3.7.2.2 Enabling Access Control to Purge Reports of DRTM Purge Requests

Restrict access to purge reports of DRTM purge requests based on countries/regions to strengthen data protection and privacy.

Context

The following purge requests don't support access control based on countires/regions:

● DRTM Employment Information Purge● DRTM Person Information Purge● DRTM Time Management Purge● DRTM Benefits Management Purge● DRTM Onboarding Purge● DRTM Onboarding 1.0 Purge● DRTM Inactive Application Purge● DRTM Inactive Candidate Purge● DRTM Recruiting Read Access Log Purge● DRTM Workflows Purge

Procedure

1. Go to Admin Center Company System and Logo Settings Data Retention Management .2. Select Additional access control based on DRTM-enabled countries or regions.

Results

You have enabled access control to DRTM purge requests. When the target data of a DRTM purge request is country/regionspecific, approvers need to have the permission Additional access control based on DRTM-enabled countries or regions and are assigned with corresponding countries/regions in Role-Based Permission. Otherwise, approvers can't approve or decline the purge request, or access preview or final purge report.

NoteIt takes up to 24 hours for changes to Role-Based Permission in Admin Center take effect and generate new permissions.


Data Purge

Example

Target User Country/Region Approver Permission Required

Target users are all in the United States. Additional access control based on DRTM-enabled countries

or regions United States (USA)

Target users are all in China. Additional access control based on DRTM-enabled countries

or regions China (CHN)

Target users from the United States and China are both included.

Both Additional access control based on DRTM-enabled

countries or regions China (CHN) and United States (USA)

Next Steps

Assign the permission Manage Data Purge Additional access control based on DRTM-enabled countries or regions in Role-Based Permission to approvers and choose countries/regions for them so that they can access DRTM purge reports and approve DRTM purge requests.

Related Information


3.7.2.3 Setting Up a Simple Purge Role for Data Retention Time Management

Set up a simple permission role for all users involved in your data purge process with data retention time management (DRTM).

Prerequisites

You're familiar with role-based permissions and able to manage them for your organization.


Context

These steps describe the simplest way to get started using data retention time management with a simple purge role that contains all the necessary permissions. If required by your business case, you can use role-based permissions to set up a more robust data purge process using multiple roles, groups, or target populations.

Procedure

1. Create an RBP role for people who use the data purge function.

For example, type Data Purge as the role name.

2. Add the following permissions to the role.

○ Create DRTM Data Purge Request○ Manage and Approve DRTM Data Purge Request○ Remove Preview and Complete Reports for DRTM Data Purge Request ○ Additional access control based on DRTM-enabled countries or regions and countries/regions selected.

NoteThis permission is only required when you have enabled Additional access control based on DRTM-enabled countries or regions in Admin Center Company System and Logo Settings Data Retention Management .

○ Manage Users3. Create an RBP group defining a small set of people who are allowed to permanently purge data from the

system.

For example, type Purge Admin as the group name.

4. In Grant this role to..., select your purge admin group so that users in this group can use the data purge function.

For example, grant the Data Purge role to the Purge Admin group.

5. In Grant this role to Edit Granting , specify the target population Everyone so that users in this role can purge data for any user in your system.

CautionAssigning a target population of Everyone gets you started with the simplest data purge configuration, allowing everyone in the role to perform all steps in the data purge process. However, your business process might require stricter controls. For example, you might set up multiple purge roles and groups, so that purge users can only run a full master data purge for a specific target population.

For example, in a simple set-up, create one permission role Data Purge and assign it to a permission group Purge Admin with a target population of Everyone.

To create a role for purge users who can only purge inactive users in North America, you create a permission role North America Data Purge and assign it to a permission group North America Purge Admin with a target population of all users in North America. Purge users in this role can only successfully purge inactive


Data Purge

users in North America with the master data purge. They can run other types of DRTM purge requests for all users because other DRTM purge request types do not require a target population.

6. Save changes to the RBP role.7. Ensure that two or more approvers are required for data purge so that users in this role cannot permanently

purge data on their own.

a. Go to Admin Center Tools Company System and Logo Settings .b. Under Data Retention Management, in the Minimum # of approvers field, enter an integer value of 2 or

more.c. Click Save Company System Setting to save your changes.

Results

Now, all users in the new purge role can create, submit, approve, and decline any type of DRTM purge request, for all users in your system.

However, no one in the role can purge data on their own. At least one other approver is required, according to the minimum number you configured.

Next Steps

If you are using SAP SuccessFactors Learning, you need to ensure that the same group of users who are assigned to a purge role in role-based permissions also have the required security workflows in the LMS.

Related Information

Recommended Permission Settings for Data Purge Functions [page 128]SAP SuccessFactors Learning Security Permissions [page 135]Changing the Minimum Number of Approvers for Purge Requests [page 222]

3.7.2.4 SAP SuccessFactors Learning Security Permissions

When you apply security permissions to a role, you indicate the actions that the role can take on specific entities or pages.

A security permission in SAP SuccessFactors Learning defines what a security role can do with an entity. It answers the question, what can administrators in this role do with users? For example, they can search learning items, add learning items, or edit learning items but not delete learning items.

In most cases, permissions follow this simple pattern:


● Add an entity (for example, add learning items)● Edit an entity (for example, edit learning items)● Search for an entity (for example, search for learning items)● View an entity (for example, view learning items)● Copy an entity (for example, copy learning items)● Delete an entity (for example, delete learning items)

In some cases, however, a permission doesn't fit this pattern. For example, you can select Run ad-hoc Item Evaluation Report to give the role permission to run the ad-hoc evaluation reports. When the permission doesn't fit the simple pattern, it’s apparent from their name what they control.

Permissions, by themselves, can control what users in a role can do in the system, but you often want to restrict the role further. For example, you want an administrator role to add learning items, but in the Americas domain only. Or you want to control whether a role can work on active or inactive learning items. These more precise permissions are handled by Entity Restrictions, Functional Restrictions, and Permission Restrictions.

System Administration Security Role Management Permissions contains all the permissions associated with the security role.

Related Information


3.7.2.5 Adding or Removing Security Permissions in SAP SuccessFactors Learning Roles

Add or remove security permissions to or from a role in SAP SuccessFactors Learning if you adjust an existing role with new permissions.

Context

When you adopt new features or periodically review your security roles, add security permissions to a role or remove them from a role.

Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to System Administration Security Role Management .

2. Find and open the role that you want to edit.


Data Purge

3. Click Permissions.4. To add a permission, click add one or more from list and then find and add the permissions.5. To remove a permission, find it in the Update the Permissions for the Role, click its Remove box, and then click

Apply Changes.

TipTo find the permission quickly, click Expand All and press CTRL + F to use your browser's find functionality to locate the permission.

Related Information


3.7.3 Configuration of Data Retention Times

Here's on overview of how to configure data retention times used by the DRTM purge function.

Before you can purge data with data retention time management (DRTM), you first need to configure data retention times for each type of data in the system.


Understand retention times and base dates

Retention times for each type of data are calculated from a base data that is specific to that type of data.

Data Retention Time [page 138]

Base Dates for Retention Time Calculation [page 151]

Grant permissions Give people in the appropriate roles the MDF permissions required to configure retention times using MDF tools.

Permissions Required to Configure Data Retention Times [page 139]

Configure the base date to purge Job Applications in Recruiting Management.

If you are using Recruiting Management, you should decide which date to use for purging Inactive Job Applications.

Selecting the Date Used for Retention Time of Job Applications [page 157]

Configure retention times for user data. Configure data retention times for each type of data and each country/region or legal entity in your system.

Configuring Data Retention Times [page 139]



Related Information

Enablement of Data Retention Time Management (DRTM) [page 112]Recommended Permission Settings for Data Purge Functions [page 128]

3.7.3.1 Data Retention Time

Data retention is the continued storage of an organization's data for legal compliance and other business reasons. The period of time that your organization can or must retain a particular type of data is called its retention time.

Specific retention times are required for a number of reasons, such as:

● Regulatory requirements● Business needs● Involvement in litigation● Financial reporting

The required retention time for a specific type of data can vary between countries or regions according to a user's employment status.

In SAP SuccessFactors, you can configure different retention times for different types of data, using Data Retention Time Management.

In Onboarding, you can configure different retention times for different objects of the onboarding process. The exact end date of the retention period is determined by a base date, which is the date from which retention time is calculated. In Onboarding, the base date is the new hire's start date.

ExampleIf you configure the retention time for new hire data to be seven years, the retention time for a given form would be seven years after the respective new hire's start date.

NoteFor canceled onboarding scenarios, the base date would be the date when onboarding is canceled.

For more information about configuring data retention times, refer to the Related Information section.

Related Information

Data Retention Time Management [page 16]Configuration of Data Retention Times [page 137]Base Dates for Retention Time Calculation [page 151]


Data Purge

3.7.3.2 Permissions Required to Configure Data Retention Times

To configure data retention times, using Metadata Framework (MDF) tools, you need certain role-based permissions.

Data retention times for each DRTM purge object are stored in a corresponding retention time object. To configure retention times, you need permission to edit data in each MDF object used to store this information.

To configure data retention times in your system, here are the role-based permissions you need:

● Administrator Permissions Metadata Framework Manage Data permission is required to access to the MDF Manage Data tool and edit MDF data in general.

● MDF object-level edit permissions are required for each object listed in the User Permissions Data Retention Management category.For each object listed, you need the following permissions:○ View Current

View HistoryCreateInsertCorrectImport/Export.

CautionDon't assign the Delete permission. You don't need the Delete permission to update retention times. But objects in DRTM Onboarding Data aren't recoverable once being deleted.

○ Do not check Field Level Overrides permission.

3.7.3.3 Configuring Data Retention Times

Configure data retention times for each data purge use case so that data in your system is retained for the required period before it can be purged.

Prerequisites

To configure retention times for a specific type of data, you must first have permission to manage the MDF object where retention times are stored. The exact permission name varies depending on the data type, but all of relevant permissions are listed in role-based permissions under the User Permissions Data Retention Managementcategory.


Context

The exact steps and requirements for configuring retention times vary depending on your use case. You may need to complete one or more of the following tasks, according to your business requirements.

Configuring Retention Times for the Master Data Purge [page 140]Configure data retention times for the master data purge to ensure that inactive user accounts and their associated data are retained for the required period before they can be purged.

Configuring Retention Times for Specific Types of Data [page 143]Configure data retention times for each DRTM purge object to ensure that the data in each object is retained for the required period before it can be purged.

Configuring Retention Times for Audit Data [page 146]Configure retention times for different types of audit data, for both active and inactive users, to ensure that it is retained and available for audit reporting for the required period before it can be purged.

3.7.3.3.1 Configuring Retention Times for the Master Data Purge

Configure data retention times for the master data purge to ensure that inactive user accounts and their associated data are retained for the required period before they can be purged.

Prerequisites

● Determine the required retention time for each type of data and for each country or region, in accordance with local data protection and privacy laws and your organization's data retention policy.

● Enable the DRTM Master Data object in the Upgrade Center.● Enable data retention time management (DRTM) for each country or region in the MDF object for country/

region.● You have the MDF permission Manage Data and permission to edit all the required MDF objects.

Context

Configure a retention time for the master data purge for each country or region in your system, whether it is required by local law or not. This simplifies your implementation with the use of a single tool (DRTM) and ensures that you are ready to meet future data purge requirements as they arise.

If no retention time is configured, the master data purge cannot run successfully.

CautionThe retention time configured for the master data purge overrides all other retention times. When you run a master data purge, it purges all data based on this single, common retention time and ignores any other retention time configured for each specific type of data.


Data Purge


For example, if you want to be able to purge data for people in Germany based on their legal entity, you should plan to always do so and never purge them based on their country or region. To do this, configure Time Configuration for Legal Entity-Based Data Retention but not Time Configuration for Country/Region-Based Data Retention.

Similarly, if you want to purge data for people in France based on their country or region, configure Time Configuration for Country/Region-Based Data Retention but not Time Configuration for Legal Entity-Based Data Retention.

Procedure

1. Go to Admin Center Tools Manage Data .2. Find and select DRTM Master Data in the first search box.

3. Find and select USER (USER) in the second search box.

4. Open the edit screen for the selected object.



5. Select an effective date in the dialog and click Proceed.

NoteThe effective date you set here is the date on which your configuration changes take effect. If you select a future date, the retention times you configure now are not considered by purge requests until that date. For example, if you are changing the retention time in response to a change in local law that goes into effect on a certain date in the future, you can configure your change to take effect on the same day as the new law. If you want the change to take effect immediately, use the current date, which is selected by default.

6. Configure retention times in the Time Configuration for Country/Region-Based Data Retention section so that you can purge inactive user accounts and their associated data based on the user's country or region.a. Select the country or region.

NoteOnly countries or regions that use data retention time management appear in the dropdown menu. If you do not see the one you're looking for, check the MDF object for country/region and make sure that the attribute Data Retention Enabled is set to Yes.

b. Enter the time unit and time period for each country or region.

○ Time Unit is the unit used to calculate retention times. You can choose months or years.


○ Inactive Period is the length of time, in months or years, for which the data is retained for inactive users. For example, if you select a time unit Year and an inactive period of 3, then inactive user accounts and their associated data are retained for three years before they can be purged.

CautionThe retention time you configure in this step overrides all other retention times that have been configured for specific types of data. The DRTM Master Data only considers the retention time configured for the USER (USER) purge object and purges all data based on that time.

NoteThe minimum allowable retention time for inactive users is one month.

c. Repeat for each country or region in your system.

RememberConfigure retention times for every country or region in your system, not just for those required by local law. This enables you to avoid using two types of purge (DRTM and non-DRTM) in parallel, which is not recommended and can lead to confusing or conflicting purge rules that are difficult to manage.

7. If the option is enabled in your system, configure retention times in the Time Configuration for Legal Entity-Based Data Retention section so that you can purge inactive user accounts and their associated data based on the user's legal entity in Employee Central.a. If you see a Details link in the "More" column, click Details so that you can see all fields. Only the first few

fields are displayed by default but you can see all of them in the Details dialog.b. Select a country or region.c. Select a legal entity in Employee Central.d. Enter the Time Unit and Inactive Period for each legal entity, following the same steps as you would for

retention times based on country or region.e. Repeat for each legal entity in your system.

8. Click Save to save your retention times.

Results

The DRTM Master Data purge request can now use the configured retention times to determine whether inactive users and their data can be purged.

Next Steps

If you are a Learning customer, you must also set up retention times in the Purge Deleted User Audit History automatic process because master data purge purges users from Learning transactional tables but not history tables. (In this case, audit means the data that supports an audit of users' learning, not the auditing of personal data for data protection and privacy.) The Purge Deleted User Audit History is a non-standard purge process because it affects only Learning.


Data Purge

Related Information

Enabling the Purge Deleted User Audit History Job in Learning [page 158]

3.7.3.3.2 Configuring Retention Times for Specific Types of Data

Configure data retention times for each DRTM purge object to ensure that the data in each object is retained for the required period before it can be purged.

Prerequisites


● Enable all the required DRTM objects in the Upgrade Center.● Enable data retention time management (DRTM) for each country or region in the MDF object for country/


Context

Configure a retention time for each type of data and each country or region in your system, whether it is required by local law or not. This simplifies your implementation with the use of a single tool (DRTM) and ensures that you are ready to meet future data purge requirements as they arise.

CautionDo not follow these steps to configure retention times for the master data purge or the audit data purge. Those retention times require slightly different steps.





Procedure

1. Go to Admin Center Tools Manage Data .2. In the first search box, type the name of the DRTM purge request type that includes the purge object you want

to configure retention times for.

ExampleFor example, type DRTM Learning Data to find and select the DRTM Learning Data Purge purge request.

TipIf you're not sure of the name, first type DRTM to filter search results and then scroll through the remaining list to find the one you want.

3. In the second search box, select the purge object you want to configure retention times for.

ExampleFor example, to configure the retention times for Learning Assignments and History, select DRTM_LEARNING_ASSIGNMENTS_AND_HISTORY.




CautionDon't delete any object. Objects in DRTM Onboarding Data aren't recoverable once being deleted.



6. Configure retention times in the Time Configuration for Country/Region-Based Data Retention section so that you can purge data based on a user's country or region.a. Select the country or region.


Data Purge



○ Time Unit is the unit used to calculate retention times. In most cases, you can choose months or years. In some cases, you can also choose days.

○ Time Period is the length of time (in days, months or years) for which data in the selected purge object is retained. For example, if you select a time unit Year , an active period of 5, and an inactive period of 3, then the data is retained for five years while the user is active and for three years after the user becomes inactive.Time periods and display labels vary by purge object. Here are the most common ones:

Time Period Description

Active Period

activePeriod

Active Users

This is the length of time (in days, months, or years) that this type of data must be retained for active users.

Inactive Period

inactivePeriod

Inactive Users

This is the length of time (in days, months, or years) that this type of data must be retained for inactive users.

CautionThe retention time you configure for each specific type of data is overridden by the master data purge. To avoid confusion, always configure a retention time for each specific type of data that is shorter than that of the USER (USER) purge object used by the master data purge.

NoteFor most purge types, the minimum allowable retention time is one month. In some cases, it is one day.

c. Repeat for each country or region in your system.

RememberYou need to configure retention times for every country or region in your system, not just those for which it is required by local law. This enables you to avoid using two types of purge (DRTM and non-DRTM) in parallel, which is not recommended and can lead to confusing or conflicting purge rules that are difficult to manage.

7. If the option is enabled in your system, configure retention times in the Time Configuration for Legal Entity-Based Data Retention section so that you can purge data based on a user's legal entity in Employee Central.

a. If you see a Details link in the "More" column, click Details so that you can see all fields. Only the first few fields are displayed by default but you can see all of them in the Details dialog.


b. Select a country or region.c. Select a legal entity in Employee Central.d. Enter the time unit and time period for each legal entity, following the same steps as you would for

retention times based on country.e. Repeat for each legal entity in your system.

8. Click Save to save changes to the object.9. Repeat these steps for each purge DRTM purge request type and each of its corresponding DRTM purge

objects.

Results

A DRTM purge request can now use the configured retention times to determine whether a given type of data can be purged.

Related Information


3.7.3.3.3 Configuring Retention Times for Audit Data

Configure retention times for different types of audit data, for both active and inactive users, to ensure that it is retained and available for audit reporting for the required period before it can be purged.

Prerequisites


● Enable all the required DRTM objects in the Upgrade Center.● Enable data retention time management (DRTM) for each country or region in the MDF object for country/


Context

Configure retention times for audit data only if you want to purge audit data only, for both active and inactive users, using the DRTM Audit Data purge. If your only requirement is to make sure that audit data is eventually


Data Purge

purged, along with all other inactive user data, you may want to use the DRTM Master Data purge instead, which includes audit data.

You cannot purge audit data for active users only. The DRTM Audit Data purges audit data for both active and inactive users.

You cannot purge audit data for inactive users only. You can either use the DRTM Master Data purge to purge all data for inactive users, including audit data, or use the DRTM Audit Data purge to purge only audit data but for all users, both active and inactive.

CautionAfter audit data is purged, it is no longer available in audit reports. Be sure to generate the required audit reports and save them in your records before you purge audit data.




Procedure

1. Go to Admin Center Tools Manage Data .2. Find and select the DRTM Audit Data Purge in the first search box.

3. For each type of audit data that you want to configure a retention time for, find and select the corresponding purge object listed in the second search box.

NoteBe sure to complete these steps for the MASTER_DATA (MASTER_DATA) audit data purge object, at a minimum.

Currently, you must configure a retention time for this audit data purge object in order to successfully execute a DRTM Audit Data purge. Otherwise, the purge fails. If you don't have a business requirement to specify a retention time for this type of audit data, set a retention time that is equal to that of the DRTM Master Data purge. That way, this audit data is retained as long as possible, until the user account is completely and permanently purged from the system.







6. Configure retention times in the Time Configuration for Country/Region-Based Data Retention section so that you can purge audit data, for both active and inactive users, based on the user's country or region.a. Select the country or region.



○ Time Unit is the unit used to calculate retention times. You can choose months or years.○ Change Log Period is the length of time, in months or years, for which change audit data, for both

active and inactive users, is retained. For example, if you select a time unit Year and a change log period of 3, then the specified type of audit data is retained for three years before it can be purged.

○ Read Access Log Period is the length of time, in months or years, for which read audit data, for both active and inactive users, is retained. For example, if you select a time unit Month and a read access log period of 6, then the specified type of audit data is retained for 6 months before it can be purged.

CautionThe retention times you configure for audit data are overridden by the master data purge. To avoid confusion, always configure retention times for audit data that are shorter than that of the USER (USER) purge object used by the master data purge.

NoteThe minimum allowable retention time for audit data is six months.

c. Repeat for each country or region in your system.7. If the option is enabled in your system, configure retention times in the Time Configuration for Legal Entity-

Based Data Retention section so that you can purge audit data, for both active and inactive users, based on the user's legal entity in Employee Central.a. If you see a Details link in the "More" column, click Details so that you can see all fields. Only the first few

fields are displayed by default but you can see all of them in the Details dialog.b. Select a country or region.


Data Purge


c. Select a legal entity in Employee Central.d. Enter the Time Unit, Change Log Period, and Read Access Log Period for each legal entity, following the

same steps as you would for retention times based on country or region.e. Repeat for each legal entity in your system.

8. Repeat these steps for each type of audit data that you want to configure a retention time for, using the search boxes at the top of the page.

Results

The DRTM Audit Data purge request can now use the configured retention times to determine whether different types of audit data can be purged.

Related Information

Configuration of Data Retention Times [page 137]Purge of Audit Data [page 44]DRTM Audit Data Purge [page 61]Configuring Retention Times for Audit Data [page 146]Purging Audit Data for Active and Inactive Users with DRTM [page 165]Audit Data Purge Objects [page 149]

3.7.3.3.3.1 Audit Data Purge Objects

A list of audit data purge objects, for which you can configure data retention times.

You can configure a different retention time for each audit data purge object.

NoteThe DRTM Master Data purge request does not consider these retention times. In a master data purge, audit data is purged, like all other data, based on a single common retention time.

Solution Audit Purge Objects

All DOCUMENT_MANAGEMENT


Solution Audit Purge Objects

All EMPLOYEE_PROFILE

All MASTER_DATA

Analytics and Reporting REPORTING

Analytics and Reporting WFA

Calibration DRTM Calibration Data


Compensation SPOT_AWARDS

Employee Central BENEFITS

Employee Central EMPLOYMENT_INFORMATION

Employee Central PERSON_INFORMATION

Employee Central TIME

Employee Central WORKFLOWS

Employee Central Payroll PAYROLL_RESULTS

Learning LMS

Onboarding ONBOARDING

Performance and Goals DRTM Continuous Performance

Performance and Goals GOAL_MANAGEMENT

Performance and Goals MULTIRATER

Performance and Goals PERFORMANCE_MANAGEMENT

Recruiting RECRUITING

NoteThe same retention time is used for both internal and external candidates, but the data is purged differently. To purge audit data about internal candidates, use DRTM Audit Data Purge. To purge audit data about external candidates, use DRTM Recruiting Read Access Log Purge.

Succession and Development CAREER_WORKSHEET

Succession and Development DEVELOPMENT_GOAL

Succession and Development MENTORING

Succession and Development Succession

Data Retention Management DATA_RETENTION_MANAGEMENT


Data Purge

3.7.3.4 Base Dates for Retention Time Calculation

The base date is the date from which retention times are calculated. For example, the base date for a Performance Reviews purge is the Performance Management form completion date. That means that if you configure the retention time for Performance Reviews to be, say, seven years, the retention time for a given form would be seven years after its completion date.

Base Dates for Retention Time Calculation

Solution

Retention Time Configura-tion Group

(first menu in Manage Data)

DRTM Purge Object

(second menu in Manage Data) Base Date

All DRTM Master Data User Termination date

NoteFor employees managed in Employee Central, data purge considers the employment termination date in Employee Central. For other employees, it considers the standard user field companyExitDate as the termination date.

All DRTM Audit Data Purge Audit Data Purge Objects [page 149]

Creation date of the audit log

All DRTM MDF Custom GO Purge Object

Custom object ● Active users: configurable. Taken from the date field of the selected custom object.

● Inactive users: termination date.

Calibration DRTM Calibration Calibration Subject Session Approval date


Worksheet Data Completion date


Statements Statement creation date

Compensation DRTM Rewards and Recognition

Spot Awards Launch date

Employee Central DRTM Benefits Purge Objects <Dynamic Object for Benefits Enrollment>

Valid Until date


Solution



DRTM Purge Object


Employee Central DRTM Benefits Purge Objects <Dynamic Object for Benefits Claim>

End date of claim window

Employee Central DRTM Benefits Purge Objects <Dynamic Object for Benefit Program Enrollment>

Valid Until date

Employee Central DRTM Employment Info Purge Objects

Apprenticeship End Date


Compensation Termination date (effective end-date)


Cost Distribution Termination date (effective end-date)


Income Tax Declaration End Date of the Fiscal Year


Job Relationships Termination date (effective end-date)


Non-Recurring Pay Date of issue


Payment Information Termination date (effective end-date)


Advances Period End Date (Eligibility Valid Until).

If there is a recovery for the Advance enabled, then the base date is the date of the last installment (last Payment Date).


Employee Dismissal Protection

Protection End Date

Employee Central DRTM Person Info Purge Objects

Addresses Termination date (effective end-date)


Dependents Termination date (effective end-date)


Email Termination date (effective end-date)


Data Purge

Solution



DRTM Purge Object



Emergency Contact Info Termination date (effective end-date)


National ID Card Termination date (effective end-date)


Personal Details Termination date (effective end-date)


Phone Termination date (effective end-date)


Social Account Termination date (effective end-date)

Employee Central DRTM Time Info Object Alerts Date of Time Management Alert object

Employee Central DRTM Time Info Object External Accrual Calculation Base

Date of Accrual Calculation Base object

Employee Central DRTM Time Info Object Temporary Time Information End date of Temporary Time Information object

Employee Central DRTM Time Info Object Time Account Payout Posting date of the "Time Account Payout" object

Employee Central DRTM Time Info Object Time Sheet End date

Employee Central DRTM Time Info Object <Dynamic Group for Time Account Type: TimeManagementRetentionGroup>

● Time Account End Date● Time Account Detail Post

ing Date

Employee Central DRTM Time Info Object <Dynamic Group for Time Type: TimeManagementRetentionGroup>

Employee Time End Date

Employee Central DRTM Workflow Purge Objects

All Workflows Last modified date

Employee Central DRTM Workflow Purge Objects

Completed Workflows Last modified date

Employee Central Payroll DRTM Payroll Results Employee Payroll Run Results End date of IN Period

Employee Central Payroll DRTM Payroll Data Maintenance Task

Payroll Data Maintenance Task Current Task Creation Date


Solution



DRTM Purge Object


Employee Profile DRTM Employee Profile Background Termination date


Employee Profile DRTM Employee Profile Feedback Termination date


Employee Profile DRTM Employee Profile Introduction Termination date



Data Purge

Solution



DRTM Purge Object


Employee Profile DRTM Employee Profile Photo Termination date


Learning DRTM Learning Data Purge User Personal Information Last updated timestamps in the audit record to be deleted (user personal information in Learning deletes audit data).

Learning DRTM Learning Data Purge Learning Assignments and History

Last updated timestamps for removing assignment or history, but learning completion date for removing completion data, internal learning events, or external learning events.

Onboarding DRTM Onboarding Candidate Info

Candidate Info Start Date

Performance and Goals DRTM 360 Reviews 360 Review Form Form completion date

Performance and Goals DRTM Continuous Performance

Continuous Performance Last Modified date

Performance and Goals DRTM Objective Management Business Goals Last modified date for the goal

Performance and Goals DRTM Performance Reviews Performance Reviews Performance Management form completion date

Recruiting DRTM Candidate Profile

These are purge objects in the DRTM Inactive Candidate purge.

Candidate Last login date


Solution



DRTM Purge Object


Recruiting DRTM Job Application

These are purge objects in the DRTM Inactive Application purge.

Application Three options available:

● last modified date● disposition date● job requisition closure

date

Succession and Development DRTM Career Worksheet Career Worksheet Date on which the target role was added to the worksheet

Succession and Development DRTM Learning Activity Development Transcript Learning

Date on which the learning activity was last modified

Succession and Development DRTM Development Objective Development Objective Date on which the goal was last modified

Succession and Development DRTM Mentoring Program Mentoring Program Mentees Last modified date

Succession and Development DRTM Mentoring Program Mentoring Program Mentors Last modified date

Succession and Development DRTM Mentoring Program Mentoring Program Owners Last modified date

Succession and Development DRTM Succession Purge Succession Nominations Inactive users: Termination date


Active users: Date on which the succession nomination was last changed


Data Purge

Solution



DRTM Purge Object


Succession and Development DRTM Succession Purge Position Incumbent Inactive users: Termination date


Active users: No purge action is taken

Related Information

Data Retention Time Management [page 16]Data Retention Time [page 138]Configuration of Data Retention Times [page 137]DRTM Purge Request Types [page 47]

3.7.3.5 Selecting the Date Used for Retention Time of Job Applications

Select the base date used for retention time calculation for Job Applications.

Procedure

1. Go to Admin Center Manage Recruiting Settings DRM 2.0 settings .2. To purge Job Applications based on the last modified date, select Use Application Last Modified date to start

the Application aging for purge..


3. To purge Job Applications based on the disposition date, select Use Application Disposition date to start the Application aging for purge..

4. To purge Job Applications based on the Job Requisition closure date, select Use Job Req Closure date to start the Application aging for purge..

3.7.3.6 Enabling the Purge Deleted User Audit History Job in Learning

Enable the purge deleted user audit history job to periodically purge the audit history of deleted users. The job removes, in an unrecoverable way, all compliance history data about a user.

Prerequisites

Before users can be purged from history tables, they must first be deleted from transactional tables, so you must set up a process to handle transactional tables:

● Most customers are integrated with SAP SuccessFactors platform. If you use SAP SuccessFactors platform, then chances are that you set up Data Retention Time Management (DRTM), both the master data purge and the learning data purge.

● A few customers aren’t integrated with the platform. If you aren’t integrated, then you must set up the Delete Inactive Native Users process. This process acts as DRM for customers who haven’t yet integrated with the platform.

● Any customer can go to a user, instructor, or administrator record and delete the record manually.

Context

NoteIn this context, the word audit and audit history means audit for compliance. It’s the data that shows to compliance auditors, for example, who approved enrollment and on what date.

SAP SuccessFactors Learning uses the Purge Deleted User Audit History process to irrevocably remove data from the PH tables, which are the audit history of SAP SuccessFactors Learning. Deletion is a prerequisite of the purge process, so all user data is already removed from the PA tables (the transactional tables). Deletion, in this case, means any user who has Delete as the final action in the user history table (PH_STUDENT). After you purge a user audit history, you can’t recover any user information.


Data Purge

Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to System Administration Automatic Processes Purge Deleted User Audit History .

2. Schedule the automatic process using the fields in the Schedule area.

TipIf you aren’t integrated with Platform, schedule the process to run after the Delete Inactive Native Users process or the DRM process so that the purge process has the most recent set of deleted users.

3. In Purge deleted users' audit data after the specified number of days, type a number of days for a grace period between deletion and purge.

For example, if you type 10 in Purge deleted users' audit data after the specified number of days, then the process looks for user deletions that occurred eleven days or more in the past. Users who were deleted within the last ten days aren’t purged. Those ten days are a grace period. You might, for example, run a compliance report weekly and want to include recently deleted users. If your report runs against the PH tables, you still see the compliance data for the users.


3.8 Process for Purging Data with Data Retention Management

Purging data with Data Retention Management is a multistep process.

Here is an overview of the process:

1. Create purge request by defining data to be purged and specifying approvers.2. Submit purge request to occur immediately or at a future time.3. Notification is sent to specified approvers.4. Approval steps vary based on when the purge request is set to occur:

1. If the purge request was launched immediately, a preview report is generated immediately so that approvers can review it.

2. If the purge request was scheduled to occur at a future time, approvers first need to approve the request so that a preview report is generated at the scheduled time.

5. Notification is sent to specified approvers when the preview report is ready to review.6. Approvers review the purge preview report to confirm that the purge is set up correctly and executes

successfully.7. Approvers either approve or decline the purge request.8. The approved purge request is sent to the job queue:

1. If the purge request was launched immediately, it’s sent to the job queue as soon as it’s approved and the purge job runs at the next available time.

2. If the purge request was scheduled to occur at a future time, it's sent to the job queue at the time of recurrence and the purge job runs at the next available time after that.


9. The purge job runs.10. The purge job completes and the complete final report is generated.11. Review the complete final report to confirm whether the purge job was successful or not, for each type of data.

3.9 DRTM Purge Request Set-Up

Create and save a new DRTM purge request to begin the process of purging some type of data from your system based on its configured retention time.


The exact steps and configuration options of each DRTM purge request vary based on the type of data you want to purge and the users you want to include in the purge.

Purging Inactive Users with DRTM [page 160]Create a DRTM Master Data purge request so that you can purge inactive users and their associated data from the system.

Purging Specific Types of Data with DRTM [page 163]Create a DRTM purge request so that you can purge a specific type of data, based on its own specific retention time.

Purging Audit Data for Active and Inactive Users with DRTM [page 165]Create a DRTM Audit Data purge request so that you can purge audit data, for both active and inactive users.

Retrieving an Onboarding External User Report During a Data Purge [page 168]Generate or extract external user IDs based on PersonType while performing a data purge.

3.9.1 Purging Inactive Users with DRTM

Create a DRTM Master Data purge request so that you can purge inactive users and their associated data from the system.

Prerequisites

● You understand the scope and impact of a master data purge.

CautionThe master data purge has a broad impact across the suite, purging inactive users so that they no longer exist in the system, along with all data associated with those users, including audit data. Before you launch a master data purge, be sure that you review the available documentation to understand its full scope.


Data Purge

● You have set up data retention time management (DRTM).● You have configured retention times for the master data purge, for each country/region or legal entity you want

to include in the purge.● The status of target users has been set to inactive.● You have Create DRTM Data Purge Request permission.● You have Manage Users permission for the relevant target population.

NoteTo completely remove user accounts and basic user information from the system, the user who initiates the purge request needs to have Manage Users permission for the target population that is included in the purge set-up.

Context

Do this task when you want to purge entire users with all their records, not just a specific type of data. If you want to do a partial purge of specific data, use a modulespecific purge request instead.

Procedure

1. Go to Admin Center Tools Data Retention Management .2. Click Create New Purge Request.3. In the Select a purge request type menu, select DRTM Master Data Purge.

NoteIf you do not see any purge request types in the dropdown that begin with the abbreviation "DRTM", you may not have Create DRTM Data Purge Request permission. If you have this permission but do not see DRTM Master Data Purge, you may still need to add it to your instance using the Upgrade Center.

4. Use subject criteria to define the users whose data you want to purge.a. Choose from the available options.

○ Select one user. Use this option to purge data for an individual user. ○ Upload a user list (by User ID or Assignment ID). Use this option to purge data for multiple users, based

on your own criteria. Use the downloadable CSV example as a template.

NoteEnsure that the import file only has one column and that the column header matches the unique identifier field you use. By default, the column header is Assignment ID. You can use Assignment ID or User Id.

○ Ignore data retention time configuration for this purge request. When you purge data for an individual user, use this option to ignore data retention times and purge data immediately. This option enables you to quickly purge data that no longer has any business need, if you are required to do so.


○ Select countries. Use this option to purge data for multiple users in one or more countries. This option enables you to set up a recurring or reusable purge request for specified countries, according to your data retention policy.

○ Select legal entities. Use this option to purge data for multiple users in one or more legal entities in Employee Central. This option enables you to set up a recurring or reusable purge request for specified legal entities, according to your data retention policy.

NoteYou cannot select users by status because you cannot run a master data purge for active users. Only inactive users are included.

If you do not see the Select legal entities option, it may not be available in your system. Contact your administrator to have it enabled.

b. If needed, specify users by country/region or by legal entity. Select one or more using the dropdown menu.

NoteYou can only select countries or regions that have been set up to use data retention time management (DRTM). If you don't see the one you are looking for, contact your administrator to have it enabled.

5. If desired, deselect User belongs to an incomplete compensation or variable pay form to include inactive users in this purge, whether or not they belong to an incomplete compensation or variable pay form.

6. Add one or more approvers. Use the Add approvers search box to add the first approver. To add another, select Add another approver.

7. Click Save to save your purge rule.

TipAlways save your request before submitting. Proper set-up is validated on save and you cannot save your purge request if any information is missing or invalid.

Results

Your new purge request is saved and ready to submit for approval.

Next Steps

Submit your purge request to the designated approvers.

Related Information

Purge of Inactive Users and All Data [page 40]DRTM Master Data Purge [page 54]


Data Purge

Configuring Retention Times for the Master Data Purge [page 140]Setting User Status to InactiveUser Identifiers Included in the DRTM Master Data Purge [page 57]

3.9.2 Purging Specific Types of Data with DRTM

Create a DRTM purge request so that you can purge a specific type of data, based on its own specific retention time.

Prerequisites

● You have set up data retention time management (DRTM).● You understand important notes and limitations for the type of DRTM purge request you want to set up.● You have Create DRTM Data Purge Request permission.● You have configured retention times for the type of data you want to purge, for each country/region or legal

entity you want to include in the purge.● (Applicable for DRTM inactive candidate purge in Recruiting) If required, you can have your system configured

to send advance e-mail notifications to inactive candidates before their profiles are purged. To configure this setting, enable the Imminent Candidate Purge Notification e-mail trigger in Admin Center Recruiting Email Triggers , and associate it with the appropriate e-mail template.

Context

Do this task when you want to purge a specific type of data, not entire user accounts with all their records. If you want to do a full purge of inactive users, use the DRTM Master Data purge instead.

Procedure

1. Go to Admin Center Tools Data Retention Management .2. Click Create New Purge Request.3. In the Select a purge request type menu, select the option that corresponds with the data you want to purge

and begins with the prefix "DRTM".

NoteDo not select DRTM Master Data Purge. This option is only used for a full data purge.

Do not select DRTM Audit Data Purge. This option is set up in the same way as other partial purge types, but has different prerequisite steps.


https://help.sap.com/viewer/534356acc0ab4b0e8977ebfb2eb432f7/2111/en-US/7665667ee78c401695f317df5fc808c7.html

If you don’t see any purge request types in the dropdown that begin with "DRTM", you may not have Create DRTM Data Purge Request permission. If you have this permission but do not see the option you want, you may still need to add it to your instance using the Upgrade Center.

4. Use subject criteria to define the users whose data you want to purge.

Note(For Recruiting only) To purge inactive candidate profiles, you need to select DRTM Inactive Candidate Purge as the purge request type. Further, define countryspecific purge rules to configure the inactivity period, and if necessary, set up advance e-mail alerts to notify inactive candidates before their profiles are purged.

a. Choose from the available options.




○ Select user status and countries. Use this option to purge data for multiple users based their user status and country/region. This option enables you to set up a recurring or reusable purge request according to your data retention policy.

○ Select user status and legal entities. Use this option to purge data for multiple users based their user status and legal entity in Employee Central. This option enables you to set up a recurring or reusable purge request according to your data retention policy.

NoteSubject criteria options vary by purge type. If these settings aren't available for the purge request type you selected, proceed to the next step.


b. If needed, specify users by user status, country or region, or legal entity.

NoteIf the Active checkbox is disabled, you cannot purge active user data with the purge request type you selected. This type of data can only be purged for inactive users.

NoteYou can only select countries or regions that have been set up to use data retention time management (DRTM). If you don't see the one you're looking for, contact your administrator to have it enabled.

5. Select purge objects you want to include in the purge, if the option is available.

○ If purge objects are listed, select the checkbox for each purge object you want to include. Only data in the selected objects is purged.


Data Purge

○ If no purge objects are listed, the selected purge request type doesn’t allow you to select individual objects. Data in all purge objects associated with this purge type are purged.

○ Where available, select the MDF Custom Objects option to purge personal data captured in MDF custom objects associated with a given module or functional area.



TipAlways save your request before submitting. Proper set-up is validated on save and you can’t save your purge request if any information is missing or invalid.

Results


Next Steps


Related Information

Submitting a DRTM Purge Request for Approval [page 169]DRTM Purge Request Types [page 47]

3.9.3 Purging Audit Data for Active and Inactive Users with DRTM

Create a DRTM Audit Data purge request so that you can purge audit data, for both active and inactive users.

Prerequisites

● You have set up data retention time management (DRTM).● You have Create DRTM Data Purge Request permission.● You have confirmed that the retention times configured for audit data are longer than the period for which you

are required to produce audit reports for data protection and privacy.


● You have configured retention times for each type of audit data in your system.

Context

Only use this purge type to purge audit data after it is no longer required.


NoteThe DRTM Audit Data Purge does not include audit data about external candidates in SAP SuccessFactors Recruiting. It only includes internal candidates. To purge audit data about external candidates, use the DRTM Recruiting Read Access Log Purge instead.

Procedure

1. Go to Admin Center Tools Data Retention Management .2. Click Create New Purge Request.3. In the Select a purge request type menu, select DRTM Audit Data Purge.

NoteIf you do not see any purge request types in the dropdown that begin with the abbreviation "DRTM", you may not have Create DRTM Data Purge Request permission.

4. Use subject criteria to define the users whose data you want to purge.a. Choose from the available options.




○ Select countries. Use this option to purge data for multiple users in one or more countries. This option enables you to set up a recurring or reusable purge request for specified countries, according to your data retention policy.

○ Select legal entities. Use this option to purge data for multiple users in one or more legal entities in Employee Central. This option enables you to set up a recurring or reusable purge request for specified legal entities, according to your data retention policy.


Data Purge

NoteYou cannot select users by user status. The audit purge always includes audit data for both active and inactive users.


b. If needed, specify users by country/region or by legal entity. Select one or more using the dropdown menu.

NoteYou can only select countries or regions that have been set up to use data retention time management (DRTM). If you don't see the one you're looking for, contact your administrator to have it enabled.



TipAlways save your request before submitting. Proper set-up is validated on save and you cannot save your purge request if any information is missing or invalid.

Results


Next Steps


Related Information

Purge of Audit Data [page 44]DRTM Audit Data Purge [page 61]Configuring Retention Times for Audit Data [page 146]Purging Audit Data for Active and Inactive Users with DRTM [page 165]Audit Data Purge Objects [page 149]Submitting a DRTM Purge Request for Approval [page 169]DRTM Master Data Purge [page 54]User Identifiers Included in the DRTM Master Data Purge [page 57]


3.9.4 Retrieving an Onboarding External User Report During a Data Purge

Generate or extract external user IDs based on PersonType while performing a data purge.

Context

When the Onboarding process is cancelled for an external user, you must purge the external user's personal data. To purge external user data, upload a list of external user IDs in an inactive user purge.

To upload the .csv file to the inactive data purge, remove all information from the file except the user ID. The inactive user purge excludes any users not in an inactive status.

CautionUsers who have a legal holding must be excluded from a data purge, otherwise known as a purge freeze. It is important that these users are manually excluded from the inactive user file.

Procedure

1. Go to Admin Center Integration Center My Integrations and click Create to create a new integration such as a Scheduled Simple File Output Integration to retrieve a report through an SFTP transfer.

2. In Create New Scheduled CSV File Output Integration, type "PerPersonal" in the Search for Entities by Entity Name field, to access the Personal Information (Per Personal) entity.

3. Select the initial necessary personal information attributes to distinguish the user record in Data Preview such as First Name, Middle Name, Last Name, and Gender and then click Select.

NotePerson ID External and Start Date are enabled by default.

4. In Create New Scheduled CSV File Output Integration, under Options, provide the file name for your new integration, output file type, file delimiter, header type, and footer type.

5. Click Next to go to Configure Fields, where you can view your selected entities from Data Preview as columns in your CSV File Output Integration table.

6. In Configure Fields, click Add Add Field .7. To add personType in PersonTypeUsage column to the Personal Information (PerPersonal) table, perform the

following actions:


PersonTypeUsage by entering personType in PersonTypeUsage in the search field.c. Click Add Association "User ID".

8. To add User ID-Employee Details column to the Personal Information (PerPersonal) table, perform the following actions:


Data Purge


PersonTypeUsage by entering personType in PersonTypeUsage in the search field.c. In Entity Tree View, navigate to select personNav, employmentNav, and User ID.d. Click Add Association "User ID".

User ID is part of the employment data.

You now have some personal information associated with the User ID.9. Click Next.

10. In Filter & Sort Advanced Filters , add the condition on the personType-PersonTypeUsage field to be equal to the Onboardee value and click Next.

11. Click Save and select Download Preview to view the CSV File Export preview file.12. Click Next to advance to Destination Settings.13. In Destination Settings, provide details such as SFTP Server Host Address, SFTP User Name, SFTP Password,

File Name Prefix, and File Folder in the File Server Settings.14. Click Next to advance to Scheduling.

15. In Scheduling Scheduled Version Occurs , determine how often you generate the report, such as once, daily, weekly, monthly, or yearly.

You also have the Suspended/Not Scheduled option to stop generating the report.16. If you select Weekly, you can determine the day of the week, the Start Time, Ending on Date, and designate e-

mail recipients of the report in the Email To field.17. Click Save.18. Click Set Schedule.19. In Confirm, click Save and Continue.20.In Save Integration, provide the integration name and a brief description.21. Click Save.

3.10 Submitting a DRTM Purge Request for Approval

Set up the time you want the purge request to occur and submit it to designated approvers.

Prerequisites

● You have set up the purge request completely.● You have Create DRTM Data Purge Request permissions.

NoteTo submit a DRTM purge request, you do not need to be the creator of the request.


● You have configured retention times for the type of data you want to purge, for each country/region or legal entity you want to include in the purge.

Procedure

1. Open the Edit Purge Request page in edit mode:

○ If you have just set up a new purge request, you should already be on this page.

○ If you’re returning to a previously saved purge request, go to Admin Center Data Retention Management and choose the name of your saved request in the Saved Purge Requests table.

2. Review your purge request to confirm it’s set up correctly.3. Decide when you want the purge occur.

○ If you want to create a one-time purge request that begins as soon as it’s approved, choose Launch Immediately, then Yes to confirm. In this case, the preview report is generated immediately and the request only needs to be approved once.

○ If you want to create a scheduled purge request that recurs at a specified time, date, and frequency, choose Schedule, then use the scheduling dialog to set up the recurrence pattern. In this case, the purge request must be approved twice, once to generate a preview report and once to begin the actual purge process.

CautionUI issues in the scheduling dialog can cause some unintentional configuration errors. For example, the recurrence pattern is set in 24-hour time, while start and end dates use 12-hour time. Also, purge times are based on our server times, not your local time. Be careful when scheduling your purge request.

Results

● If you selected Launch Immediately, the preview report is generated immediately and is available for approvers to review in Purge Request Monitor Requests Pending Final Approval when the preview report is ready.

● If you selected Schedule, the purge request first appears in Purge Request Monitor Requests Pending Initial Approval at the scheduled time.

● For one-time purge requests, the purge creator and specified approvers receive an email notification when the preview report is ready and the purge request is pending final approval.

● For scheduled purge requests, the purge creator and specified approvers receive an email notification when the purge request is pending initial approval.

Next Steps

Purge requests can now be reviewed and approved by the specified approvers.


Data Purge

3.11 Generating Preview Report for a Scheduled Purge Request

Approve the criteria and schedule of a scheduled purge request so that a preview report can be generated.

Prerequisites

● You have either Manage and Approve DRTM Data Purge Request or Manage and Approve Legacy Data Purge Request permission.

● You’re designated as an approver of the purge request.

NoteAs an approver, you should have the permission to purge the target users of the scheduled purge request. Otherwise, users that you don't have the permission to purge are excluded from the purge job. If all users are out of your target population, an empty purge report is generated.

Context

Only scheduled purge requests require a separate step to generate a preview report. Scheduled purge requests show up in Purge Request Monitor Requests Pending Initial Approval at the scheduled time.

For immediate purge requests, you can skip this step. The preview report is generated immediately after it’s submitted and you only need to approve to start the purge process in Purge Request Monitor Requests Pending Final Approval .

NoteYou should only receive an email notification asking you to approve a purge request for which you’re identified as an approver. If you haven't received any email, you may not need to complete this step. However, you don’t need to have received an email in order to do it.

Procedure

1. Go to Admin Center Purge Request Monitor .2. Locate the purge request that needs approval in the Request Pending Initial Approval tab.3. Expand the Criteria section to review the purge request setup.4. Click View Schedule to review when the purge request is set to recur.5. Choose how you want to proceed with scheduled purge requests or decline this request.


Results

● If you agree to generate a preview report, the purge request shows up in the Request Pending Final Approval tab when the preview report is ready for review.

NoteIf there are multiple approvers, the preview report is only available when all approvers approve the requests. However, your decision on the approval options only determines your own approval workflow.

● If you decline the request, it goes to the Purge Progress & Results.● If one of the approvers chooses to review preview report for each occurrence, the creator and specified

approvers receive an email notification when preview report for each occurrence is ready and the purge request is pending final approval.

● If all approvers choose to approve the whole series, the creator and specified approvers receive an email notification when each occurrence is complete.

● Only future occurrences of a scheduled purge request are executed when the approval is granted after a scheduled time.

Next Steps

Specified approvers must approve the purge request to start the purge process.

3.12 Reviewing a Purge Preview Report

Review the purge preview report to verify the set-up of a purge request before you approve it.

Prerequisites


● Additional access control based on DRTM-enabled countries or regions and countries/regions selected.

NoteThis permission is only required when you have enabled Additional access control based on DRTM-enabled countries or regions in Admin Center Company System and Logo Settings Data Retention Management .


Data Purge

Procedure

1. Go to Admin Center Purge Request Monitor .2. Locate the purge request you want to review in the Requests Pending Final Approval tab.3. Expand the Criteria section to confirm the purge set-up is correct.4. Download and review the preview report in a ZIP file.

Results

The preview purge report archive may contain multiple CSV files. One of the files lists the selection results—that is, the users that meet the selection criteria. The other files show a preview of purge results and each one corresponds to a different data source. In the preview purge results files, records that will be purged are marked with a process status of "TO BE PURGED".

If a user satisfies the selection criteria but doesn’t have the relevant data to be purged, the user is listed in the CSV file for selection results but not listed in the CSV file for the preview purge results. If none of the selected users have relevant data to be purged, no CSV files for preview purge results are generated.

NoteAs a Compensation Administrator, you can either purge the complete worksheet or move the existing employees in the worksheet before approving the purge request with the DRTM Master Data purge. In addition, the system automatically deletes the purged user data in the Snapshot of Compensation worksheets.

Next Steps

Specified approvers must approve the request to start the purge process.

3.13 Approving or Declining a Purge Request

As a designated approver, approve or decline a purge request before data can be purged from the system.

Prerequisites


● You are designated as an approver of the purge request.● You have reviewed the purge preview report.


Context

NoteYou should only receive an email notification asking you to approve a purge request for which you’re identified as an approver. If you haven't received any email, you may not need to complete this step. However, you don’t need to have received an email in order to do it.

Procedure

1. Use the link in your email notification, or log in and go to Admin Center Purge Request Monitor .2. Locate the purge request that needs approval in the Requests Pending Final Approval.3. Approve or decline the request.

Results

● After a purge request is approved by all designated approvers, the purge process can proceed.● The creator and specified approvers receive an email notification when the purge is complete.● Immediate purge requests are submitted to the job scheduler immediately after approval and the purge job

begins at the next available time.● Scheduled purge requests are submitted to the job scheduler at the configured recurrence time and the purge

job begins at the next available time.● Only future occurrences of a scheduled purge request are executed when the approval is granted after a

scheduled time.

3.14 Verifying Final Purge Results

Review a complete final purge report to verify that data was purged successfully.

Prerequisites

You have permission to create or approve purge requests.


Data Purge

Procedure

1. Go to Admin Center Purge Request Monitor .2. Locate the purge request in the Purge Progress & Results tab and choose View Result.3. View the number of successful, filtered, and failed records affected by the purge.4. Download the complete report in a ZIP file.5. Open the downloaded archive and review its contents.

Results

RememberUnlike other purge processes, targeted audit data may still be available in the system when the purge request is shown as completed in Purge Request Monitor. This is because we run purge jobs for audit data collectively on weekends. When you complete a DRTM Aduit Data or DRTM Master Data Purge on a weekday, you should validate the purge result of audit data next week.

The complete final purge report archive may contain multiple CSV files. One of the files lists the selection results—that is, the users that meet the selection criteria. The other files show the actual purge results and each one corresponds to a different data source. In these purge results files, records that are successfully purged are marked with a process status of "PURGED".

If a user satisfies the selection criteria but doesn’t have the relevant data to be purged, the user is listed in the CSV file for selection results but not listed in the CSV file for the actual purge results. If none of the selected users have relevant data to be purged, no CSV files for purge results are generated.

3.15 Data Purge in Employee Central Integration with Other Systems Holding Employee Data

Understand how data purge in Employee Central affects integration with other systems.

If data is purged in Employee Central that is needed for replication to other systems, integration must react to this. That is, Employee Central's Compound Employee API, the standard integrations we provide for SAP ERP HCM, SAP S/4HANA, Employee Central Payroll, and the Employee Central Data Replication Monitor used in these integrations must consider data purge.

RememberConsider the full transmission start date (FTSD) defined for data replication to other systems when configuring retention times for employee data in Employee Central: The FTSD should be after the latest retention date of any SAP SuccessFactors entity that is contained in data replication. In other words, no integration-relevant data should be purged after the FTSD. Otherwise, data can no longer be replicated for the employee in question. And if the employee's data was completely purged, this employee can never be replicated again – even if they are rehired later.


Custom integrations (for example, a copied standard integration process) do not consider purge by default. You must enable the effective end date filter validation in Compound Employee API for your integration if you want to consider purge situations.

How the CompoundEmployee API Reacts to Data Purge [page 176]The CompoundEmployee API provides some optional data purge checks, which can be enabled by the consumers.

How the CompoundEmployee API Delta Transmission Mode Reacts to Data Purge [page 194]Data Retention Management allows purging of transactional data and audit data independently, with different retention periods. That's why the CompoundEmployee API must be able to handle situations where transactional data was purged and audit data is still there.

How the Employee Central Data Replication Monitor Reacts to Data Purge [page 196]If master data or inactive users are purged using Data Retention Management, the related data replication records are also purged in the Employee Central Data Replication Monitor.

Purge of Employee Central Data Replicated to ERP Systems [page 198]If you have a data integration between your Employee Central and Enterprise Resource Planning (ERP) systems, look at how data purge in Employee Central and ERP interact and how to purge data in your ERP system.

Purge of Employee Central Data Replicated to Employee Central Payroll [page 209]Since you have data integration between Employee Central and Employee Central Payroll in place, take a look at how data purge in Employee Central and Employee Central Payroll interact and how to purge data in your Employee Central Payroll system.

Related Information


3.15.1 How the CompoundEmployee API Reacts to Data Purge

The CompoundEmployee API provides some optional data purge checks, which can be enabled by the consumers.

Master data purge and partial purge of personal data have an impact on the result of the CompoundEmployee API since the API returns less data than before.

For example, if an employee's master data is completely purged, the API no longer returns any data for this employee. If the data is partially purged – for example, if an entity such as address information is purged – the API doesn't return any information about the purged records. Even a last modified query doesn't detect purged employees or partially purged entities since no audit records are created for the purged records.

CautionWhen using the validations provided by the CompoundEmployee API, make sure that you configure your systems, especially retention times, according to the requirements of the integrations you’re running. Otherwise, there’s a high risk that after data was purged in Employee Central, integrations no longer work and employees can only be replicated again when you adjust the integration.


Data Purge

For example, integrations that use an effective end date filter don't replicate employee data of employees for which the date of the effective end date filter is in the purge period of any of the requested entities. For such employees, the data replication shows an error.

To resolve such issues, the effective end date filter of the affected integration must be adjusted, or the validation must be disabled altogether. Therefore, make sure that you define retention times of purge objects in close alignment with the effective end date filters used in your integrations. When you use the validation, terminated employees aren't replicated anymore, as soon as any personal data-related entity such as the email or address is purged. Such employees are always replicated with an error, even if they’re rehired.

Data Purge Handling [page 177]In full transmission mode, the CompoundEmployee API provides additional information to help the downstream systems interpret data that's no longer available due to purge and to prevent unintended data loss at consumer side.

Data Purge Handling in Snapshot Mode [page 193]Data Retention Management allows purging of transactional data and audit data independently, with different retention periods. For that reason, the CompoundEmployee API must be able to handle situations where transactional data was purged and audit data is still there.

Parent topic: Data Purge in Employee Central Integration with Other Systems Holding Employee Data [page 175]

Related Information

How the CompoundEmployee API Delta Transmission Mode Reacts to Data Purge [page 194]How the Employee Central Data Replication Monitor Reacts to Data Purge [page 196]Purge of Employee Central Data Replicated to ERP Systems [page 198]Purge of Employee Central Data Replicated to Employee Central Payroll [page 209]

3.15.1.1 Data Purge Handling

In full transmission mode, the CompoundEmployee API provides additional information to help the downstream systems interpret data that's no longer available due to purge and to prevent unintended data loss at consumer side.

Whether the CompoundEmployee API provides additional information about data purge is an optional setting. The consumers must enable it. They have the following options:

● Consumers can request a purge status overview with detailed purge information, using the DRTMPurgeStatusOverview segment.

● Consumers can validate agains the effective end date filter using the purgeOptions parameter with validateEffectiveEndDateFilter.

CautionUse either one approach or the other. We recommend that you use DRTMPurgeStatusOverview.


Purge Status Overview [page 178]Use the DRTMPurgeStatusOverview segment of the CompoundEmployee API if the API is to return detailed information about data purge.

Effective End Date Filter [page 184]Use the purgeOptions query parameter of the Compound Employee API if the API is to check whether the effective end date filter (which is also known as Full Transmission Start Date (FTSD) in the standard integrations) is in a period for which data was purged.

3.15.1.1.1 Purge Status Overview

Use the DRTMPurgeStatusOverview segment of the CompoundEmployee API if the API is to return detailed information about data purge.

Consumers can expose the purge information stored in the DRTMPurgeStatus MDF object in the response of the CompoundEmployee API. The API returns the purge information from the DRTMPurgeStatus object in the DRTMPurgeStatusOverview segment.

Enabling Purge Status Overview [page 178]Enable the CompoundEmployee API to request information about the purge status, so that the consumer can react on data purge.

Structure of the Purge Status Overview Segment [page 179]What the DRTMPurgeStatusOverview segment of the CompoundEmployee API looks like.

Example: Query Response When Requesting Purge Status Overview [page 180]What the response returned by CompoundEmployee API looks like if purge status overview is requested.

Entities Supporting Purge Status Overview [page 182]Purge status overview information is supported for some segments of the CompoundEmployee API, but not for all of them.

3.15.1.1.1.1 Enabling Purge Status Overview

Enable the CompoundEmployee API to request information about the purge status, so that the consumer can react on data purge.

Procedure

Add the DRTMPurgeStatusOverview segment to the SELECT clause of the query request.


Data Purge

3.15.1.1.1.2 Structure of the Purge Status Overview Segment

What the DRTMPurgeStatusOverview segment of the CompoundEmployee API looks like.

The CompoundEmployee API response adds the DRTMPurgeStatusOverview segment at the end of the person segment. The DRTMPurgeStatusOverview segment includes all existing DRTMPurgeStatus subsegments in descending order of the fields node_name and person_id or user_id.

The key fields of the DRTMPurgeStatus subsegment are:

● node_name● Either user_id or person_id, depending on whether the data was purged for an employment-related object

(user_id) or a person-related object (person_id)

Altogether, the DRTMPurgeStatus subsegment has the following fields:

● nodeNameContains the name of the CompoundEmployee API segment to which the purge status object belongs.

● highestBusinessPurgeDateIs filled when an effectivedated object is partially purged for an active employee. It contains the date of the purge execution, minus the retention time. The exact time information is cut off.highestBusinessPurgeDate marks the start of the retention period. All time slices that end before this date is purged.

ExampleLet's say, data is purged on October 17, 2018 at 08:00:00 00 local time (for example, CET). The retention period is one month. Then highestBusinessPurgeDate is September 17, 2018 in the CompoundEmployee API response. This means, all time slices that end on September 16, 2018 or earlier are purged.

● highestAuditPurgeDateTimeIs filled when audit data is purged. It contains the date and time until which the audit data for the affected segment was purged, in local time. CompoundEmployee API converts the date and time to a UTC time stamp. This matches the exact date and time in UTC when audit data is available again.

ExampleLet's say, audit data is purged on October 17, 2018 at 08:00:00 00 local time (for example, CET). The retention period for audit data is one month. Then all audit time slices with a last_modified_on date of September 17, 2018 00:00:00 local time or earlier are purged. CompoundEmployee API transforms the date and time into the UTC time stamp 2018-09-16T23:00:00Z.

● completePurgeDateTimeIs filled when data is partially purged for a terminated employment and the termination date is outside the configured retention period of the affected segment for inactive employees. It contains the date and exact local time (for example, CET) when the data was purged. CompoundEmployee API converts the date and time to a UTC time stamp.If a complete master data purge was carried out for an employment, CompoundEmployee API only returns data for the respective employee if another employment exists that hasn't been fully purged. The purge removes the terminated employment from the database, including all subsegments. But CompoundEmployee API exposes only the complete purge of the employment to the consumer, by rendering a


DRTMPurgeStatusOverview segment for the employment information that includes the completePurgeDateTime field.Consumers can compare the timestamps of completePurgeDateTime and rehiredAtDateTime to identify if the segment needs to be treated currently as purged or active

● rehiredAtDateTimeIs filled when an employee is rehired. Rehiring into an existing employment adds the rehiredAtDateTime for all previously existing employment-related DRTMPurgeStatus objects. Rehiring into new employment adds only the rehiredAtDateTime to all previously existing person-related DRTMPurgeStatus objects. It contains the date and exact local time (for example, CET) of the specified rehiring, and not the effective start date of the rehiring. Note that rehiredAtDateTime is only written if the rehiring was performed once Employee Central has been updated to release b2011. CompoundEmployee API converts the date and time to a UTC time stamp.Consumers can compare the time stamps of completePurgeDateTime and rehiredAtDateTime to detect which segment needs to be processed as purged or active.

3.15.1.1.1.3 Example: Query Response When Requesting Purge Status Overview

What the response returned by CompoundEmployee API looks like if purge status overview is requested.

Sample Code

<result> <sfobject> <id>1501</id> <type>CompoundEmployee</type> <person> <person_id>1501</person_id> <person_id_external>sgdpr</person_id_external> ... <DRTMPurgeStatusOverview> <DRTMPurgeStatus> <node_name>address_information</node_name> <person_id>1501</person_id> <highestBusinessPurgeDate>2014-12-31</highestBusinessPurgeDate> <highestAuditPurgeDateTime>2016-12-30T23:00:00.000Z</highestAuditPurgeDateTime> <completePurgeDateTime>2012-06-15T11:52:32.000Z</completePurgeDateTime> <rehiredAtDateTime>2013-02-08T08:41:21.000Z</rehiredAtDateTime> </DRTMPurgeStatus> <DRTMPurgeStatus> <node_name>compensation_information</node_name> <user_id>sgdpr</user_id> <highestBusinessPurgeDate>2014-12-31</highestBusinessPurgeDate> <completePurgeDateTime>2012-06-15T11:52:32.000Z</completePurgeDateTime> <rehiredAtDateTime>2013-02-08T08:41:21.000Z</rehiredAtDateTime> </DRTMPurgeStatus> <DRTMPurgeStatus> <node_name>dependent_address_information</node_name> <person_id>1502</person_id> <highestBusinessPurgeDate>2013-12-31</highestBusinessPurgeDate>


Data Purge

<completePurgeDateTime>2017-11-30T23:00:00.000Z</completePurgeDateTime> </DRTMPurgeStatus> <DRTMPurgeStatus> <node_name>dependent_personal_information</node_name> <person_id>1502</person_id> <highestBusinessPurgeDate>2013-12-31</highestBusinessPurgeDate> </DRTMPurgeStatus> <DRTMPurgeStatus> <node_name>email_information</node_name> <person_id>1501</person_id> <highestAuditPurgeDate>2016-12-30T23:00:00.000Z</highestAuditPurgeDate> <completePurgeDateTime>2012-06-15T11:52:32.000Z</completePurgeDateTime> <rehiredAtDateTime>2013-02-08T08:41:21.000Z</rehiredAtDateTime> </DRTMPurgeStatus> <DRTMPurgeStatus> <node_name>person_relation</node_name> <person_id>1501</person_id> <highestBusinessPurgeDate>2017-07-31</highestBusinessPurgeDate> </DRTMPurgeStatus> <DRTMPurgeStatus> <node_name>personal_information</node_name> <person_id>1501</person_id> <highestBusinessPurgeDate>2013-12-31</highestBusinessPurgeDate> <completePurgeDateTime>2012-06-15T11:52:32.000Z</completePurgeDateTime> <rehiredAtDateTime>2013-02-08T08:41:21.000Z</rehiredAtDateTime> </DRTMPurgeStatus> <DRTMPurgeStatus> <node_name>phone_information</node_name> <person_id>1501</person_id> <highestAuditPurgeDateTime>2016-12-30T23:00:00.000Z</highestAuditPurgeDateTime> </DRTMPurgeStatus> </DRTMPurgeStatusOverview> </person> <execution_timestamp>2018-10-08T12:10:44.000Z</execution_timestamp> <version_id>1811P0</version_id> </sfobject> <numResults>1</numResults> <hasMore>false</hasMore> <querySessionId>8dd7c505-8264-423d-a86b-a2ad2fbf20ea</querySessionId> </result>


3.15.1.1.1.4 Entities Supporting Purge Status Overview

Purge status overview information is supported for some segments of the CompoundEmployee API, but not for all of them.

Entities Supporting Purge Status Overview

Segment or Subsegment More Info

person

personal_information

address_information

email_information

phone_information

person_relation If data is purged for an employee's dependents, the API returns the purge status for the dependent_information and person_relation segments. This implies that the data of the dependent as well as the relation between the employee and the dependent have been purged. The node_name value differs for the dependent_information and person_relation segments, but the other fields are identical.

employment_information Can only be purged if the employment is terminated and a master data purge is executed.

compensation_information

paycompensation_recurring This subsegment can only be purged with the compensation_information segment. That's why it’s communicated only with this segment

paycompensation_non_recurring

payment_information

job_relation

deduction_recurring

deduction_non_recurring

ItDeclaration

associated_employee_employment_information For associated employees, the API returns information about a master data purge only. That is, the associated_employee_employment_information child segment of the associated_employee_information segment is returned.

national_id_card


Data Purge

Segment or Subsegment More Info

dependent_information If data is purged for an employee's dependents, the API returns the purge status for the dependent_information and person_relation segments. This implies that the data of the dependent as well as the relation between the employee and the dependent have been purged. The node_name value differs for the dependent_information and person_relation segments, but the other fields are identical.

dependent_personal_information For dependents who are also employees, the API returns information about a purge of their personal information.

dependent_address_information For dependents who are also employees, the API returns information about a purge of their address information.

dependent_national_id_card_information For dependents who are also employees, the API returns information about a purge of their national ID information.

emergency_contact_primary

BenefitsIntegrationOneTimeInfo

BenefitsIntegrationRecurringInfo

PriorService

Any custom MDF object, which is added to CompoundEmployee API and can be purged with an Employee Central Employment Information purge

If data is purged for custom entities, the node_name field shows the name of the custom object or custom object segment.

Segments Not Supporting Purge Status Overview

For the following segments, no purge information is available because the underlying data can't be purged or because they’re technical segments.

Segment or subsegment

global_assignment_information

job_information

alternative_cost_distribution

accompanying_dependent

direct_deposit

personal_documents_information

EmployeeDataReplicationElement

DRTMPurgeStatusOverview

EmpCostAssignment

HDTempAssignment


Segment or subsegment

Any custom MDF object, which is added to CompoundEmployee API, but can’t be purged

3.15.1.1.2 Effective End Date Filter

Use the purgeOptions query parameter of the Compound Employee API if the API is to check whether the effective end date filter (which is also known as Full Transmission Start Date (FTSD) in the standard integrations) is in a period for which data was purged.

Enabling Validation Against Effective End Date Filter [page 184]Enable validation against the effective end date filter in the query request of the CompoundEmployee API, so that the consumer can react on data purge.

How the Effective End Date Filter Works [page 186]The CompoundEmployee API goes through these steps if validation against the effective end date filter is requested in the query.

Example: Query Response When Using Effective End Date Filter [page 187]What the response returned by CompoundEmployee API looks like if validation against the effective end date filter is enabled.

Entities Supporting Effective End Date Filter [page 188]The CompoundEmployee API applies validation against the effective end date filter to all entities that support partial purge.

Partial Purge of Inactive Employees [page 190]For terminated employees, partial purge will purge the complete data of an entity as soon as the termination date is outside of the retention period of the entity. If the data of an entity is purged completely, the standard effective end date validation doesn't work.

What Else Is Good to Know About the Effective End Date Filter [page 192]Additional things conumers of the CompoundEmployee API should know when validating against the effective end date filter.

3.15.1.1.2.1 Enabling Validation Against Effective End Date Filter

Enable validation against the effective end date filter in the query request of the CompoundEmployee API, so that the consumer can react on data purge.

Context

Validating against the effective end date filter is useful because the CompoundEmployee API just returns the data that is available in the system for the requested entities. This means that after a partial purge, only the remaining data is returned. The consumer might be provided with less data than before. It’s the responsibility of the consumer to handle this situation correctly.


Data Purge

Procedure

1. Ensure that the effective_end_date filter parameter is provided in the query string.

Otherwise, the CompoundEmployee API ignores the value of the purgeOptions parameter and doesn't carry out the validation.

2. Enable the validation using the purgeOptions query parameter as shown in this example:

Code Syntax

<urn:query> <urn:queryString> SELECT person, personal_information, address_information, … FROM CompoundEmployee WHERE last_modified_on > to_DateTime('2017-08-01T00:00:00Z') AND effective_end_date >= to_date('2016-01-01') </urn:queryString> <urn:param> <urn:name>purgeOptions</urn:name> <urn:value>validateEffectiveEndDateFilter</urn:value> </urn:param> </urn:query>

Example

The following example shows employees with different retention periods and different time slices. The highest purge date is the day before the begin of the retention period.


Example: Impact of Effective End Date Filter

Without the validation, the CompoundEmployee API returns all active time slices that are valid on the effective end date filter and beyond. The consumer doesn't get any information about the purged time slices.

Using the validation, the CompoundEmployee API returns the same result as without the validation for employees 1 and 4. For employees 2 and 3, however, the API returns an error, since the effective end date filter hits a purge period for at least one of the requested entities. For employee 2, for example, the effective end date filter hits the purge period of the address information. For employee 3, it's the purge period of the spot bonus.

3.15.1.1.2.2 How the Effective End Date Filter Works

The CompoundEmployee API goes through these steps if validation against the effective end date filter is requested in the query.

Validation against the effective end date filter in the CompoundEmployee API is available for all entities that support partial purge. The steps of the validation are:

1. For each employee and entity, the API determines the highest purge date from the Purge Status MDF object. The highest purge date indicates the date from which on complete data is available for the entity. If no purge date is stored for the employee and entity, the API considers the entity as not being purged and returns the complete data.

2. If a highest purge date exists, the API checks, whether the date is before the effective end date filter.


Data Purge

3. If the highest purge date is before the effective end date filter, the API returns the data of the entity as it is, without an error.

4. If the highest purge date is on or after the effective end date filter, the API proceeds as follows:○ For noneffectivedated entities, the API returns an error for the employee.○ For effectivedated entities, the API checks whether a record exists that is valid at the effective end date

filter. If no such record exists, the API returns an error for the employee. Otherwise, it returns the data of the entity without error.

3.15.1.1.2.3 Example: Query Response When Using Effective End Date Filter

What the response returned by CompoundEmployee API looks like if validation against the effective end date filter is enabled.

The following example shows the response of the CompoundEmployee API for a query with parameter purgeOptions = validateEffectiveEndDateFilter and effective_end_date >= to_date('2016-12-01') and two selected employees.

For the first employee, the address information was purged on January 1, 2017 (with the highest purge date December 31, 2016) and no valid record exists on the data of the effective end date filter, December 1, 2016. That's why the query returns an error for this employee.

The second employee is returned completely since a valid record exists at the date of the effective end date filter.

Sample Code

<result> <sfobject> <id>4711</id> <type>CompoundEmployee</type> <log> <log_item> <person_id>4711</person_id> <person_id_external>cgrant</person_id_external> <code>COMPOUND_EMPLOYEE/EMPLOYEE_ERROR</code> <severity>ERROR</severity> <message_text>Data for user id cgrant can't be returned: Please see log items for more information.</message_text> </log_item> <log_item> <person_id>4711</person_id> <person_id_external>cgrant</person_id_external> <code>COMPOUND_EMPLOYEE/EFFECTIVE_END_DATE_FILTER_IN_PURGE_PERIOD</code> <severity>ERROR</severity> <message_text>The effective end date filter is outside of the retention period of address_information that starts on 2017-01-01. Please use an effective end date filter greater than or equal to 2017-01-01. </message_text> </log_item> </log> <execution_timestamp>2017-08-06T10:00:00.000Z</execution_timestamp> <version_id>1711P0</version_id> </sfobject> <sfobject> <id>240</id> <type>CompoundEmployee</type>


<person> <person_id>240</person_id> <person_id_external>3</person_id_external> … <address_information> <start_date>2013-03-01</start_date> <end_date>9999-12-31</end_date> <address1>10 Main Street </address1> <city>San Francisco</city> … </address_information> </person> <execution_timestamp>2017-08-06T10:00:00.000Z</execution_timestamp> <version_id>1711P0</version_id> </sfobject> <numResults>2</numResults> <hasMore>false</hasMore> <querySessionId>37c6b290-c569-4d2d-8ce7-9aa4281336b2</querySessionId> </result>

3.15.1.1.2.4 Entities Supporting Effective End Date Filter

The CompoundEmployee API applies validation against the effective end date filter to all entities that support partial purge.

Entities Supporting Effective End Date Filter

The following entities support the effective end date filter:

Entity Effective-DatedBase Date Used by Entity

Entity Affects Only Inactive Employees

Entity Supports Complete Purge

personal_information Yes end_date No No

address_information Yes end_date No Yes

email_information No No Yes Yes

phone_information No No Yes Yes

person_relation Yes end_date No Yes

compensation_information

Yes end_date No Yes

alternative_cost_distribution

Yes effectiveEndDate No Yes


Data Purge

Entity Effective-DatedBase Date Used by Entity

Entity Affects Only Inactive Employees

Entity Supports Complete Purge


No pay_date No Yes

job_relation Yes end_date No Yes

deduction_recurring Yes effectiveEndDate No Yes

deduction_non_recurring

No deductionDate No Yes

ItDeclaration Yes effectiveEndDate No Yes

PaymentInformationV3 Yes effectiveEndDate No Yes

national_id_card No No Yes Yes

emergency_contact_primary

No No Yes Yes

The validation is also applied to global assignments and concurrent employment data that are purged in master data purge:

Global Assignment and Concurrent Employment Entities Supporting Effective End Date Filter

Entity Used Base Date

employment_information end_date

associated_employee_employment_information end_date

CompoundEmployee API Entities and Corresponding Purge Objects

The following table shows the relation of CompoundEmployee API entity and purge object, which is defined in Data Retention Management:

EntityEntity Belongs to Data Retention Group Entity Uses Purge Object Entity Uses Subject ID

personal_information Person Information DRTM_PERSONAL_DETAILS person_id

address_information Person Information DRTM_ADDRESS person_id

email_information Person Information DRTM_EMAIL person_id

phone_information Person Information DRTM_PHONE person_id


EntityEntity Belongs to Data Retention Group Entity Uses Purge Object Entity Uses Subject ID

person_relation Person Information DRTM_DEPENDENTS person_id

compensation_information Employment DRTM_COMPENSATION user_id

alternative_cost_distribution Employment DRTM_COST_DISTRIBUTION user_id


Employment DRTM_NON_RECURRING_PAY

user_id

job_relation Employment DRTM_JOB_RELATIONSHIPS user_id

deduction_recurring Employment DRTM_DEDUCTION user_id

deduction_non_recurring Employment DRTM_DEDUCTION user_id

ItDeclaration Employment DRTM_INCOME_TAX_DECLARATION

user_id

PaymentInformationV3 Employment DRTM_PAYMENT_INFORMATION

user_id

national_id_card Person Information DRTM_NATIONAL_ID_CARD person_id

emergency_contact_primary Person Information DRTM_EMERGENCY_CONTACT_INFO

person_id

The validation is also applied to custom MDF objects that support partial purge and that are configured according to Legislatively Sensitive Data Configuration. In this case, the MDF object name will be used as purge object.

3.15.1.1.2.5 Partial Purge of Inactive Employees

For terminated employees, partial purge will purge the complete data of an entity as soon as the termination date is outside of the retention period of the entity. If the data of an entity is purged completely, the standard effective end date validation doesn't work.

That's why a different handling is required here:

● The CompoundEmployee API introduces a new error code that indicates complete purge of an entity.● The API returns an error with this code for all employees for which at least one person-related entity, such as

email or address information, was completely purged.● The API ignores all employments of an employee for which at least one employment-related entity, such as

compensation information, was completely purged. If all of the employee's employments are affected by complete purge, the API returns an error for this employee with the new error code.

The new error code enables consumers to detect employees with completely purged entities and to react accordingly.


Data Purge

ExampleThe standard integration we provide for replicating employee master data from Employee Central to ERP systems ignores such employees and treats them as successfully replicated.

The complete purge is supported by almost all purgeable entities. It is applied to noneffective dated entities, such as email or phone, as well as to effectivedated entities, such as address information or compensation information. Only personal information is excluded from this handling, since at least the name of the employee should be kept for identification.

The following example shows the purge of address information and email of an inactive employee whose termination date was mid of 2013. Since the retention period of both entities is one year, they were purged completely with the purge run executed in 2015. Personal information is not purged since this entity is excluded from complete purge. The termination date of the employment (dotted line) is now outside of the retention period of email, personal, and address information. Email and address information are purged, whereas personal information remains.

Example: Partial Purge Deleting Address Information and Email

In this example, the CompoundEmployee API will return the following response message:

Sample Code

<result> <sfobject> <id>4711</id> <type>CompoundEmployee</type> <log> <log_item> <person_id>4711</person_id> <person_id_external>Steve</person_id_external> <code>COMPOUND_EMPLOYEE/EMPLOYEE_ERROR</code> <severity>ERROR</severity> <message_text>


Data for user id Steve can't be returned: Please see log items for more information. </message_text> </log_item> <log_item> <person_id>4711</person_id> <person_id_external>Steve</person_id_external> <code>COMPOUND_EMPLOYEE/COMPLETE_ENTITY_PURGE</code> <severity>ERROR</severity> <message_text> The data of entity address_information was purged completely on 2015-01-01T14:00:00Z. </message_text> </log_item> </log> <execution_timestamp>2017-08-06T10:00:00.000Z</execution_timestamp> <version_id>1711P0</version_id> </sfobject> <sfobject> <id>240</id> <type>CompoundEmployee</type> <person> <person_id>240</person_id> <person_id_external>3</person_id_external> … <address_information> <start_date>2013-03-01</start_date> <end_date>9999-12-31</end_date> <address1>10 Main Street </address1> <city>San Francisco</city> … </address_information> </person> <execution_timestamp>2017-08-06T10:00:00.000Z</execution_timestamp> <version_id>1711P0</version_id> </sfobject> <numResults>2</numResults> <hasMore>false</hasMore> <querySessionId>37c6b290-c569-4d2d-8ce7-9aa4281336b2</querySessionId> </result>

3.15.1.1.2.6 What Else Is Good to Know About the Effective End Date Filter

Additional things conumers of the CompoundEmployee API should know when validating against the effective end date filter.

● The API returns the error message for the first processed entity that does not fulfill the validation. If the consumer adapts the effective end date filter to the value proposed in the error message, the same error might be raised for the next entity which does not fulfill the validation.

● The effective end date filter validation is applied to all entities that support partial purge. Whenever the effective end date filter hits a purge period of one of these entities, the employee will be returned as erroneous.

● The effective end date filter validation is also applied to related persons or related employees, such as dependents or associated employees. That's why an employee is also returned as erroneous if the effective end date filter hits the purge period of the address information of one of its dependents, for example.

● Since audit data is purged independently of transactional data, the last modified query might return employees that don’t contain changes in the transactional data, but are selected because of the data in the audit tables.


Data Purge

This can happen in special situations, for example, when old data was changed shortly before being purged. When the last modified date query is executed after the purge, the CompoundEmployee API detects the change of the old data in the audit table and returns the employee in the response.

● The CompoundEmployee API aborts processing if maxRows is equal or greater than 200 and all of the selected employees of the first query page have a purge error with code EFFECTIVE_END_DATE_FILTER_IN_PURGE_PERIOD and severity ERROR. This restriction prevents situations where after a partial purge thousands of erroneous employees are replicated due to an inappropriate effective end date filter. In such a case, the CompoundEmployee returns the following response:

Code Syntax

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:Fault xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/" … > <faultcode>ns2:Server</faultcode> <faultstring>SFAPI Domain Error!</faultstring> <detail> <ns2:SFWebServiceFault xmlns="urn:sfobject.sfapi.successfactors.com" … > <ns2:errorCode>INVALID_SFQL</ns2:errorCode> <ns2:errorMessage> Invalid SFQL! Error: The effective end date filter is outside of the retention period for most of the selected employees. Please use an effective end date filter greater than or equal to 2015-12-31. </ns2:errorMessage> </ns2:SFWebServiceFault> </detail> </ns2:Fault> </S:Body> </S:Envelope>

3.15.1.2 Data Purge Handling in Snapshot Mode

Data Retention Management allows purging of transactional data and audit data independently, with different retention periods. For that reason, the CompoundEmployee API must be able to handle situations where transactional data was purged and audit data is still there.

In snapshot mode, the CompoundEmployee API determines the retention times of transactional data for each employee and entity. All records of the snapshot image that are outside of the respective retention period of the underlying entity will be ignored. Snapshot is only calculated for the records that are valid in the retention period. For the period in which data was purged and for the following day, no snapshot is calculated.

The API also checks for each entity whether the provided snapshot_date is within the audit retention time of the entity. If this is not the case for one or more entities, the CompoundEmployee API returns an error for the employee, indicating that the provided date is not allowed.

Example

Sample Code

<log> <log_item> <person_id>4711</person_id>


<person_id_external>Steve</person_id_external> <code>COMPOUND_EMPLOYEE/EMPLOYEE_ERROR</code> <severity>ERROR</severity> <message_text> Data for user id Steve can't be returned: Please see log items for more information. </message_text> </log_item> <log_item> <person_id>4711</person_id> <person_id_external>Steve</person_id_external> <code>COMPOUND_EMPLOYEE/SNAPSHOT_DATE_IN_AUDIT_PURGE_PERIOD</code> <severity>ERROR</severity> <message_text> The provided snapshot_date is outside of the audit retention period of entity "phone_information" that starts on 2016-12-30T23:00:00.000Z. Please use a snapshot_date later than 2016-12-30T23:00:00.000Z. </message_text> </log_item> </log>

The audit retention time of phone information is configured to 6 months. The audit purge was executed for this employee on June 30, and the audit records of all phone information changes prior to December 30 were deleted. The CompoundEmployee API will not provide a snapshot for this employee that has a snapshot_date before December 30.

3.15.2 How the CompoundEmployee API Delta Transmission Mode Reacts to Data Purge

Data Retention Management allows purging of transactional data and audit data independently, with different retention periods. That's why the CompoundEmployee API must be able to handle situations where transactional data was purged and audit data is still there.

In the delta transmission mode, the CompoundEmployee API determines the retention times of transactional data for each employee and entity. All records that are outside of the respective retention period of the underlying entity are ignored. Delta is only calculated for the records that are valid in the retention period. For the period in which data was purged and for the following day, no delta is calculated.

This means that the following changes aren't exposed by delta calculation:

● New records that are valid outside of the retention period● Changed or deleted records that were re-created after purge and are valid outside of the retention period

The API also checks for each entity whether the provided last_modified_on date is within the audit retention time of the entity. If this is not the case for one or more entities, CompoundEmployee API returns an error for the employee, indicating that the provided date isn’t allowed.

Example

Sample Code

<log <log_item> <person_id>4711</person_id>


Data Purge

<person_id_external>Steve</person_id_external> <code>COMPOUND_EMPLOYEE/EMPLOYEE_ERROR</code> <severity>ERROR</severity> <message_text> Data for user id Steve can't be returned: Please see log items for more information. </message_text> </log_item> <log_item> <person_id>4711</person_id> <person_id_external>Steve</person_id_external> <code>COMPOUND_EMPLOYEE/LAST_MODIFIED_ON_IN_AUDIT_PURGE_PERIOD</code> <severity>ERROR</severity> <message_text> The provided last_modified_on is outside of the audit retention period of entity "phone_information" that starts on 2016-12-30T23:00:00.000Z. Please use a last_modified_on later than 2016-12-30T23:00:00.000Z. </message_text> </log_item> </log>

The audit retention time of phone information is configured to 6 months. The audit purge was executed for this employee on June 30, and the audit records of all phone information changes before December 30 were deleted. CompoundEmployee API won’t support delta queries for this employee that have a last_modified_on date before December 30.

In period delta mode, also the provided fromDate is validated against the retention periods of the requested entities. When the fromDate is within the purge period of an entity for an employee, CompoundEmployee API returns an error for this employee.

Example

Sample Code

<log> <log_item> <person_id>4711</person_id> <person_id_external>Steve</person_id_external> <code>COMPOUND_EMPLOYEE/EMPLOYEE_ERROR</code> <severity>ERROR</severity> <message_text> Data for user id Steve can't be returned: Please see log items for more information. </message_text> </log_item> <log_item> <person_id>4711</person_id> <person_id_external>Steve</person_id_external> <code>COMPOUND_EMPLOYEE/FROM_DATE_IN_PURGE_PERIOD</code> <severity>ERROR</severity> <message_text> The provided fromDate is outside of the retention period of entity “address_information” that starts on 2017-01-01. Please use a fromDate later than or equal to 2017-01-01. </message_text> </log_item></log>



Related Information

How the CompoundEmployee API Reacts to Data Purge [page 176]How the Employee Central Data Replication Monitor Reacts to Data Purge [page 196]Purge of Employee Central Data Replicated to ERP Systems [page 198]Purge of Employee Central Data Replicated to Employee Central Payroll [page 209]

3.15.3 How the Employee Central Data Replication Monitor Reacts to Data Purge

If master data or inactive users are purged using Data Retention Management, the related data replication records are also purged in the Employee Central Data Replication Monitor.

Data replication records can be related to the employee, who is identified by the PersonId. This means they are valid for all employments of this employee. Or they can be related to only one employment, which is identified by the UsersSysId. If the employee has multiple employments, only those data replication records are purged that are related to the employment for which the data is purged. Other data replication records stay in the database as long as not all of the employee's employments are purged.

In detail, purge of data replication records goes through these steps:

1. Using Data Retention Management, data is purged for specific employments, identified by UsersSysIds.2. Data Retention Management determines the PersonIds for these UsersSysIds.3. Data Retention Management checks for each PersonId whether the list of UsersSysIds to be purged

contains all UsersSysIds of this PersonId.○ If yes, this means that the employee has only one employment or that the data of all of the employee's

employments was purged. In this case, all data replication records related to this PersonId will be purged.○ If no, this means the employee has multiple employments, but data was purged for only one or several of

these employments, not for all of them. In this case, only the data replication records related to these specific UsersSysIds will be purged. Data replication records for other UsersSysIds of the same PersonId will stay in the database.

NoteOnly data replication records with the replication content types Employee Absence Data, Time Pay Components, and Planned Working Time contain a UsersSysId. Only these records are purged for a UsersSysId. Data replication records with other content types, such as Employee Master Data or Employee Organizational Assignments, only contain the PersonId. They don't have a UsersSysId. This means that these data replication records will stay in the database until the last employment of the respective employee is purged.

4. The data replication records related to the determined UsersSysIds and PersonIds are purged. The referenced Confirmations and Notifications are also purged.


Data Purge

Purging Data Replication Records


Related Information

How the CompoundEmployee API Reacts to Data Purge [page 176]How the CompoundEmployee API Delta Transmission Mode Reacts to Data Purge [page 194]Purge of Employee Central Data Replicated to ERP Systems [page 198]Purge of Employee Central Data Replicated to Employee Central Payroll [page 209]


3.15.4 Purge of Employee Central Data Replicated to ERP Systems

If you have a data integration between your Employee Central and Enterprise Resource Planning (ERP) systems, look at how data purge in Employee Central and ERP interact and how to purge data in your ERP system.

Validation of Employee Data Purge in Data Replication from Employee Central [page 198]When employee master data and employee organizational assignments are purged in Employee Central, the data replication to SAP ERP validates the purge and reacts to it.

Purging Employee Master Data in SAP ERP [page 203]Purge employee master data in SAP ERP with the default tools to remove data from your system and comply with data protection and privacy regulations.

Purge of Employee Time Data Replicated to SAP ERP [page 204]Some things you should know about purging employee time data in the SAP ERP system, and how to trigger a purge run.

Purge of Application Logs in SAP ERP [page 207]Here's more info about purge of application logs in the SAP ERP system that you no longer need.

Purging Inventory Table Records [page 208]Use the Delete Inventory Entries report to purge details from the inventory table.


Related Information

How the CompoundEmployee API Reacts to Data Purge [page 176]How the CompoundEmployee API Delta Transmission Mode Reacts to Data Purge [page 194]How the Employee Central Data Replication Monitor Reacts to Data Purge [page 196]Purge of Employee Central Data Replicated to Employee Central Payroll [page 209]

3.15.4.1 Validation of Employee Data Purge in Data Replication from Employee Central

When employee master data and employee organizational assignments are purged in Employee Central, the data replication to SAP ERP validates the purge and reacts to it.

The Employee Central CompoundEmployee API has two validation options for reacting to the purge of employee data in Employee Central:

● A purge status overview, which provides detailed purge information.● Validation against the effective end date filter, which checks whether the full transmission start date (FTSD) is

in a period for which data was purged.


Data Purge

Depending on which option you use in the CompoundEmployee API, you can configure SAP ERP to consider the selected validation option. The SAP ERP system then reacts accordingly when data is purged for an employee in Employee Central that's included in the data replication to SAP ERP.

NoteThe option you select determines how the SAP ERP reacts to a data purge in Employee Central. It doesn't affect purging data from SAP ERP itself. Purging data in SAP ERP is independent of purging data in Employee Central. You decide for each system separately what data is to be purged.

Parent topic: Purge of Employee Central Data Replicated to ERP Systems [page 198]

Related Information

Purging Employee Master Data in SAP ERP [page 203]Purge of Employee Time Data Replicated to SAP ERP [page 204]Purge of Application Logs in SAP ERP [page 207]Purging Inventory Table Records [page 208]

3.15.4.1.1 Configuring Validation Options for the Replication of Employee Data Purge

Configure the SAP ERP system to react to the purge of employee data in Employee Central.

Prerequisites

The validation option you use must be enabled in the CompoundEmployee API.

Context

You can use the Use Purge Status Overview query parameter in SAP ERP to define whether the data replication from Employee Central is to use the purge status overview or the validation against the effective end date filter provided by the CompoundEmployee API. The difference between these two options is the following:

● Enabling the Purge Status OverviewThe DRTMPurgeStatusOverview segment of the CompoundEmployee API informs the SAP ERP system about what data was purged and provides detailed purge dates. Using the DRTMPurgeStatusOverview segment enables the SAP ERP system to validate the detailed purge dates and react accordingly.The replication is also able to handle the purge of a complete block (for example, the purge of all Address Information time slices) in Employee Central.


You don't need to adjust the full transmission start date (FTSD) defined for the replication of employee master data to prevent errors.The replication distinguishes the deletion of data in Employee Central from a data purge. If data is deleted in Employee Central, the same data is also deleted on the SAP ERP side. If data is purged in Employee Central, the SAP ERP system retains this data because each system is responsible for its own purge.

● Enabling the Effective End Date FilterThe validation against the effective end date filter is carried out in the CompoundEmployee API. If you use this validation, the replication of employee master data can only react to the error messages raised by the CompoundEmployee API.The replication is able to handle the purge of selected time slices. But errors are raised by the API if data is purged in Employee Central that is after the FTSD. The replication fails for the employee in question. You need to adjust the FTSD to prevent errors.If a complete block of data is purged in Employee Central, the employee is no longer replicated.Rehiring a terminated employee with the same employment isn't possible if their data was purged.

Procedure

1. Go to Customizing for Personnel Management and choose Integration with SuccessFactors Employee CentralBusiness Integration Builder Employee Data Integration Define Parameters for Employee Master Data and

Org. Assignment Query .2. Select the Use Purge Status Overview checkbox so that the SAP ERP system uses the

DRTMPurgeStatusOverview segment of the CompoundEmployee API.

3. Leave the Use Purge Status Overview checkbox empty if you want the SAP ERP system to continue to evaluate the validation against the effective end date filter provided by the CompoundEmployee API.

3.15.4.1.2 Use of the Purge Status Overview in the Replication of Data Purge

Learn more about what the SAP ERP system does if you've enabled the use of the purge status overview in SAP ERP.

What the Query Program Does

If you decide to use the purge status overview, the query program queries the purge status overview information instead of the effective end date filter. A DRTMPurgeStatusOverview segment is added to the payload when employee data was purged in Employee Central. The DRTMPurgeStatusOverview segment contains one or more DRTMPurgeStatus subsegments. Each of the DRTMPurgeStatus subsegments informs about what data was purged and provides detailed purge dates.


Data Purge

What Happens in Particular Situations

Let's look at some specific situations, using the Address Information block in Employee Central as an example.

Purge of Individual Time Slices of a Specific BlockIf the Address Information block is partially purged (that is, one or more Address Information time slices are purged, but at least one time slice remains), the remaining time slice is replicated. The DRTMPurgeStatusOverview segment is also added to the payload. It contains the DRTMPurgeStatus subsegment for Address Information. The DRTMPurgeStatus subsegment contains the highestBusinessPurgeDate field. This field holds the start date of the retention period set for Address Information in Employee Central. The infotype records that exist before the highestBusinessPurgeDate are retained in SAP ERP to protect the data.

Purge of All Time Slices of a Specific BlockIf the complete Address Information block is purged (that is, all Address Information time slices are purged, no time slice remains), the DRTMPurgeStatusOverview segment is added to the payload. It contains the DRTMPurgeStatus subsegment for Address Information. The DRTMPurgeStatus subsegment contains the highestBusinessPurgeDate and completePurgeDateTime fields. The completePurgeDateTime field holds the time stamp set in Employee Central when the complete Address Information block was purged. The infotype records that exist in SAP ERP are all retained to protect the data.

Purge and RehireIf the employee was terminated and is rehired after their data (including some or all Address Information time slices) was purged, the DRTMPurgeStatusOverview segment is added to the payload. It contains DRTMPurgeStatus subsegments for the purged data, such as Address Information. In each DRTMPurgeStatus subsegment, the rehiredAtDateTime field is set in addition to the other date field (either highestBusinessPurgeDate or completePurgeDateTime). The rehiredAtDateTime field holds the time stamp set in Employee Central when the employee was rehired. The rehire date to be used in SAP ERP for the infotypes is approximately determined from the data entered in Employee Central during the rehire process, to ensure that valid data is used in SAP ERP. The infotypes in SAP ERP are updated using this date as the start date.

Purge of Organizational Assignments

The same processing as for employee master data applies when an employee's job relations (such as matrix manager or HR manager relationships) are purged in Employee Central.

The SAP ERP adds the following information in the staging area:

● The Date Before Which Data Was Purged in Employee Central field is filled with the date from which job relationships are available for an employment in Employee Central and can be replicated. Before this date, no job relationship data exists for this employment because the data was purged. The SAP ERP system stores one of the following dates in this field:○ If the job relationship data was purged for a specific period: The start date of the retention period.○ If all job relationship data was purged because the employee was terminated, and is then available again

because the employee was rehired with the same employment: Either the start date of the retention period or the rehire date, depending on which one is the later date.

● The Data Was Completely Purged in Employee Central flag is set when all job relationships for a specific employment were purged in Employee Central because the employee was terminated. If this indicator is set,


the Date Before Which Data Was Purged in Employee Central field is empty because there's no date from which job relationship data is available for the replication.

3.15.4.1.3 Use of the Effective End Date Filter in the Replication of Data Purge

Find out how the SAP ERP system reacts if you've enabled the validation against the effective end date filter for the Employee Central CompoundEmployee API.

Retention Times

When configuring retention times for employee data in Employee Central, consider the full transmission start date (FTSD) you've defined for employee master data and organizational data replication to SAP ERP: The FTSD must be after the latest retention date of any entity that's contained in data replication to SAP ERP.

Data Purge for Active Employee

The CompoundEmployee API raises an error message if employee data was purged in Employee Central that is still needed for replication to SAP ERP. When data is purged that is after the FTSD defined for employee master data and organizational assignment replication, data replication fails for the employee in question. Individual retention dates aren't evaluated. It uses the highest date of all retention dates you've defined.

NoteThis error message is raised by the CompoundEmployee API only if at least support package 20 of the PA_SE_IN 100 software component version is installed in your SAP ERP system. If you want to use the purge option in Employee Central, make sure that you first install SP20 in your SAP ERP system.

Data Purge for Terminated Employee

If specific data such as the address or email of a terminated employee is completely purged when doing a partial purge in Employee Central, the CompoundEmployee API raises a different error message for this employee. If only one of the employee's employments is terminated (such as in a global or concurrent employment situation), the error message is raised for this employment.

NoteThis error message is raised by the CompoundEmployee API only if at least support package 21 of the PA_SE_IN 100 software component version is installed in your SAP ERP system. If you want to use partial purge in Employee Central, make sure that you first install SP21 in your SAP ERP system.


Data Purge

Employee master data replication to SAP ERP reacts on this error message by ignoring the employee in question. That is, the employee's data is no longer replicated. From a replication point of view, the status is Successful in this case. That's why a success confirmation is sent for the employee. As a result, the Employee Central Data Replication Monitor shows the Successful status for employee master data and organizational assignment replication for this employee. If only one employment is terminated, the replication of employee master data and organizational assignments ignores this employment, but still transfers data for the other employment.

If you want to rehire such an employee in Employee Central, make sure that you create a new employment. Don't use the Rehire event. You can't use the Rehire event because the employee still has data in Employee Central and therefore will still be ignored by employee master data and organizational assignment replication. To ensure that the employee's data can be replicated, you must use a New Hire event.

3.15.4.2 Purging Employee Master Data in SAP ERP

Purge employee master data in SAP ERP with the default tools to remove data from your system and comply with data protection and privacy regulations.

Procedure

1. Use the corresponding archiving objects in the Archive Administration (SARA) transaction to purge employee master data in SAP ERP.

2. Use the program Destruction of Personnel Numbers in Live Systems (RPUDELPP) or the Delete Personal Data (PU00) transaction to purge selected personnel numbers and the related infotype records in productive systems.

3. Use the program Delete Personnel Numbers Completely (RPUDELPN) to purge selected personnel numbers and the related infotype records in test and other non-productive systems.

Task overview: Purge of Employee Central Data Replicated to ERP Systems [page 198]

Related Information

Validation of Employee Data Purge in Data Replication from Employee Central [page 198]Purge of Employee Time Data Replicated to SAP ERP [page 204]Purge of Application Logs in SAP ERP [page 207]Purging Inventory Table Records [page 208]


3.15.4.3 Purge of Employee Time Data Replicated to SAP ERP

Some things you should know about purging employee time data in the SAP ERP system, and how to trigger a purge run.

What You Should Know About Data Purge

If employee time data records are purged in Employee Central, no data replication proxies are created for the purged data. Preventing the creation of data replication proxies ensures that purged employee time data isn’t replicated to the SAP ERP system. This is the default setup, there's no need for you to configure anything in Employee Central.

The following restriction currently applies to data purge in Employee Central:

NotePlease note that, in the current release, this function is fully available in test and preview environments only. You can set it up and test it, but unfortunately you won’t be able to work with any live data in a productive environment just yet. The function will be available productively in a future release.

How to Purge Employee Time Data

To purge employee time data in SAP ERP, use the default tools provided there:

● Using the corresponding archiving object in the Archive Administration (SARA) transaction, you can destroy employee time data in SAP ERP.For more information, see Destroying Time Management Data (PT).

● Using the program Destruction of Personnel Numbers in Live Systems (RPUDELPP) or the Delete Personal Data (PU00) transaction, you can destroy personnel numbers and the related infotype records – which includes employee time-related infotype records.

NoteIn non-productive systems, use the program Delete Personnel Numbers Completely (RPUDELPN) instead of the RPUDELPP program.

For more information, see Destruction of Personnel Numbers in the application help for SAP ERP.

What Other Data Is Purged

In both cases the following additional data needs to be purged:

● Data stored in the Reference Key Mapping (PAOCFEC_REFMAP) table


Data Purge

https://help.sap.com/viewer/79bf89044e8e484fabad18711260f13a/latest/en-US/155cb1954a954fb8a7604b1d7f959a19.html

https://help.sap.com/viewer/d3bc4479e3344626be836c03a5c6962f/latest/en-US/ec6aa852c8296028e10000000a441470.html

This table stores the mapping information between the Employee Time object from Employee Central and the corresponding infotype record in SAP ERP. It must always be in sync with the HR Time Record: Infotype 2001 (Absences) (PA2001) and HR Time Record: Infotype 2010 (Employee Remuneration Info) (PA2010) tables.

TipIn case data inconsistencies occur between the PAOCFEC_REFMAP table and table PA2001 or PA2010, you can also use the Clean-Up of Employee Time Data Replicated from Employee Central (ECTIM_CLEANUP_REFMAP_INFTY_TAB) program to clean them up.

● Data stored in the Linking Index for Employee Time Groups (ECTIM_LINK_INDEX) tableThis table stores link indices for identical or overlapping sickness absences, which are linked in Employee Central Time Off and replicated to the SAP ERP system.


We provide Business Add-In (BAdI) implementations, which delete the relevant data from these tables:

BAdI Implementations for Deleting Employee Time Data

If you delete employee time data using...

The system calls this implementation... Of this BAdI definition... What's good to know...

Archive Administration (transaction SARA)

EC Time Integration BLP-Save: Delete Refmap/Link-Index (ECTIM_PT_BLP_SAV)

Enhance Business Logic for Time Data (PT_BLP_USER)

By default, this BAdI implementation isn’t called. We strongly recommend that you activate it. To do this, you have two options, depending on whether you’ve already implemented the Enhance Business Logic for Time Data (PT_BLP_USER) BAdI or not:

● If you haven’t implemented the PT_BLP_USER BAdI yet, activate this implementation. To do so:1. Go to transaction

SE19.

2. In the Classic BAdI Implementation field, enter ECTIM_PT_BLP_SAV and choose Change.

3. Choose Activate Business Add-In Implementation.

● If you’ve already implemented the PT_BLP_USER BAdI, don't activate the implementation. Instead, add the PROCESS_DATA method of the implementing class CL_IM_ECTIM_PT_BLP_SAV in your customerspecific implementation for the SAV time point.

Delete Personnel Numbers Completely (program RPUDELPN) or Delete Personal Data (transaction PU00)

Delete EE Time Key Mapping Record for Given Pers. Number (TIM_SFEC_DEL_PERNR)

BAdI for Reports Deleting Personnel Numbers (HRPAYXX_DELETE_PERNR)

This BAdI implementation is called by default


Data Purge


Related Information

Validation of Employee Data Purge in Data Replication from Employee Central [page 198]Purging Employee Master Data in SAP ERP [page 203]Purge of Application Logs in SAP ERP [page 207]Purging Inventory Table Records [page 208]

3.15.4.4 Purge of Application Logs in SAP ERP

Here's more info about purge of application logs in the SAP ERP system that you no longer need.

What Data Can Be Purged

Data replication between Employee Central and SAP ERP uses the following objects when writing messages to the application log:

● Employee data replication from SAP ERP to Employee Central:Object ECPAO with subobjects:○ ECPAO○ ECPAO_KEYVALUE○ ECPAO_MANAGER○ ECPAO_METADATA

● Organizational data replication from SAP ERP to Employee Central:Object ECPAO with subobject ECPAO_OM

● Combined employee master data and organizational assignments replication from Employee Central to SAP ERP:Object ECPAO_IN with subobjects:○ GEN for generic messages○ EE for employee master data○ VERBOSE for the Verbose message log

● Employee master data replication from Employee Central to SAP ERP:Object PAOC_SFI_PA with subobject EE

● Organizational data or organizational objects replication from Employee Central to SAP ERP:Object PAOC_SFI_OM with subobjects:○ REPL_REQ_PROCESSING for the log created by the replication to the SAP ERP HCM system○ REPL_REQ_PROXY for the log created when processing the inbound message in SAP ERP HCM

● Employee time data replication from Employee Central to SAP ERP:Object PAOC_SFI_PA with subobject EE_TIME


How to Purge Data

Use the BC_SBAL archiving object in the Archive Administration (SARA) transaction to delete these application logs in SAP ERP if you no longer need them. The archiving object calls the SBAL_ARCHIVE_DELETE program, which deletes the data from the archived logs from the original tables.

On the selection screen of the SBAL_ARCHIVE_DELETE program, enter the following data:

● Object and Subobject: Select all application log objects and subobjects whose logs you want to delete● From (Date/Time): To delete all logs, enter 18000101● To (Date/Time): Enter the latest possible date, keeping in mind that only the logs written after that date will still

be available in SAP ERP

For more information, see Archiving Object BC_SBAL in the SAP NetWeaver documentation.


Related Information

Validation of Employee Data Purge in Data Replication from Employee Central [page 198]Purging Employee Master Data in SAP ERP [page 203]Purge of Employee Time Data Replicated to SAP ERP [page 204]Purging Inventory Table Records [page 208]

3.15.4.5 Purging Inventory Table Records

Use the Delete Inventory Entries report to purge details from the inventory table.

Context

By using the Delete Inventory Entries report ECPAO_TO_ERP_INVT_DELETE, you can purge the details from the inventory table which are no longer used or relevant. Cleanup of the inventory tables will ensure only the relevant records are stored in the table, which will improve the performance while processing data.

Procedure

1. Choose the Personnel Number, Action Type, Personnel area, Personal subarea, Employee group, or Employee subgroup for which you want to purge the data.


Data Purge

https://help.sap.com/viewer/addb96cd90c945dfb3182865363bbc47/latest/en-US/4e4a2209872c3b0fe10000000a42189e.html

2. Choose the Time Period or the Retention Period. Based on the Time Period or the Retention Period, the records will be purged from the ECPAO_INVT_INFTY and ECPAO_INVT_ITMSG tables. Data which are before the purge date would be purged from the inventory tables.

Task overview: Purge of Employee Central Data Replicated to ERP Systems [page 198]

Related Information

Validation of Employee Data Purge in Data Replication from Employee Central [page 198]Purging Employee Master Data in SAP ERP [page 203]Purge of Employee Time Data Replicated to SAP ERP [page 204]Purge of Application Logs in SAP ERP [page 207]

3.15.5 Purge of Employee Central Data Replicated to Employee Central Payroll

Since you have data integration between Employee Central and Employee Central Payroll in place, take a look at how data purge in Employee Central and Employee Central Payroll interact and how to purge data in your Employee Central Payroll system.

NoteYou must purge data in both systems: Employee Central and Employee Central Payroll. This is because data purged in Employee Central is not automatically purged in Employee Central Payroll.

Prerequisites

Before you begin, please read 2598362 and information about Data Protection in the Security Guide for Human Resources Management.

Purging Employee Master Data Replicated to Employee Central Payroll [page 210]Look at how you can purge employee master data in the Employee Central Payroll system.

Purge of Time Data Replicated to Employee Central Payroll [page 212]Take a look at how you can purge time data in the Employee Central Payroll system.

Purge of Application Logs in Employee Central Payroll [page 213]Here's how to purge application logs in the Employee Central Payroll system that you no longer need.



http://help.sap.com/disclaimer?site=https://launchpad.support.sap.com/#/notes/2598362

https://help.sap.com/viewer/928991e452634382a457e4655ea675b7/latest/en-US/4761ec5353d5764ae10000000a441470.html

Related Information

How the CompoundEmployee API Reacts to Data Purge [page 176]How the CompoundEmployee API Delta Transmission Mode Reacts to Data Purge [page 194]How the Employee Central Data Replication Monitor Reacts to Data Purge [page 196]Purge of Employee Central Data Replicated to ERP Systems [page 198]

3.15.5.1 Purging Employee Master Data Replicated to Employee Central Payroll

Look at how you can purge employee master data in the Employee Central Payroll system.

What You should Know About Data Purge

When configuring retention times for employee data in Employee Central, consider the Full Transmission Start Date (FTSD) you've defined for replicating employee master data to Employee Central Payroll. The Full Transmission Start Date (FTSD) must be later than the latest retention date of any entity that is contained in data replication to Employee Central Payroll.

The following logics are in place:

● During the replication process, an error message is raised if employee data is purged in Employee Central that is still needed for replication to Employee Central Payroll. Meaning, when the end date of the purged data is later than the FTSD defined for the employee master data replication, data replication fails for the employee in question. Data with the shortest retention time determines where to set the FTSD as described in the Customizing guide for Integration Settings for SuccessFactors Employee Central Payroll Configuration of Point-to-Point Replication Configure Compound Employee API Query . Note that you can move the FTSD as many times as necessary in this customizing activity.

● As of Q4 2018, if support package 60 of the EA-HRRXX software component version is installed in your Employee Central Payroll system, employee master data replication is automatically purged for the following employee data if you’ve enabled the SFEC DRTM switch in the V_T77S0 view. This means that you no longer have to make settings for the FTSD for the following employee master data replication to Employee Central Payroll:○ Personal Information○ Address Information○ Payment Information○ Dependents Information

ExampleIf you activate the replication of purged information, the replication uses this information to restore data from the database in the time frame including the mapped data. Therefore, make sure that your BAdIs don’t override this logic once the mapping is done.


Data Purge

We strongly recommend implementing a check at the start of your BAdI coding if purged information is included in the master data you want to replicate. An example is available in the BAdI definition itself. By doing this, you can prevent restored data from being deleted in your BAdI implementation as shown in the graphic:

For terminated employees, the partial purge purges the complete data of master data records, as soon as the termination date is outside of the retention period of the master data records in question.

During the replication process, an error message is raised for all employees for whom at least one personspecific record such as mail or address information has been purged completely. The replication process ignores all employment of an employee, for which at least one employmentspecific record such as compensation has been purged completely. If all employments of the employee are affected by the complete purge, the replication process raises an error message.

NoteThese error messages are only raised during the replication process, if support package 47 of the EA-HRRXX software component version is installed in your Employee Central Payroll system. If you want to use purge in Employee Central, make sure that you first install SP47 in your system. Otherwise, purges done in the Employee Central system might lead to unintended data loss in Employee Central Payroll once the data is replicated.

If you want to rehire such an employee in Employee Central, make sure that you create an employment. Don't use the Rehire event. This is because the employee still has data in Employee Central and will still be ignored by employee master data replication. For more information about Rehiring scenarios, see Rehiring an Employee.

Note that you can replicate master data of rehired employees from Employee Central after a complete purge of blockspecific data.

How to Purge Data

To purge employee master data in Employee Central Payroll, use the default tools provided there:

● Using the respective archiving objects in the Archive Administration (SARA) transaction, you can destroy employee master data in Employee Central Payroll.For more information, see Archiving and Destroying Personnel Administration Data (PA-PA)


https://help.sap.com/viewer/4b0f4a72b0ea46fb9b9917bdd7c8f29b/latest/en-US/f7ba417021e34902b3862737f7907b5e.html

https://help.sap.com/viewer/d3bc4479e3344626be836c03a5c6962f/latest/en-US/14c8e051bfab464e9e2b8c7833c181fa.html

● Using the Delete Personnel Numbers Completely (RPUDELPP) program or the Delete Personal Data (PU00) transaction, you can destroy personnel numbers and the related infotype records – which includes employee master data infotype records.For more information, see Destruction of Personnel Numbers in the application help for Employee Central Payroll.

Parent topic: Purge of Employee Central Data Replicated to Employee Central Payroll [page 209]

Related Information

Purge of Time Data Replicated to Employee Central Payroll [page 212]Purge of Application Logs in Employee Central Payroll [page 213]

3.15.5.2 Purge of Time Data Replicated to Employee Central Payroll

Take a look at how you can purge time data in the Employee Central Payroll system.

What you should know about data purge

● If time data records are purged in Employee Central, no data replication proxies are created for the purged data. This ensures that purged time data is not replicated to Employee Central Payroll. This is the default setup, so there's no need for you to configure anything in Employee Central. An error message is raised for purged time data unsuccessfully replicated. To correct failed replications, make the replication possible or delete the data replication proxy if no replication of this time data is needed or wanted.

● If master data records, for example, of terminated employees are fully purged in Employee Central, no data replication proxies are created for the purged data. Note that no error message will be raised to Employee Central Payroll if the replication of time data was not successful. The purge in Employee Central gets completed.

How to purge time data

To purge time data in Employee Central Payroll, use the corresponding archiving object in the Archive Administration (SARA) transaction to destroy time data in Employee Central Payroll.

● For more information, see Destroying Time Management Data (PT).


Data Purge

https://help.sap.com/viewer/d3bc4479e3344626be836c03a5c6962f/latest/en-US/ec6aa852c8296028e10000000a441470.html

https://help.sap.com/viewer/79bf89044e8e484fabad18711260f13a/latest/en-US/155cb1954a954fb8a7604b1d7f959a19.html

What other data is purged

In both cases the following additional data is automatically purged:

● Data stored in the Reference Key Mapping (HRSFEC_D_REFMAP) tableThis table stores the mapping information between the Time object from Employee Central and the corresponding infotype record in Employee Central Payroll. It should always be in sync with the infotype tables like HR Time Record: Infotype 2001 (Absences) (PA2001) and HR Time Record: Infotype 2010 (Employee Remuneration Info) (PA2010).

TipWhere data inconsistencies occur between the HRSFEC_D_REFMAP table and the corresponding infotype tables, for example, PA2001 and PA2010, you can also use the Clean-Up of Employee Time Data Replicated from Employee Central (RP_HRSFEC_CLEANUP_TIME_DATA) program to clean them up.

● Data stored in the Linking Index for Employee Time Groups (ECTIM_LINK_INDEX) tableThis table stores link indices for identical or overlapping sicknesses, which are linked in Employee Central Time Off and replicated to the Employee Central Payroll system.


Related Information

Purging Employee Master Data Replicated to Employee Central Payroll [page 210]Purge of Application Logs in Employee Central Payroll [page 213]

3.15.5.3 Purge of Application Logs in Employee Central Payroll

Here's how to purge application logs in the Employee Central Payroll system that you no longer need.

What data can be purged

Data replication between Employee Central and Employee Central Payroll uses the following objects when writing messages to the application log:

● Employee master data replication from Employee Central to Employee Central Payroll:Object HRSFEC with subobject Employee or EMPLOYEE_PTP

● Employee time data replication from Employee Central to Employee Central Payroll:Object HRSFEC with subobject EMPLOYEE_TIME or EMPLOYEE_TIME_PTP.

● Object HRESS without subobject created using report HRSFEC_ESS_USER_UPDATE


How to purge data

Use the BC_SBAL archiving object in the Archive Administration (SARA) transaction to delete these application logs in Employee Central Payroll, if you no longer need them. The archiving object calls the SBAL_ARCHIVE_DELETE program, which deletes the data contained in the archived logs from the original tables.

On the selection screen of the SBAL_ARCHIVE_DELETE program, enter the following data:

● Object and Subobject: Select all application log objects and subobjects whose logs you want to delete● From (Date/Time): To delete all logs, enter 18000101● To (Date/Time): Enter the latest possible date, keeping in mind that only the logs written after that date will still

be available in Employee Central Payroll.

For more information, see Archiving Object BC_SBAL in the SAP NetWeaver documentation.


Related Information

Purging Employee Master Data Replicated to Employee Central Payroll [page 210]Purge of Time Data Replicated to Employee Central Payroll [page 212]

3.16 Legal Holds on Data

A legal hold (or "litigation hold") is when you are required to preserve certain data records pending legal proceedings. When a legal hold is placed on data, you need to exclude it from your normal data purge process until the hold is lifted.

The DRTM data purge function enables you to place a legal hold on data for a specific user by adding them to a "purge freeze list". You can use the purge freeze list to put a legal hold on data for users, employment, or candidates. As long as an individual user, employment, or candidate is on the purge freeze list, their data is excluded from all DRTM purge requests, whether the retention time has elapsed or not.

To manage the purge freeze list, use the MDF Manage Data tool to edit the DRTM Purge Freeze MDF extension object.

Note● The purge freeze list is only used by DRTM purge requests. Legacy (non-DRTM) purge requests do not

consider this list and DO delete data for any users who meet the purge criteria, even if they are on the purge freeze list.

● After your changes to the purge freeze list are saved, these changes only affect future DRTM purge requests and future jobs of existing recurring purge requests.

Permission to Edit the Purge Freeze List [page 215]


Data Purge

https://help.sap.com/viewer/addb96cd90c945dfb3182865363bbc47/latest/en-US/4e4a2209872c3b0fe10000000a42189e.html

To edit the purge freeze list, using Metadata Framework (MDF) tools, you need certain role-based permissions.

Adding a User to the Purge Freeze List [page 216]Add a new user, employment, or candidate to the purge freeze list so that their data is retained and excluded from DRTM purge requests.

Adding Multiple Users to the Purge Freeze List [page 217]Add multiple users or candidates to the purge freeze list so that their data is retained and excluded from DRTM purge requests.

Editing an Existing Entry on the Purge Freeze List [page 219]Edit an existing entry about a specified user, employment, or candidate on the purge freeze list.

Deleting an Existing Entry on the Purge Freeze List [page 220]Permanently delete an entry on the purge freeze list so that data associated the specified user, employment, or candidate can be purged..

Related Information

Excluding People from the Learning Audit History Purge [page 245]

3.16.1 Permission to Edit the Purge Freeze List

To edit the purge freeze list, using Metadata Framework (MDF) tools, you need certain role-based permissions.

The purge freeze list is stored in an MDF object DRTM Purge Freeze. To edit the purge freeze list, you need permission to edit data in this object.

● To access to the MDF Manage Data tool and edit MDF data in general, you need the role-based permission Administrator Permissions Metadata Framework Manage Data .

● To edit the purge freeze list used by DRTM data purge, you need the following edit permissions for the MDF object DRTM Purge Freeze:

○ User Permissions Data Retention Management View

○ User Permissions Data Retention Management Edit

○ User Permissions Data Retention Management Import/Export

People with these permissions can put a legal hold on individual users, employments, or candidates by editing the DRTM Purge Freeze object.

Parent topic: Legal Holds on Data [page 214]

Related Information

Adding a User to the Purge Freeze List [page 216]


Adding Multiple Users to the Purge Freeze List [page 217]Editing an Existing Entry on the Purge Freeze List [page 219]Deleting an Existing Entry on the Purge Freeze List [page 220]

3.16.2 Adding a User to the Purge Freeze List

Add a new user, employment, or candidate to the purge freeze list so that their data is retained and excluded from DRTM purge requests.

Prerequisites

You have the MDF permission Manage Data and permission to edit data for the DRTM Purge Freeze object.

Context




If you are not using DRTM or have not yet set it up, this task is unnecessary and has no effect.

This task does not exclude people from the Learning audit history purge. That task is done separately.

Procedure

1. Go to Admin Center Tools Manage Data .2. In the Create New dropdown menu, find and select the DRTM Purge Freeze object.3. Select the type of user you want to add in the Purge Freeze Target Type field.

○ Select Employment to add a standard user (employee).○ Select Candidate to add an external candidate in SAP SuccessFactors Recruiting.

4. Fill out the remaining fields:


Data Purge

Field Description

Employment / Candidate ID For employments, use search to find and select the user or employment you want to add. People with multiple employments return multiple search results and you can only select one of them.

For external candidates, enter a numeric Candidate ID.

Description Add a display label, as the entry should appear on the purge freeze list and in purge reports.

Comment Add additional information, such as the legal reason for the purge freeze.

5. Click Save to save your changes.

Results

The specified user, employment, or candidate is added to the purge freeze list. A DRTM purge request will exclude data for this user.

Task overview: Legal Holds on Data [page 214]

Related Information

Permission to Edit the Purge Freeze List [page 215]Adding Multiple Users to the Purge Freeze List [page 217]Editing an Existing Entry on the Purge Freeze List [page 219]Deleting an Existing Entry on the Purge Freeze List [page 220]Excluding People from the Learning Audit History Purge [page 245]Excluding People from the Learning Audit History Purge [page 245]

3.16.3 Adding Multiple Users to the Purge Freeze List

Add multiple users or candidates to the purge freeze list so that their data is retained and excluded from DRTM purge requests.

Prerequisites



Context





This task does not exclude people from the Learning audit history purge. That task is done separately.

Procedure

1. Go to Admin Center Import and Export Data .2. Choose Download Template and select the DRTM Purge Freeze object.3. Open the template and fill in the type of user you want to add in the Purge Freeze Target Type column.

○ Enter a user ID in the Employment column to add a standard user (employee).○ Enter a numeric Candidate ID in the Candidate ID column to add an external candidate in SAP

SuccessFactors Recruiting.4. Fill out remaining required columns and save the file.

Column Description

Description Add a display label, as the entry should appear on the purge freeze list and in purge reports.

Comment Add additional information, such as the legal reason for the purge freeze.

5. Go back to Import and Export Data and choose to perform Import Data.6. Select DRTM Purge Freeze as the generic object in the CSV File tab.7. Upload the file you prepared.

Results

You receive an email notification email when the process is completed. If the import is successful, those users, employment, or candidates are added to the purge freeze list. A DRTM purge request will exclude data for this user.

If not, you can download detailed report in Monitor Jobs.



Data Purge

Related Information

Permission to Edit the Purge Freeze List [page 215]Adding a User to the Purge Freeze List [page 216]Editing an Existing Entry on the Purge Freeze List [page 219]Deleting an Existing Entry on the Purge Freeze List [page 220]Excluding People from the Learning Audit History Purge [page 245]

3.16.4 Editing an Existing Entry on the Purge Freeze List

Edit an existing entry about a specified user, employment, or candidate on the purge freeze list.

Prerequisites


Context





Procedure

1. Go to Admin Center Tools Manage Data .2. In the first search box, find and select the DRTM Purge Freeze object from the dropdown menu.3. In the second search box, select the existing exclusion that you want to edit.

The existing information is displayed.

4. Click Take Action Make Correction .5. Edit fields as needed.


6. Click Save to save your changes.

Results

Your changes are saved and considered by future DRTM purge requests affecting this user, employment, or candidate.


Related Information

Permission to Edit the Purge Freeze List [page 215]Adding a User to the Purge Freeze List [page 216]Adding Multiple Users to the Purge Freeze List [page 217]Deleting an Existing Entry on the Purge Freeze List [page 220]

3.16.5 Deleting an Existing Entry on the Purge Freeze List

Permanently delete an entry on the purge freeze list so that data associated the specified user, employment, or candidate can be purged..

Prerequisites


Context






Data Purge

Procedure

1. Go to Admin Center Tools Manage Data .2. In the first search box, find and select the DRTM Purge Freeze object from the dropdown menu.3. In the second search box, select the existing exclusion that you want to delete.

The existing information is displayed.

4. Click Take Action Permanently Delete Entry .5. Click Save to save your changes.

Results

The entry is permanently deleted from the purge freeze list. Data associated with the specified user, employment, or candidate can now be purged by a DRTM purge request.


Related Information

Permission to Edit the Purge Freeze List [page 215]Adding a User to the Purge Freeze List [page 216]Adding Multiple Users to the Purge Freeze List [page 217]Editing an Existing Entry on the Purge Freeze List [page 219]

3.17 Check for Updates in Upgrade Center

Check the Upgrade Center periodically to ensure that you've enabled all the available DRTM objects.

New DRTM object may become available as new features are added. Or sometimes we make changes to object configurations and you should update the object. To ensure your DRTM solution is up-to-date, visit the Upgrade Center periodically and complete all the available DRTM upgrades.


3.18 Changing the Minimum Number of Approvers for Purge Requests

Change the minimum number of approvers required for purge requests. By default, the minimum number of approvers is one.

Prerequisites


Procedure

1. Go to Admin Center Tools Company System and Logo Settings .2. Under Data Retention Management, in the Minimum # of approvers field, enter an integer value of 1 or more.

For better oversight of the data purge function, we recommend a value of 2 or more to ensure that no single individual can purge data on their own.

3. Click Save Company System Setting to save your changes.

Results

When creating a purge request, you now must add the specified minimum number of approvers to a purge request before you can submit it.

Related Information



Data Purge

3.19 Checking Job Status and Details for a Purge Request

Use the Purge Request Monitor to check the status of a purge job or link to more job details in the Execution Manager.

Prerequisites

● To check status, you need permission to either create or approve purge requests.● To see job details, you also need permission to access Execution Manager.

Procedure

1. Go to Admin Center Tools Purge Request Monitor .2. Find the purge request you are interested in, using the Request Name defined during purge set-up.3. Check the current status of the purge job in the Status column.

○ Completed means that the background purge process has completed successfully and that data was either purged or excluded, according to backend purge rules. It does NOT mean that all data for all specified users were necessarily purged. To confirm whether a given user was successfully purged, check the Process Status in the purge report.Review the purge report to confirm which data was purged and which data was excluded.

○ Completed With Error means that the background purge process has completed and was mostly successful, with some possible exceptions. Exceptions occur when we find bad data that prevents a certain type of data from being purged successfully for some users.Use the View Job Details action to identify the source of the error or contact Product Support for help.

○ Completed with empty report means that the background purge process has completed successfully but none of the specified user data was eligible for purging, so no data purge occurred. For example, if you try to purge all inactive users in Germany but there are no inactive users in your system who are in Germany and past the required retention time, then the report is empty.If correct, no action is needed. If you think this might not be correct, double check the purge criteria and configured retention time. Then submit the request again.

○ Processing purge means that the background purge process is still in progress.Check again later.

○ Expired means that a preview report was generated successfully but the designated approvers didn’t respond in time, so no data purge occurred.Submit the request again.

○ Failed means there was an internal error that caused the background purge process to fail.Submit the request again. If the problem persists, contact Product Support for help.

○ Declined means that a preview report was generated but one of the designated approvers rejected the request, so no data purge occurred.Double check the purge criteria or contact approvers to understand why it was declined. Then adjust the criteria as needed and submit the request again.


4. For technical details about a purge job, to help with troubleshooting, use the View Job Details action to open details from the Execution Manger in a pop-up window.

3.20 Deleting Old Purge Requests

Delete your old purge requests when they’re expired, failed, or completed to remove unnecessary clutter from the Purge Request Monitor.

Prerequisites

● You have permission to either create or approve purge requests.● The purge request has a status of EXPIRED, FAILED, or COMPLETED.● You’re the requestor of the purge request.

Context

A large organization with complex purge rules in multiple countries/regions or regions may have a large number of past purge requests. You can delete your old purge requests to remove clutter from the page.

NotePurge requests that are more than 180 days are being deleted monthly from the system automatically. The associated purge reports are deleted as well. You can't find them in the Purge Request Monitor.

CautionDeleting a purge request also deletes its associated purge reports. If you want to keep these reports, be sure to download and archive them before deleting the purge request.

Procedure

1. Go to Admin Center Purge Request Monitor Purge Progress & Results .2. Locate the purge request you want to delete.3. Select Delete Request from the actions menu and then Yes to confirm.


Data Purge

Results

The purge request is permanently deleted and removed from the Purge Request Monitor, along with its associated reports.

3.21 Deleting Old Purge Reports

Delete your old purge reports when they are no longer needed.

Prerequisites

● You have either Remove Preview and Complete Reports for DRTM Data Purge Request or Remove Preview and Complete Reports for Legacy Data Purge Request permission.

Context

Purge reports can contain personal information so periodically you may need to remove them from storage, for data protection and privacy.

NotePurge requests that are more than 180 days are being deleted monthly from the system automatically. The associated purge reports are deleted as well. You can't find them in the Purge Request Monitor.

Procedure

1. Go to Admin Center Tools Purge Request Monitor Purge Progress & Results .2. Locate the purge request with reports you want to delete.3. Use the actions menu to select the report you want to delete and then Yes to confirm.

○ Select Remove Preview Report to delete the preview that was generated before the purge.○ Select Remove Complete Report to delete the final report that was generated after the purge.

Results

The selected report is permanently deleted from storage and cannot be recovered.


3.22 Non-Standard Purge Processes

Although most customers and most configurations can follow the standard purge process, some customers and some configurations have non-standard purge processes.

Most customers can follow steps to set up and use DRTM data purge in a standard way. However, some customers can't follow the standard process because, for example, they have not adopted the SAP SuccessFactors platform or they have a configuration that is non-standard.

Non-Standard Data Purge Processes

Solution Non-Standard Process More Information

Learning Native-Only SAP SuccessFactors Learning Customer Configurations


Learning If you have learning sites with external users and if you are integrated with Platform, then you cannot run a partial data purge of the external users by yourself. Please create a support ticket.




All Purging data in MDF custom objects DRTM Data Purge for MDF Custom Objects [page 258]

Employee Central Configuring Retention Period to Purge Import Jobs in SAP SuccessFactors Compensation


Employee Central Purging Employee Central Data Replicated to ERP Systems

Purge of Employee Central Data Replicated to ERP Systems [page 198]

Native-Only SAP SuccessFactors Learning Customer Configurations [page 227]A native-only SAP SuccessFactors Learning configuration is one that does not use SAP SuccessFactors platform. This configuration is rare.

Purge Process for Integrated Users of Learning Sites (External Users) [page 249]Data purge for External Learners isn’t fully supported in SAP SuccessFactors Platform. If you need to purge External Learners, contact Customer Support for other purge options.

Purging SAP SuccessFactors Learning Background Jobs Automatically [page 253]Automatically purge SAP SuccessFactors Learning background jobs to keep your application clean of past job data.


Data Purge

Purging SAP SuccessFactors Learning Background Reports Automatically [page 254]Automatically purge SAP SuccessFactors Learning background reports to keep your data clean of past report data.

Email Notification Archiving in SAP SuccessFactors Learning [page 255]SAP SuccessFactors Learning offers you choices for archiving email that it sends. Choose an archiving option that matches your company policy.

DRTM Data Purge for MDF Custom Objects [page 258]MDF supports modules to fulfill their requirements for data purge within data retention management for custom MDF entities.

Configuring Retention Period to Purge Import Jobs [page 263]The system automatically purges all the completed import jobs listed on the Monitor Job page depending on the retention period.

Managing Data Retention Settings for Candidates and Client Administrators in Career Site Builder [page 264]

3.22.1 Native-Only SAP SuccessFactors Learning Customer Configurations

A native-only SAP SuccessFactors Learning configuration is one that does not use SAP SuccessFactors platform. This configuration is rare.

A native-only customer is one that has not adopted SAP SuccessFactors platform, so user identities are known only to SAP SuccessFactors Learning. There are many advantages to adopting the platform, but a few include:

● As a platform customer, you can use standard SAP SuccessFactors data retention management tools. As a native-only customer, you have a different process.

● As a platform customer, you can easily adopt other parts of the SAP SuccessFactors suite, including single sign-on and integration center.

● You are ready for the eventual retirement of the native-only configuration.

NoteOnly a small minority of customers is native-only, so chances are that you have adopted platform.

Parent topic: Non-Standard Purge Processes [page 226]

Related Information

Purge Process for Integrated Users of Learning Sites (External Users) [page 249]Purging SAP SuccessFactors Learning Background Jobs Automatically [page 253]Purging SAP SuccessFactors Learning Background Reports Automatically [page 254]Email Notification Archiving in SAP SuccessFactors Learning [page 255]DRTM Data Purge for MDF Custom Objects [page 258]Configuring Retention Period to Purge Import Jobs [page 263]


Managing Data Retention Settings for Candidates and Client Administrators in Career Site Builder [page 264]

3.22.1.1 Purge Process for Native-Only Learning Configurations

Use the purge process for native-only Learning configurations when users are not part of SAP SuccessFactors platform and when you want to remove user or their information (like learning assignments, history, and personal information) from SAP SuccessFactors Learning.

When you set up data purge, you create a process that removes all traces of user data from the system. In the case of Learning native-only users, all user information is contained in Learning, so all purge takes place inside of the Learning Management System (LMS). Native-only configurations are uncommon, so most customers do not follow this process. Most customers use Data Retention Time Management (DRTM) or Data Retention Management (DRM) to enable their purge policy because user information is stored in the suite, not contained to Learning.

● Process Prerequisites for Native-Only Learning User Purge [page 229]● Enabling the SAP SuccessFactors Learning Audit Purge Log [page 236]● Deleting SAP SuccessFactors Learning Users without Data Retention Management [page 238]


Data Purge

● Enabling the Purge Deleted User Audit History Job in Learning [page 243]● Enabling a Partial Purge of User Information for Native-Only Learning Users [page 246]

3.22.1.2 Process Prerequisites for Native-Only Learning User Purge

Most native-only SAP SuccessFactors Learning customers already have a termination and an inactivation process, and also have related users for administrators and instructors as part of their user management process, but check the processes when you set up native-only purge.

Processes that Trigger Purges

Full purge begins when users separate from your organization. The SAP SuccessFactors Learning purge process looks for triggers to begin:

● For internal users, the trigger is their termination date.● For external users, the trigger is their inactivation date.

For most native-only customers, the processes run through a user connector to a Human Resources Information System (HRIS). Administrators who have permission, however, can edit termination dates or to inactivate users can create the triggers outside of the standard process. For example, an administrator with permission can go to

People Users and add a termination date to a particular user. For the purposes of process, however, oneoff changes aren’t typical and we don’t recommend them because this kind of administrator intervention doesn’t scale.

Prerequisite to trigger Learning native-only full data purge

How customers typically meet the prerequisite Why you need the prerequisite

A termination process for employees (internal users)

In most cases, native-only customers add a termination date for their internal users with a user connector from a third-party Human Resources Information System (HRIS).

The end-to-end purge process begins with user deletion. In the native-only configuration, internal users' deletion is triggered by termination dates. When a termination date is older than a threshold, the user is deleted. After users are deleted, the purge process then triggers later stages until ultimately, users' data is purged from the system.


Prerequisite to trigger Learning native-only full data purge

How customers typically meet the prerequisite Why you need the prerequisite

An inactivation process for the extended enterprise users (external users)

In most cases, native-only customers add an inactivation date for their external users with a user connector from a third-party Human Resources Information System (HRIS).

The end-to-end purge process begins with user deletion. In the native-only configuration, external users' deletion is triggered by inactivation dates. When an inactivation date is older than a threshold, the user is deleted. After users are deleted, the purge process then triggers later stages until ultimately, users' data is purged from the system.

User Management Processes Required by Purge

To use purge, your user management process must include related users for instructors and administrators. Missing related users is most common in native-only configurations. You can check for missing related users with the Is Emtpy search in instructors and administrators.

If you have empty related users, correct the issue in your system and your user management process before configuring purge.

Configuring Search Selectors to Find Empty Related Users [page 231]Change search selectors to find empty related users so that you can easily search for the list of administrators and instructors who need related users.

Finding Instructors Without Related Users [page 232]Find instructors without related users to correct non-standard configurations.

Assigning a Related User to Instructors [page 233]Assign related users to instructors so that instructors can log in to the instructor dashboard (My Classes).

Finding Learning Administrators Without Related Users [page 234]Find administrators without related users to correct non-standard configurations.

Assigning a Related User to a Learning Administrator [page 235]Assign related users to administrators to correct user configuration issues.

SAP SuccessFactors Learning Native Deeplink User [page 235]How you set native deeplink controls how Learning recognizes both link redirects and also how it recognizes the user as native or not native.

Enabling the SAP SuccessFactors Learning Audit Purge Log [page 236]Enable the purge log to preserve users' first names, last names, and IDs even after the Purge Deleted User Audit History process runs.


Data Purge

3.22.1.2.1 Configuring Search Selectors to Find Empty Related Users

Change search selectors to find empty related users so that you can easily search for the list of administrators and instructors who need related users.

Context

We strongly recommend that all SAP SuccessFactors Learning administrators and SAP SuccessFactors Learning instructors have related users. Although this is a problem most often in native-only user customers, it might occur also in integrated environments. By configuring search selectors to find empty related users, you can easily find problems to fix.

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go to System Administration ConfigurationSearch Selectors .

2. Find and edit the Instructor search selector and the Admin search selector to add IsEmpty to the related user search field.

3. Look for criteria.Student.criterionUI.uiLabel=label.RelatedUser.

This is the criterion that configures the related user search field.4. At the end of the criteria.Student, look for

criteria.Student.criterionUI.matchOptions.OP_NULL.

5. If criteria.Student.criterionUI.matchOptions.OP_NULL is missing, add it.

For example, this configuration sets up the null option (Is Empty) in the sixth position in the list:

criteria.Student.criterionUI.matchOptions.OP_NULL.enabled=true criteria.Student.criterionUI.matchOptions.OP_NULL.order=6.0criteria.Student.criterionUI.matchOptions.OP_NULL.value=OP_NULLcriteria.Student.criterionUI.matchOptions.OP_NULL.label=label.IsEmpty criteria.Student.criterionUI.matchOptions.OP_NULL.labelValue=null


Next Steps

Go to System Administration Application Administration Administrators to check that Related User has Is Empty in its list.

Go to People Instructors to check that Related User has Is Empty in its list.


Task overview: Process Prerequisites for Native-Only Learning User Purge [page 229]

Related Information

Finding Instructors Without Related Users [page 232]Assigning a Related User to Instructors [page 233]Finding Learning Administrators Without Related Users [page 234]Assigning a Related User to a Learning Administrator [page 235]SAP SuccessFactors Learning Native Deeplink User [page 235]Enabling the SAP SuccessFactors Learning Audit Purge Log [page 236]

3.22.1.2.2 Finding Instructors Without Related Users

Find instructors without related users to correct non-standard configurations.

Context

Native-only customers can create instructors without related users. This was common in early configurations when instructors were tracked as resources and not as a leader of courses. Newer features, however, require related users for instructors.

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go to People Instructors .2. In Related User, select Is Empty.

NoteIf you don’t see Is Empty, add it to the search selector.

3. Click Search.

You see all instructors that lack a related user. These instructor records are at risk for strange behavior in the system.

4. Click Download Search Results to save the results.

The results that you save are the list of instructors to troubleshoot and fix.


Data Purge

Next Steps

Troubleshoot and fix each search result:

● If you’re integrated with platform, then empty related users are a symptom of a problem in the user feed from platform. Check the feed.

● If you’re a native-only customer, then chances are that you created the instructor and then forgot to add the related user. You can simply add the related user to the instructor.


Related Information

Configuring Search Selectors to Find Empty Related Users [page 231]Assigning a Related User to Instructors [page 233]Finding Learning Administrators Without Related Users [page 234]Assigning a Related User to a Learning Administrator [page 235]SAP SuccessFactors Learning Native Deeplink User [page 235]Enabling the SAP SuccessFactors Learning Audit Purge Log [page 236]

3.22.1.2.3 Assigning a Related User to Instructors

Assign related users to instructors so that instructors can log in to the instructor dashboard (My Classes).

Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to People Instructors .2. Find and open the instructor who you want to edit.3. In Summary, add the associated user in Related User.


Related Information

Configuring Search Selectors to Find Empty Related Users [page 231]Finding Instructors Without Related Users [page 232]Finding Learning Administrators Without Related Users [page 234]


Assigning a Related User to a Learning Administrator [page 235]SAP SuccessFactors Learning Native Deeplink User [page 235]Enabling the SAP SuccessFactors Learning Audit Purge Log [page 236]

3.22.1.2.4 Finding Learning Administrators Without Related Users

Find administrators without related users to correct non-standard configurations.

Context

Native-only customers can create administrators without related users. This was common in early configurations when administrators weren’t also learners. Newer features, however, require related users for administrators.

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go to System Administration SecurityAdministrators .

2. In Related User, select Is Empty.

NoteIf you don’t see Is Empty, add it to the search selector.

3. Click Search.

You see all administrators that lack a related user. These administrator records are at risk for strange behavior in the system.

4. Click Download Search Results to save the results.

The results that you save are the list of administrators to troubleshoot and fix.


Related Information

Configuring Search Selectors to Find Empty Related Users [page 231]Finding Instructors Without Related Users [page 232]Assigning a Related User to Instructors [page 233]Assigning a Related User to a Learning Administrator [page 235]


Data Purge

SAP SuccessFactors Learning Native Deeplink User [page 235]Enabling the SAP SuccessFactors Learning Audit Purge Log [page 236]

3.22.1.2.5 Assigning a Related User to a Learning Administrator

Assign related users to administrators to correct user configuration issues.

Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to System Administration SecurityAdministrators .

2. Find and open the administrator who you want to edit.3. In Summary, add the associated user in Related User.4. Choose Apply Changes.


Related Information

Configuring Search Selectors to Find Empty Related Users [page 231]Finding Instructors Without Related Users [page 232]Assigning a Related User to Instructors [page 233]Finding Learning Administrators Without Related Users [page 234]SAP SuccessFactors Learning Native Deeplink User [page 235]Enabling the SAP SuccessFactors Learning Audit Purge Log [page 236]

3.22.1.2.6 SAP SuccessFactors Learning Native Deeplink User

How you set native deeplink controls how Learning recognizes both link redirects and also how it recognizes the user as native or not native.

Depending on how you set Native Deeplink User, you mark the user as either coming in from Human Experience Management (HXM) through the connector or a user who is native to learning. Your user base can be mixed, with some Human Experience Management (HXM) users and some native Learning users.

● If the user is native to Learning and has no record in SAP SuccessFactors platform, set Native Deeplink User to Yes or true.

● If the user is not managed in Learning but is instead is managed in SAP SuccessFactors platform, set Native Deeplink User to No or false.


Native Deeplink Effects on URLs

Stand-alone customers' users are tagged as Native Deeplink users. This tag changes the way that URLs are constructed for the users' deeplinks. If those users later become part of an integrated environment, their URLs continue to be formatted for a stand-alone environment, and so they break in an integrated environment. By enabling the redirect, SAP SuccessFactors redirects them from the stand-alone URL to the integrated URL.

Native Deeplink Effects on Delete Inactive Native Users Automatic Process

The delete native inactive users automatic process deletes users who are not part of SAP SuccessFactors platform. The process uses the value of Native Deeplink as one way to distinguish between platform users and native users. If you set Native Deeplink incorrectly, the process can skip native users who should be deleted and delete platform users who should not be deleted.

Parent topic: Process Prerequisites for Native-Only Learning User Purge [page 229]

Related Information

Configuring Search Selectors to Find Empty Related Users [page 231]Finding Instructors Without Related Users [page 232]Assigning a Related User to Instructors [page 233]Finding Learning Administrators Without Related Users [page 234]Assigning a Related User to a Learning Administrator [page 235]Enabling the SAP SuccessFactors Learning Audit Purge Log [page 236]

3.22.1.2.7 Enabling the SAP SuccessFactors Learning Audit Purge Log

Enable the purge log to preserve users' first names, last names, and IDs even after the Purge Deleted User Audit History process runs.

Context

NoteMost customers don’t enable the purge log.


Data Purge

A few customers have a data privacy and protection policy that requires them to preserve a learning audit trail even after the Purge Deleted User Audit History process runs. The case to log purged users is rare but critical to the business of customers who are audited by an oversight organization.

TipCheck laws, contracts, and guidelines that balance data privacy and protection with audit traceability.

Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to System Administration ConfigurationSystem Configuration .

2. Edit LMS_ADMIN.3. Find enablePurgeLog and set it to true.


Example

For example, some Life Sciences customers in the United States are audited by the Food and Drug Administration (FDA). They must show the FDA that when a learning event occurred (an approval, a completion, and so on) that a particular user was a part of that event (approved it, marked the event complete, and so on). If their data privacy and protection policy purges users before the audit period ends, then they need a way to tie the user to the learning event.

To understand the timing, imagine someone who works at a Life Sciences organization and who approves learning. The company's data privacy and protection requires that most of this person's data must be purged after six months of separation with the company, but carries an exception: for audit purposes, the users' first name, last name, ID, and date of purge can be preserved for auditing purposes. The customer enables the purge log so that SAP SuccessFactors Learning writes the exempted information to a log.

With the log, if the FDA audits the customer nine months after the user separates from the company, the FDA can see enough personal identification to complete the audit without seeing information that is irrelevant to the audit. For example, the FDA can’t see the users' phone numbers, address, and so on, because it was purged and not logged.


Related Information

Configuring Search Selectors to Find Empty Related Users [page 231]Finding Instructors Without Related Users [page 232]Assigning a Related User to Instructors [page 233]


Finding Learning Administrators Without Related Users [page 234]Assigning a Related User to a Learning Administrator [page 235]SAP SuccessFactors Learning Native Deeplink User [page 235]

3.22.1.2.7.1 SAP SuccessFactors Learning Audit Table Purge Log

SAP SuccessFactors Learning can keep a log of users whose personal information is purged from Learning audit tables.

When the Purge Deleted User Audit History process runs and purges user data, SAP SuccessFactors Learning can log the users who were purged from the audit tables. The log includes only the following information of the user who was purged from the history tables:

● User system ID● User student ID● User first and last name● Purge date and time● User type (user, administrator, or instructor)

NoteIn most cases, you don’t want to enable the log because the point of the audit history purge is to remove all user information permanently.

NoteAlthough we store the log in the database, we don’t surface the information in the Graphical User Interface (GUI).

3.22.1.3 Deleting SAP SuccessFactors Learning Users without Data Retention Management

Configure a process to delete SAP SuccessFactors Learning users who are outside the DRM system to set up your data privacy system.

Prerequisites

We recommend that you define a standard process for inactivating users. Most customers set up a user connector that inactivates users, but the reasons for inactivation are unique to the organization. This deletion process begins when user accounts are inactivated.


Data Purge

Context

In most cases, your users are deleted and purged from SAP SuccessFactors Learning transactional tables as part of the Data Retention Management (DRM) tool through Data Retention Time Management (DRTM) processes. Standard data retention runs centrally on SAP SuccessFactors Platform. If you are not integrated with SAP SuccessFactors Platform, then you must run a set of Learning automatic processes to delete and purge users and user data. NativeUserDelete is the template that is sent by the DRM tool.

CautionBe careful with this process if you have user records that populate from SAP SuccessFactors platform. These users are already managed from within the platform and this process can potentially delete these users. User deletion is permanent, and the records cannot be restored.

NoteThis process creates a full delete of learners' data in transaction tables as if DRM ran. DRM is often called full purge. This process does not replace Data Retention Time Management (DRTM) from platform. DTRM is also called partial purge. If you do not have SAP SuccessFactors platform and you want to mimic DTRM, please configure System Administration Automatic Processes Native User Data Retention .

Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to System Administration Automatic Processes Native User Deletion .


TipSchedule the process to run before the Purge Deleted User Audit History process so that the purge process has the most recent set of deleted users.

3. In Delete Criteria, select the records that you want to delete.

This Field... ...Deletes these records

Users You must delete user records as part of this process. User records are in People Users .

Related Instructors You must delete related instructors as part of this process. If a user record is attached to an instructor account, then the instructor account is also deleted. You match instructor accounts to user accounts in the instructor account in Summary. You almost always want to delete instructors when you delete their associated instructor records because you want to manage the data privacy of a person, not an account. If, however, you do not want to delete instructor records when you delete the user account, then remove the association as part of your inactivation process.


This Field... ...Deletes these records

Related Admins If you select Related Admins, and a user record is attached to an administrator account, then the administrator account is also deleted. You match administrator accounts to user accounts in the administrator account in Summary.

Instructors If you select Instructors, then the job looks not only for inactive user accounts but also inactive instructor accounts.

4. To delete external users and instructors, select Delete external users and instructors that have been inactive for the specified number of days, and then type a grace period between the external users and instructors inactivation and deletion.

For example, if you type 90, then to be eligible for deletion, the accounts must be continuously inactive for 90 days. If you activate them again within 90 days, they won't be deleted.

5. To delete internal users, select Delete internal users that have been terminated for the specified number of days, and then type a number of days for a grace period between termination and deletion.

Internal users are deleted when:○ They have a termination date and their termination date is before the threshold (for example, if you set 30

days, the user is terminated 31 days ago or more). Termination date is set on the user record in Terminated.○ They have a shopping account type of Internal. The shopping account type is set in the user record in

Commerce.6. Click Apply Changes.

Next Steps

After you set up the delete process, we recommend that you set up the purge process by going to System Administration Automatic Processes Purge Deleted User Audit History .

3.22.1.3.1 Excluding People from the Learning Native User Data Purge

Exclude people from the Learning native user data purge if you want to make an exception and keep their data past the set retention time.

Prerequisites

Before you can exclude people or their data from purge in SAP SuccessFactors Learning, you must first find all IDs that the person uses. In Learning, one person can have one ID as a learner, a different ID as an instructor, and yet a third ID as an administrator. This supports a more flexible implementation, but it means that you must find all IDs to preserve one person's data. Go to these places to find and record the person's IDs:

● Go to People Users to find the person's ID as a learner.


Data Purge

● Go to People Instructors to find the person's ID as an instructor.

● Go to System Administration Security Administrators .

NoteNot all people have all three kinds of IDs.

Context

The Native User Data Retention process usually purges users' Learning data after the data has expired. You can, however, exempt some users' data from the purge. Check your organizations' data privacy policies for reasons why you should exclude users. For example, you might have legal proceedings or a hold on the information.

Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to System Administration Automatic Processes Native User Data Retention .

2. Check that the process is enabled and look at Purge user data older than the specified retention period to see when you should expect users' data to be purged if they’re absent from the exclusion list.

3. Click Edit Exclusion List.4. In the exclusion list, add each type of ID for the person:

a. Select User in Record Type, add the ID that you found in People Users in Record ID, and then click Add.

b. Select Primary Instructor, add the ID that you found in People Instructors in Record ID, and then click Add.

c. Select Admin, add the ID that you found in System Administration Security Administrator Management in Record ID, and then click Add.

Next Steps

If you add a person to the exclusion list for the data purge, then you probably also want to add the user to the exclusion list for the Purge Deleted User Audit History process.


3.22.1.3.2 The Full Purge Process that Learning Follows for Native-Only Customers

If your SAP SuccessFactors Learning isn’t integrated with SAP SuccessFactors platform, then it follows a different process to fully purge user data. This is uncommon.

1. Users begin in the transactional state: they’re standard users of the system and their audit history and transactional data are stored in SAP SuccessFactors Learning because native-only customers don’t have SAP SuccessFactors platform. internal users' employment. Native-only customers terminate internal users' employment with one of these methods:

2. Individual internal users are terminated and instructors or external users are inactivated so that they move from the transactional stage to the deleted or inactivated stage.○ Termination or inactivation can happen directly on the user record: you can set a termination date in the

users' summary data or you can set them to inactive in their summary data ( People Users ).○ More likely, however, an automated user connector runs from another Human Resources Information

System (HRIS) and automatically adds a termination date or inactivates a user.3. Terminated internal users and inactivated instructors or external users are deleted so that they move from the

inactivated or terminated stage to the deleted stage. Native-only users move to deleted stage through one of these mechanisms:○ Move to deleted stage by the Delete Inactive Native User process: They’ve been inactive or terminated for

longer than the threshold that you designedand so they’re deleted.

○ A learning administrator deletes the user directly in People Users .4. Deleted users are purged completely from the system so that they move from deleted to purged. Unless you

added a user to the exclusion list, the Purge Deleted User Audit History process deletes them completely from the system unless you:○ Configured the purge log to save select information for external audit.○ Added the user to the exclusion list.

3.22.1.3.3 Rules of SAP SuccessFactors Learning Native User Deletion Process

When the SAP SuccessFactors Learning Native User Deletion process runs, it follows a set of implicit rules to delete users. These rules aren’t apparent from the configuration.

Rule Explanation

Administrators that don’t have an associated user account are not deleted by Delete Inactive Native User

Native User Deletion looks for inactivated accounts, but administrators can’t be inactivated. Associated user accounts can be inactivated, however, so the user account acts as the primary account when Delete Inactive Native User runs.

If you have administrator accounts that do not have related user accounts, you must

delete them manually. Go to System Administration Security

Administrators , search for the administrator, open the account, and then click Delete.


Data Purge

Rule Explanation

For any account to be deleted, the account's PERSON_GUID must be null

Native User Deletion is designed to run on native users: users that don’t exist in SAP SuccessFactors platform. Because all users that exist in SAP SuccessFactors platform have Person GUID, then all users without a Person GUID are native users.

We skip platform users because they’re handled by Data Retention Management (DRM), a platform tool.

Accounts must be continuously inactive during the threshold time

Users can be inactivated and activated multiple times. Delete Inactive Native User deletes users who have been continuously inactivated over the time that you set in the delete threshold. For example, if you set the threshold to 90 days, then Delete Inactive Native User deletes users if they’ve been inactive during the entire 90-day period. It skips any users who are active at any time in the last 90 days. If a user is inactive at the beginning of the period, then active, then inactive again, then that user is skipped. If a user is inactive at the beginning of the period and is currently active, then that user is skipped.

Related Instructor records are always deleted

If a user is marked for deletion and that user has a related instructor record, then the instructor record is also deleted. You can’t keep the instructor data and delete the associated user data: they’re both deleted.

The automatic deletion process does not check to see if instructors are scheduled to teach in the future

If you delete an instructor in the SAP SuccessFactors Learning Administration environment, the system checks to see if the instructor is scheduled to teach any classes in the future. The automatic process doesn’t check. It deletes the instructor data regardless of whether person is scheduled to teach classes in the future.

3.22.1.4 Enabling the Purge Deleted User Audit History Job in Learning

Enable the purge deleted user audit history job to periodically purge the audit history of deleted users. The job removes, in an unrecoverable way, all compliance history data about a user.

Prerequisites

Before users can be purged from history tables, they must first be deleted from transactional tables, so you must set up a process to handle transactional tables:

● Most customers are integrated with SAP SuccessFactors platform. If you use SAP SuccessFactors platform, then chances are that you set up Data Retention Time Management (DRTM), both the master data purge and the learning data purge.

● A few customers aren’t integrated with the platform. If you aren’t integrated, then you must set up the Delete Inactive Native Users process. This process acts as DRM for customers who haven’t yet integrated with the platform.

● Any customer can go to a user, instructor, or administrator record and delete the record manually.


Context

NoteIn this context, the word audit and audit history means audit for compliance. It’s the data that shows to compliance auditors, for example, who approved enrollment and on what date.

SAP SuccessFactors Learning uses the Purge Deleted User Audit History process to irrevocably remove data from the PH tables, which are the audit history of SAP SuccessFactors Learning. Deletion is a prerequisite of the purge process, so all user data is already removed from the PA tables (the transactional tables). Deletion, in this case, means any user who has Delete as the final action in the user history table (PH_STUDENT). After you purge a user audit history, you can’t recover any user information.

Procedure



TipIf you aren’t integrated with Platform, schedule the process to run after the Delete Inactive Native Users process or the DRM process so that the purge process has the most recent set of deleted users.

3. In Purge deleted users' audit data after the specified number of days, type a number of days for a grace period between deletion and purge.

For example, if you type 10 in Purge deleted users' audit data after the specified number of days, then the process looks for user deletions that occurred eleven days or more in the past. Users who were deleted within the last ten days aren’t purged. Those ten days are a grace period. You might, for example, run a compliance report weekly and want to include recently deleted users. If your report runs against the PH tables, you still see the compliance data for the users.



Data Purge

3.22.1.4.1 Excluding People from the Learning Audit History Purge

Exclude people from the Learning audit history purge if you want to make an exception and keep their audit history past the set retention time.

Prerequisites






Context

The Purge Deleted User Audit History process usually purges users' Learning audit history after they’ve been deleted for a set amount of time. You can, however, exempt some users' data from the purge. Check your organizations' data privacy policies for reasons why you should exclude users. For example, you might have legal proceedings or a hold on the information.

NoteIn this context, the words audit and audit history mean audit for compliance. It’s the data that shows to compliance auditors, for example, who approved enrollment and on what date.

NoteYou can exclude users from Purge Deleted User Audit History only if they’re already deleted from the transactional tables.

Procedure



2. Check that the process is enabled and look at Purge deleted users' audit data after the specified number of days to see when you should expect users to be deleted if they’re absent from the exclusion list.


a. Select User and then add the ID that you found in People Users , type the ID in Record ID, and then click Add.

b. Select Primary Instructor and then add the ID that you found in People Instructors , type the ID in Record ID, and then click Add.

c. Select Admin and then add the ID that you found in System Administration SecurityAdministratorsi , type the ID in Record ID, and then click Add.

Next Steps

If you add a person to the exclusion list for the audit table purge, then you probably also want to add the user to the exclusion list for the Native User Data Retention process.

3.22.1.5 Enabling a Partial Purge of User Information for Native-Only Learning Users

Configure the Native User Data Retention automatic process to purge SAP SuccessFactors Learning user data when you don’t use SAP SuccessFactors platform Data Retention Time Management (DRTM).

Context

In most cases, your user data is purged from SAP SuccessFactors Learning transactional tables as part of the Data Retention Time Management (DRTM) tool. The DRTM tool runs centrally on SAP SuccessFactors platform. If you aren’t integrated with the central SAP SuccessFactors platform, then you don’t have access to DRTM and need a different way to purge users: the Native User Data Retention process.

Whereas Native User Deletion and Purge Deleted User Audit History work together to completely purge all data about a user who has exited the company, you set up Native User Data Retention to purge old data for users who are still active in your organization. For example, your policy might require the removal of audit data older than two years for current employees. The employees, in this case, don’t have a termination date so you don’t want to purge all data. Instead, you want to keep current data (the users' current address, phone number, and so on) the user, but purge data that is older than two years (an old approval, an old course completion, and so on).


Data Purge

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go to System Administration Automatic Processes Native User Data Retention .


TipYou don’t need to run this process often. We recommend running it weekly.

3. In Purge Criteria, set the criteria for purging users.

Criteria Description

Purge user data older than the specified retention period SAP SuccessFactors Learning looks for native user data older than the threshold. For example, learning history like items completed before the threshold.

Set the time unit to either Years or Months. For example, if you set a threshold of 2 months, and the job runs on January 5, the job deletes user data from before November 5.

Users excluded from purge Click Edit Exclusion List to exclude users from purge. Although the reasons for maintaining an exclusion list depend on your policy, you might exclude users, for example, if you have a legal hold on their data.

User Status You can delete active users, inactive users, or both. Configure this criteria to match your data privacy policies. For example, your policy might require a process of inactivating users before purging them. In that example, you select Not Active.

User Country/Region (select one or more to restrict by country)

Select the countries or regions for which you want to purge users. For example, you might purge users from Argentina but keep user data from Canada.

4. In Data Objects Purged select what should be purged.

Object Description

User Personal Information When selected, this purges information that we store about the user, attributes like name, phone numbers, and so on.

Learning Activity When selected, this purges information that we store about the courses that a user is assigned and the courses that a user completed.



3.22.1.5.1 Excluding People from the Learning Partial Purge

Exclude people from the Learning partial purge if you want to make an exception and keep their data past the set retention time.

Prerequisites






Context

The Native User Data Retention process usually purges users' Learning data, but not the users themselves, after they have been deleted for a set amount of time. You can, however, exempt some data from the purge. Check your organizations' data privacy policies for reasons why you should exclude users. For example, you might have legal proceedings or a hold on the information.

NoteYou can exclude users from Native User Data Retention only if they are already deleted from the transactional tables.

Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to System Administration Automatic Processes Native User Data Retention .

2. Check that the process is enabled and look at Purge user data older than the specified retention period to see when you should expect user data to be purged if they are absent from the exclusion list.



Data Purge

a. Select User and then add the ID that you found in People Users , type the ID in Record ID, and then click Add.

b. Select Instructor and then add the ID that you found in People Instructors , type the ID in Record ID, and then click Add.

c. Select Admin and then add the ID that you found in System Admininstration SecurityAdministrators , type the ID in Record ID, and then click Add.

3.22.2 Purge Process for Integrated Users of Learning Sites (External Users)

Data purge for External Learners isn’t fully supported in SAP SuccessFactors Platform. If you need to purge External Learners, contact Customer Support for other purge options.

How to Know If You Need to Create a Support Ticket

If all of the following criteria are true, then create a Product Support ticket to purge external user data from Learning

● You want to run a full purge of all external users data after a certain date. If you want to run a partial data purge, use the DRTM learning data purge. Purging Inactive Users with DRTM [page 160]

● You have Learning Sites. You can check to see if you have sites by going to Learning Administration. Checking Your System for Learning Sites [page 250]

● You have provisioned Learning with Platform. Configuring Platform Endpoints in Learning [page 250]● You’ve integrated your Learning Sites into SAP SuccessFactors platform so that the external users can gain

access to SAP Jam and SAP SuccessFactors mobile features. Enabling Learning Sites to Send External Users to SAP SuccessFactors [page 252]


Related Information

Native-Only SAP SuccessFactors Learning Customer Configurations [page 227]Purging SAP SuccessFactors Learning Background Jobs Automatically [page 253]Purging SAP SuccessFactors Learning Background Reports Automatically [page 254]Email Notification Archiving in SAP SuccessFactors Learning [page 255]DRTM Data Purge for MDF Custom Objects [page 258]Configuring Retention Period to Purge Import Jobs [page 263]Managing Data Retention Settings for Candidates and Client Administrators in Career Site Builder [page 264]


3.22.2.1 Checking Your System for Learning Sites

Check for Learning Sites if you are unsure whether you use them or not.

Context

Some customers use Learning Sites to offer courses to their extend enterprise. For example, a company with dealerships can offer courses to their dealers' mechanics for repairing their equipment. The mechanics are external users because they are not part of your organization. Learning Sites are uncommon and are different from Learning Marketplace, which uses SAP Hybris to manage the storefront.

Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to System Admin Application AdminSites .

2. Click Search.

If you find any sites, then this purge process might apply to you. If you do not find any sites, then this process does not apply to you.

3.22.2.2 Configuring Platform Endpoints in Learning

Provision SAP SuccessFactors Learning centrally in SAP SuccessFactors so that customers can have access to SAP SuccessFactors Learning from the rest of SAP SuccessFactors.

Prerequisites

You need this information from SAP SuccessFactors:

● The tenant host name for SAP SuccessFactors Learning.● The host URL for SAP SuccessFactors (the URL that users could type in to log in to SAP SuccessFactors).● The company name (the unique ID of the company in SAP SuccessFactors).● Knowledge of the data centers where SAP SuccessFactors exists and where Learning exists. If they are the

same data center, you have less configuration. If they are different data centers, you have additional steps.


Data Purge

Procedure

1. Open a browser and sign in to SAP SuccessFactors as an administrator.2. In Tools, type Learning Administration in the Search Tools box, and then press ENTER .

3. Go to System Admin Configuration System Configuration and edit BizX.4. Set successFactorsCompanyID to the company ID or tenant ID that you received from operations.

In most cases, the tenant ID and the company ID are the same. If the tenant ID of Learning is the same as the company ID, you can alias the value to ${TenantID}.

5. Find the text metadataProviders[, which should find a .type and .value.

For example, you might find something like the following:

Sample Code

metadataProviders[IDP1].type=SuccessFactorsHTTPMetadataProvider metadataProviders[IDP1].value=https://salesdemo4.successfactors.com/idp/samlmetadata?company=

6. In the .value property, type the company name at the end.

For example, if the company ID is ACME, then you type:

Sample Code

metadataProviders[IDP1].value=https://salesdemo4.successfactors.com/idp/samlmetadata?company=ACME

You can have more than one ID provider. The names of ID providers are in the brackets of the property (for example, [IDP1] is the name of one ID provider).

7. Find defaultIDP and set it to one of the ID providers you named in metadataProviders.

For example, if you named an ID provider IDP1, then you have a setting like:

Sample Code

metadataProviders[IDP1].type=SuccessFactorsHTTPMetadataProvider metadataProviders[IDP1].value=https://...

To make that ID provider the default, you set defaultIDP to:

Sample Code

defaultIDP=IDP1



Next Steps

If you have determined that Learning and the rest of SAP SuccessFactors are in different data centers, you must make additional configuration changes.

If you also use SAP Jam, you must connect Learning to SAP Jam.

When you have made any additional configuration changes, enable Learning to connect to the rest of the suite.

3.22.2.3 Enabling Learning Sites to Send External Users to SAP SuccessFactors

Enable Learning sites to send external users to SAP SuccessFactors so that when users from the extended enterprise sign-up through Learning sites, they have access to other SAP SuccessFactors features.

Prerequisites

Integrate SAP SuccessFactors Learning into the suite. If you aren't sure if you’re integrated, go to SAP SuccessFactors Learning and then go to System Administration Configuration System Configuration , and open BizX. Find successFactorsLearningEnabled. If it’s set to true, then you’re integrated.

Additionally, provision the external users capability and set up role mapping between SAP SuccessFactors platform and Learning.

Procedure

1. Go to SAP SuccessFactors Learning and then go to System Administration Configuration System Configuration .

2. Choose edit for BizX.3. Find createIntegratedExternalUser and set it to true.

4. Choose Apply Changes.

Next Steps

Add SAP SuccessFactors Learning sites for your extended enterprise. Each site is a member of your extended enterprise.


Data Purge

3.22.3 Purging SAP SuccessFactors Learning Background Jobs Automatically

Automatically purge SAP SuccessFactors Learning background jobs to keep your application clean of past job data.

Context

Your organization might have a policy that data must be purged on an interval. Check your policy to see if you must purge the data on a specific interval.

NoteThe Clean up Background Jobs process does not affect the schedule of any recurring automatic process, recurring report, or job or report that is scheduled to run on a future date.

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go to System Administration Automatic Processes Purge Past Background Job Results .

2. In Threshold, type the number of days that background job data (recurring background jobs and ad hoc background jobs) is considered for purge.

For example, if you type 30 in Threshold, then we purge any background job data that is older than 30 days when the Clean up Background Jobs process runs.


Next Steps

The job runs periodically to look for background job data that is older than Threshold. Go to System AdminAutomatic Processes Clean up Background Jobs to check the process that runs the purge.

Task overview: Non-Standard Purge Processes [page 226]

Related Information

Native-Only SAP SuccessFactors Learning Customer Configurations [page 227]Purge Process for Integrated Users of Learning Sites (External Users) [page 249]Purging SAP SuccessFactors Learning Background Reports Automatically [page 254]


Email Notification Archiving in SAP SuccessFactors Learning [page 255]DRTM Data Purge for MDF Custom Objects [page 258]Configuring Retention Period to Purge Import Jobs [page 263]Managing Data Retention Settings for Candidates and Client Administrators in Career Site Builder [page 264]

3.22.4 Purging SAP SuccessFactors Learning Background Reports Automatically

Automatically purge SAP SuccessFactors Learning background reports to keep your data clean of past report data.

Context


NoteWhen Learning purges background reports, it retains the report job because we assume that you want new reports, but it purges the old report instance and its data.

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go to System Administration ConfigurationSystem Configuration .

2. Open REPORT_SYSTEM and then find asyncStorageTTLDays.

3. Set asyncStorageTTLDays to the number of days after which background reports should be removed from storage.

For example, if you set asyncStorageTTLDays to 90, then SAP SuccessFactors Learning purges background reports (and the data that was reported) that are older than 90 days.

Next Steps

A job runs periodically to look for reports older than asyncStorageTTLDays. Go to System AdministrationAutomatic Processes Purge Past Background Reports to check the process that runs the purge.



Data Purge

Related Information

Native-Only SAP SuccessFactors Learning Customer Configurations [page 227]Purge Process for Integrated Users of Learning Sites (External Users) [page 249]Purging SAP SuccessFactors Learning Background Jobs Automatically [page 253]Email Notification Archiving in SAP SuccessFactors Learning [page 255]DRTM Data Purge for MDF Custom Objects [page 258]Configuring Retention Period to Purge Import Jobs [page 263]Managing Data Retention Settings for Candidates and Client Administrators in Career Site Builder [page 264]

3.22.5 Email Notification Archiving in SAP SuccessFactors Learning

SAP SuccessFactors Learning offers you choices for archiving email that it sends. Choose an archiving option that matches your company policy.

Email archiving in SAP SuccessFactors Learning is useful for troubleshooting and for traceability. You can see the messages that were sent from the notification system. We understand, however, that archiving policies differ from customer to customer. Some organizations are more strict about archiving personal communication and some are more lenient. We offer you choices to fit your policy.

Check your company policies to learn what they allow and prevent for special archiving of emails sent to users about, for example, their learning activities.

● If your policy prevents any special email archiving, you can configure SAP SuccessFactors Learning so that it does not archive any email notifications except in standard ways. For example, users can archive the messages that they receive.

● If your policy allows email archiving but requires you to stored on your email servers, then choose Blind Carbon Copy (BCC) archiving.

● If your policy allows email archiving and allows it within third parties like SAP SuccessFactors, you can choose to archive within SAP SuccessFactors.


Related Information

Native-Only SAP SuccessFactors Learning Customer Configurations [page 227]Purge Process for Integrated Users of Learning Sites (External Users) [page 249]Purging SAP SuccessFactors Learning Background Jobs Automatically [page 253]Purging SAP SuccessFactors Learning Background Reports Automatically [page 254]DRTM Data Purge for MDF Custom Objects [page 258]Configuring Retention Period to Purge Import Jobs [page 263]Managing Data Retention Settings for Candidates and Client Administrators in Career Site Builder [page 264]


3.22.5.1 Preventing Email Notification Archiving

Prevent email notification archiving if you don’t need the archive for troubleshooting or if your company policy doesn’t allow email archives.

Context





Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to System Administration ConfigurationGlobal Application Settings Mail .

2. Clear Enable Email Archiving.

When you clear Enable Email Archiving, we don’t archive any email messages. So, there are no messages to purge.

3. Choose Apply Changes.

3.22.5.2 Enabling BCC Email Archiving in SAP SuccessFactors Learning

Enable BCC email archiving in SAP SuccessFactors Learning so that Learning to keep a record of the information that you sent to users in email notifications and to keep it on your email servers as opposed to in SAP SuccessFactors Learning.

Prerequisites

You archive mail to an email address that you control. Ask your company Information Technology (IT) team to create an email address for you for the purpose of archiving the email messages that go to users. You can tell your


Data Purge

IT team that it needs standard archiving and limiting rules to delete messages after a period of time and to keep the mailbox below a set size.

Context






Procedure

1. Go to SAP SuccessFactors Learning learning administration and then go to System AdministrationConfiguration Global Application Settings Mail .

2. Select Enable Email Archiving.3. Select BCC Address For Archiving and then type the address that the IT organization gave you in the text box.

3.22.5.3 Enabling Email Archiving Inside SAP SuccessFactors Learning Learning

Automatically purge the SAP SuccessFactors Learning email archive to keep your application clean of past email notifications and data.

Context







Procedure

1. Go to SAP SuccessFactors Learning Administration, and then go to System Administration ConfigurationGlobal Application Settinngs Mail .

2. Select Enable Email Archiving.3. Select Purge Emails older than, and then type a number of months that SAP SuccessFactors Learning retains

email notifications before they are purged.

For example, if you type 2, then we purge any emails from the archive that are older than two months.

Next Steps

Check the batch site of the purge. Go to System Administration Configuration System Configuration and then open LMS_ADMIN. Find emailArchivePurgeBatchCount and make sure that it is set to the default value.

3.22.6 DRTM Data Purge for MDF Custom Objects

MDF supports modules to fulfill their requirements for data purge within data retention management for custom MDF entities.

The purge of MDF custom objects is implemented as reusable plugin in DRTM. It is integrated in the module data purge when the MDF custom object purge object is registered as member of a module purge group. The MDF objects of one or more custom object types which are assigned to the selected purge group will be identified and purged along with other objects in the same purge group when a purge request is created and executed.

This is required for modules that have customer extension objects.

Configuring the custom object purge is a three-step process:

1. Defining a Custom Object as Containing Sensitive Personal Data for a Given Module [page 260].2. Configuring Retention Times for MDF Custom Objects [page 262].3. Purging Specific Types of Data with DRTM [page 163].



Data Purge

Related Information

Native-Only SAP SuccessFactors Learning Customer Configurations [page 227]Purge Process for Integrated Users of Learning Sites (External Users) [page 249]Purging SAP SuccessFactors Learning Background Jobs Automatically [page 253]Purging SAP SuccessFactors Learning Background Reports Automatically [page 254]Email Notification Archiving in SAP SuccessFactors Learning [page 255]Configuring Retention Period to Purge Import Jobs [page 263]Managing Data Retention Settings for Candidates and Client Administrators in Career Site Builder [page 264]

3.22.6.1 Modules That Support DRTM Purge of MDF Custom Objects

.

MDF defines the object type DRTMMDFCustomGOPurgeObject to store the MDF custom object purge configuration. A purge object instance of DRTMMDFCustomGOPurgeObject is required for each MDF custom object type

If an MDF custom object type is enabled for DRTM purge, it must have a string field to store the data subject and a date field used for retention time calculation. The custom object type will be assigned to exactly one purge group which is mapped to a group purge object type including a set of member purge object types in DRTM configuration. A date field is specified as DRTM date field. The retention time is calculated based on the configured DRTM date field.

Purge Request Type, Module Name, and Functional Area that Support MDF Custom Objects

Purge Request Type Module Name Functional Area

DRTM Continuous Performance Purge Continuous Performance Management Continuous Performance

DRTM Continuous Performance Purge Continuous Performance Management Continuous Feedback

DRTM Reward and Recognition Reward and Recognition Spot Awards

DRTM Employment Information Employee Central Employment Information

DRTM Time Management Employee Central Time Management

DRTM Benefits Management Employee Central Global Benefits

DRTM Mentoring Program Career Development Planning Mentoring


3.22.6.2 Defining a Custom Object as Containing Sensitive Personal Data for a Given Module

Mark an MDF custom object as Legislatively Sensitive Personal Data and associate it with a given SAP SuccessFactors module so that the custom object can be purged as part of that module's DRTM purge request.

Context

The Metadata Framework has defined a Legislatively Sensitive Personal Data configuration called LSPDConfig, which indicates that an object contains personal data with respect to legislation.

You can define this configuration for a parent object and open this configuration to edit the legislationspecific child object. If you are defining LSPD configuration for custom object types, Data Subject Field must be a User field. For delivered objects, the configurations can be reviewed using the LSPDconfig. It may or may not be possible for you to change this configuration as it completely depends on how the delivered object is configured. For example, whether the settings are final or not.

Procedure

1. Go to Admin Center Configure Object Definitions .2. Create a new custom object or select the custom object that is already available for which you want to

configure LSPD. For example, cust_go1.3. Ensure that the Object has External Code or any other field at Parent level as User.4. Select Legislative Sensitive Data Configuration from the Create New dropdown. The Legislatively Sensitive Data

Configuration page is displayed.5. Provide the Object Type by either entering the object type in the text box or selecting the object type from the

dropdown.6. Select the value for Data Subject Field. This is the field name with User data type as mentioned earlier.

NoteIf the specified Data Subject Field of type User in the LSDP configuration is changed and there are records for this MDF entity, an error message is displayed.

7. Now for the Data Protection and Privacy Configuration, enter the Module Name and Functional Area. For example, "Employee Central" and "Time Management" respectively.

8. Select the context field name for the already selected Object Type and save your changes.

NoteYou can configure a maximum of five context fields.


Data Purge

3.22.6.2.1 Configuring Legislatively Sensitive Personal Data Using Extension Center

You can associate the MDF custom object that is marked as Legislatively Sensitive Personal Data (LSPD) with a given SAP SuccessFactors module so that the custom object can be purged as part of that module's DRTM purge request.

Prerequisites

● Enable Metadata Framework.● Enable Extension Center.

Context

It is possible to configure the LSPD using Extension Center. This alternative approach serves the same purpose as configuring LSPD using Configure Object Definition page.

Procedure

1. Go to Admin Center Extension Center .2. Click any existing Extension and then create a new customer object or select the existing custom objects for

which you want to configure LSPD. For example, cust_go1.

The Object Details page is displayed.

Ensure that the object has User type field at Parent level. For example, cust_subjectUserfId.3. Click DPP tab from the left navigation pane.

The Data Protection and Privacy Configuration page is displayed.4. In the Data Subject Configuration section, select the value for Data Subject Field. This is the field name with

User data type as mentioned earlier. For example, cust_subjectUserfId.5. In the Read Access and Change Log Configuration section, select the Module Name and then select the

Function Area. For example, Employee Central and Time Management respectively.6. Click Add for Context Fields and select the context field for the object. For example, cust_contextfId7. Click Save.


Results

LSPD Configuration for Employee Central

3.22.6.3 Configuring Retention Times for MDF Custom Objects

Configure the retention time for an MDF custom object that has been marked as sensitive with an LSPD configuration.

Prerequisites

You’ve created the LSPD configuration for a specific module and functional area.

Procedure

1. Go to Admin Center Manage Data .2. Search and select the DRTM MDF Custom Purge Objects.3. Search for the Custom Object Type that you created while configuring LSPD.

NoteThe Custom Object Type dropdown displays only the objects that are enabled for LSPD. The custom object type with effective dating type FROM_PARENT isn’t displayed.

4. Enter effectiveStartDate for Date Field of Retention Time.Here, effectiveStartDate is an example. This can be any other date field that belongs to the custom object being configured.


Data Purge

NoteThe Date Field of Retention Time dropdown displays the custom and system defined date fields for the selected objects. Also, the field being added here is used as the base date for retention time calculation for active users. For inactive users, the base date for retention time calculation is always the termination date.

5. For each country or region, add the retention time unit and the retention time period, for active and inactive employees.

NoteYou can configure retention time for more than 1 country or region.

6. Save the changes.

The Purge Group field gets updated per the selection of functional area defined in LSPD config.

Next Steps

The purge group should match the Functional Area of the LSPD configuration.

3.22.7 Configuring Retention Period to Purge Import Jobs

The system automatically purges all the completed import jobs listed on the Monitor Job page depending on the retention period.

Prerequisites

Ensure that the Bizx Daily Rules Processing Batch job is created in Provisioning. You'll need to contact our Product Support to complete this task.

Procedure

1. Go to the Admin Center.2. In the Tools Search field, type Company System and Logo Setting.3. On the Company Logo page, in the Scheduled Jobs Retention Period in days field, enter the number of days by

when you'd want to purge the import jobs.

By default, it is set to 180 days.4. Click Save Company System Setting.



Related Information

Native-Only SAP SuccessFactors Learning Customer Configurations [page 227]Purge Process for Integrated Users of Learning Sites (External Users) [page 249]Purging SAP SuccessFactors Learning Background Jobs Automatically [page 253]Purging SAP SuccessFactors Learning Background Reports Automatically [page 254]Email Notification Archiving in SAP SuccessFactors Learning [page 255]DRTM Data Purge for MDF Custom Objects [page 258]Managing Data Retention Settings for Candidates and Client Administrators in Career Site Builder [page 264]Important Notes About Data Purge and Data Retention Time Management [page 92]

3.22.8 Managing Data Retention Settings for Candidates and Client Administrators in Career Site Builder

Context

NoteCreate Data Privacy Consent Statements using standard SAP SuccessFactors solutions for Recruiting. The

Career Site Builder Settings Data Privacy Consent Statements option is available only if your Career Site Builder is not integrated with SAP SuccessFactors Recruiting.

Procedure

1. In the Career Site Builder, choose Tools Data Privacy & Security Settings .2. In the tab Data Protection in Data Retention Management: slide the switch for Candidates/Client Admin to On

and use the sliders to set the activity threshold in days for anonymization of candidate and client admin data.

Once the threshold is set, user data is anonymized if there hasn't been any user activity in the specified number of days. You can configure separate thresholds for candidates (Talent Community Members) and client admins (users with an account in the Recruiting Dashboard).



Data Purge

Related Information

Native-Only SAP SuccessFactors Learning Customer Configurations [page 227]Purge Process for Integrated Users of Learning Sites (External Users) [page 249]Purging SAP SuccessFactors Learning Background Jobs Automatically [page 253]Purging SAP SuccessFactors Learning Background Reports Automatically [page 254]Email Notification Archiving in SAP SuccessFactors Learning [page 255]DRTM Data Purge for MDF Custom Objects [page 258]Configuring Retention Period to Purge Import Jobs [page 263]


4 Data Blocking

Learn about how you can block access to historical personal data based on a user's role-based permissions.

As a general principle, historical personal data should not be stored any longer than is absolutely necessary. Once the legally required retention time for personal data has passed, it should be purged.

However, sometimes personal data is required to be stored by different users for different lengths of time. For example, the HR department might be required to store an employee’s home address for 3 years, but the Payroll department might have to store it for 5 years. In a situation like this, the employee’s address can only be purged after 5 years, but that means that certain users (in this case, the HR department) retain unnecessary access to it even after their legally required retention time has passed.

To solve this problem, SAP SuccessFactors provides a data blocking function. This enables you to control exactly how long individual roles will be able to access historical personal data, based on their role-based permissions. Using the example above, you can specify that HR admins can only access the employee’s address for 3 years, but Payroll can continue to access it until the full 5 years are up. In this way, data can be safely stored for the full legally required retention time, but at no point will it be available to anyone who shouldn’t have access to it.

Getting Started with Data Blocking [page 267]Before you set up and use Data Blocking, there are some general prerequisites you need to complete.

Important Notes About Data Blocking [page 267]Before you start using the Data Blocking function, understand the following important notes and how they impact your SAP SuccessFactors system.

Setting Up Data Blocking for Effective Dated Objects (EC Objects) [page 270]Configure the roles that will not have full access to historical data for effective dated objects.

Setting Up Data Blocking for MDF Objects [page 270]Configure the roles that don't have full access to historical data for MDF objects.

Related Information

Process for Setting Up Data Retention Time Management (DRTM) [page 112]Getting Started with Data Purge [page 15]Getting Started with Data Blocking [page 267]Setting Up Data Blocking for Effective Dated Objects (EC Objects) [page 270]


Data Blocking

4.1 Getting Started with Data Blocking

Before you set up and use Data Blocking, there are some general prerequisites you need to complete.

Procedure

1. Familiarize yourself with your local data protection and privacy laws.2. Go through this checklist and determine the current status of each item for your company:

Check Item Action

Have you adopted the SAP SuccessFactors Platform? If you haven’t adopted the Platform yet, please get in touch with your SAP contact and ask them to start the process. Note that adopting Platform takes time, so we recommend you start as soon as possible.

Have you activated the Metadata Framework (MDF)? In your SAP SuccessFactors system, go to the Upgrade Center and switch on the Extension Center. This activates MDF automatically.

Important notes and limitations Important Notes About Data Blocking [page 267]

3. Start setting up the data blocking function in your SAP SuccessFactors systems.

4.2 Important Notes About Data Blocking

Before you start using the Data Blocking function, understand the following important notes and how they impact your SAP SuccessFactors system.

Module Limitation

Employee Central For HRIS workflows and MDF workflows, data blocking is available only for completed workflows: workflows that have the status Approved, Rejected, or Cancelled. You need to assign the correct permissions to users so they can see these completed workflows:

When using Time Account Purchase, turn off the Admin access to MDF OData API permission in the Metadata Framework category. Turning off this role based permission (RBP) is necessary for blocking the view data on the Leave Purchase UI.

Setting Up and Using Data Protection and PrivacyData Blocking PUBLIC 267

Module Limitation

Reporting The following classic reporting tools do not support data blocking:

● List views● Spotlight views● Detailed document search● Dashboards 1.0● Spreadsheet reports (also known as RDF reports)

NoteTo increase compliance with data protection and privacy laws, we strongly recommend that you disable all classic reporting tools and replace them with Table reports and Canvas Reports.

At least ensure that no sensitive fields appear in the classic reporting tools.

Reporting Table reports and Advanced Reporting both support data blocking. Please note, however, that in Table reports data blocking applies only to Employee Central sub-domain schemas. In Advanced Reporting, data blocking applies to all objects.

Reporting Data blocking does not apply to Table reports that use Group By function.

Setting Up a Simple Data Blocking View Role [page 269]Set up a simple data blocking view role so that, when you use data blocking, users in the role can see the completed workflows.


Data Blocking

4.2.1 Setting Up a Simple Data Blocking View Role

Set up a simple data blocking view role so that, when you use data blocking, users in the role can see the completed workflows.

Context

For HRIS workflows and MDF workflows, data blocking is available only for completed workflows: workflows that have the status Approved, Rejected, or Cancelled. You need to assign the correct permissions to users so they can see these completed workflows:

CautionThis task tells you how to set up a simple role so that you understand how to set up a data blocking view role. Your Role Based Permission (RBP) system is likely more complicated, so you should think through your RBP strategy for data blocking.

Procedure

1. Create a data purge role in role-based permissions.

For example, type View Completed Workflows in the Role Name field.

2. Enable the permission Platform Feature Setting Add Permission: View Completed Workflows .

3. Assign the View Completed Workflows permission in Permissions Administrator Permissions Manage Workflows .

TipYou can restrict the access for a period of time.

Task overview: Important Notes About Data Blocking [page 267]


4.3 Setting Up Data Blocking for Effective Dated Objects (EC Objects)

Configure the roles that will not have full access to historical data for effective dated objects.

Procedure

1. In the Admin Center under Manage Permission Roles, go to Permission Role Detail.

2. Select a role (for example, HR admin) and go to Permission Settings Employee Central Effective Dated Entities .

You see all the fields for effective dated entities.3. Select the View History checkbox on object level (for example, Personal Information Actions) and choose Done.4. Assign the role to a group of employees, and specify the target group that they’re authorized to access. For

example, an HR admin based in the US should have a target group of US employees only.5. Under Data Access Period Settings, choose Restricted, and enter the number of months for which the role will

have access.

○ The system always uses the current date to calculate the authorization period, so if you enter “12” the role will have access for 12 months from today.

○ If you enter "0", the role will have no historical access at all. That is, the role will not be able to see anything older than today.

○ The system always uses the time zone of the signed-in user to calculate the period.6. Choose Done.

Results

Data blocking is immediately activated for that role.

4.4 Setting Up Data Blocking for MDF Objects

Configure the roles that don't have full access to historical data for MDF objects.

Prerequisites

You can only configure data blocking for object definitions that meet one of the following criteria:


Data Blocking

● The data type of the external code is User.● The RBP Subject User Field isn't blank.

Procedure

1. Go to Admin Center Configure Object Definitions .2. Open and edit the target object definition.

3. Choose a Date field that you want to use to determine the blocking period. Enter its name in Security Base Date Field For Blocking .

For a Spot Bonus, choose whether it should be the date on which the award was awarded, or the date the manager added it to the system, or the Payroll date, and so on.

○ Whichever reference field you choose, make sure it’s a mandatory field. Otherwise, there’s a chance someone might leave it blank and then the system will be unable to calculate the authorization period.

○ The system always uses the time zone of the individual user to calculate the period.

4. Open and edit the permission role in Admin Center Manage Permission Roles Permission Role Detail .5. Choose the permissioin groups or users in the third section Grant this role to... and select Edit Granting.6. Choose Restricted for the target object definition and enter the number of months for which the role will have

access in the fourth section Data Access Period Settings.

NoteCertain MDF objects such as Time Account, contain the following data access period settings: Full, Restricted, and More Restrictions

○ The system always uses the current date to calculate the authorization period, so if you enter “12” the role will have access for 12 months from today.

○ If you enter "0", the role will have no historical access at all. That is, the role will be able to see nothing older than today.

○ If you leave it blank, access is unlimited. That is, the role will be able to access the personal data until the moment it's purged.

7. Choose Done and save your changes.

Results

Data blocking is immediately activated for the MDF object.


5 Change Audit

Change auditing capabilities enable you to track changes that have been made to different kinds of data in your system. You can audit changes to personal data, system configuration, or other business data.

If you enable change auditing in your system, we capture information about changes to the system in our audit logs. Then you can generate change audit reports, based on the data in our audit logs, as required by your business. Generated audit reports are available for download for 48 hours and then purged from storage.

Change audit reports tell you which data records were changed during a given period, what the change was, who changed them, and when. Changes are captured in logs whether they're made in the user interface, via API, or with an import file. Reports are available for many types of data, including personal data, configuration data, and other types of data in the HXM Suite. Use the self-service audit reporting tool to create the most common reports directly from the Admin Center.

Changes to Personal Data

Personal data is subject to frequent changes. Use change audit reports to keep track of changes to an employee’s personal data and comply with your organization's data protection and privacy policy.

You can create change audit reports to track changes to personal data across the SAP SuccessFactors HXM Suite, including:

● Changes made about a specific user’s personal data (changes made by anyone to John’s personal data)● Changes made by a specific user to other people's personal data (changes made by John to anyone else's

personal data)

NoteChange audit includes all changes to personal data fields, including insertions, updates, or deletions.

Changes to Other Data

Your SAP SuccessFactors system contains more than just personal data. It includes other types of data, such as configuration data or transactional business data. Use change audit reports to keep track of changes to your system, build proper internal controls, and ensure data security.

You can create change audit reports on wide range of data types from across the SAP SuccessFactors HXM Suite, including:

● Role-based permissions● Proxy assignments● Basic and extended user information● Feature settings


Change Audit

Related Information

Getting Started with Change Audit for Personal Data [page 273]Enabling Change Audit [page 281]

5.1 Getting Started with Change Audit for Personal Data

Before you set up and use the Change Audit function for personal data, for the purpose of data protection and privacy, there are some general prerequisites you need to complete.

Procedure


Check Item Action

Have you adopted the SAP SuccessFactors platform? If you haven’t adopted the Platform yet, please get in touch with your SAP contact and ask them to start the process. Note that adopting Platform takes time, so we recommend you start as soon as possible.


Important notes and limitations Important Notes About Change Audit for Personal Data [page 274]

3. Start setting up the Change Audit function in your SAP SuccessFactors systems.

Setting Up and Using Data Protection and PrivacyChange Audit PUBLIC 273

5.2 Important Notes About Change Audit for Personal Data

Before you start Change Audit to audit changes to personal data, understand the following important notes and how they impact your SAP SuccessFactors system.

Important Notes About Change Audit for Personal Data

Solutions Affected Notes and Limitations

Platform Audit reports cover a maximum time range of seven days. If you want to audit a longer period of time, create multiple reports. For example, if you want to audit data for a full month, run four separate reports of seven days each.

Platform Audit reports are created by scheduled jobs. You’ll be notified by email once the report is ready to view.

Platform There is a total storage limit of 1 GB for reports. On the Access Reports tab, you can see the size of each report and how close you are to reaching the overall storage limit.

Platform To be included in change audit reports, attachments in Document Management need to be associated with the data subject user, not the uploader. If this association hasn't been set up, change audit data may be inaccurate or incomplete.

In "changed by" reports, Document Management data shows as "no owner" (none in column) or as "shared" (has multiple owners). In "changed on" reports, Document Management data isn’t shown.

Platform If you use change audit reports for data protection and privacy, do not use the Attachment API to delete documents. Due to a known issue, using this API to delete documents can lead to inaccurate change audit data.

Platform Changing user IDs may impact audit reporting. Caution About User ID Conversion [page 14]

Platform To include changes to an MDF object in change audit reports, make sure that the MDF Version History setting is set to either Delete History or Complete History.

Calibration The change audit scope for Calibration doesn’t include ratings from data sources other than Employee Profile. You can get ratings of other data sources from other modules.

Development Changes to competencies that are linked to goals on the Development Plan are not logged.

Development Change logs are not generated when changes are made to the custom fields of the development goal plan.


Change Audit


Employee Profile Changes to personalized media content on the employee profile (About Me video and My Name audio) aren’t included in change audit reports.

SAP Identity Authentication If you use SAP Cloud Platform Identity Authentication, be sure to review the latest documentation to ensure that it meets your data protection and privacy requirements. For more information, see here.

Platform The Metadata Framework (MDF) CLOB data type isn’t supported for Change Audit.

Performance and Goals In Performance Management, you can only generate change logs for Performance Management v12 Acceleration forms.

Performance and Goals In Performance Management and 360 Degree Multirater, change logs only support up to 4,000 characters for text-area fields. If you’ve configured a text-area field to have a maximum character count to be greater than 4,000, you can only report on the first 4,000 characters entered.

In Performance Management, when a change log is generated for the "Ask for Feedback" response only the first 4,000 characters of the response is reported. The excess characters in the "Ask for Feedback" response are truncated and aren’t considered while generating the change log.

Performance and Goals In Performance Management, in the Collaborative step, change logs are generated for all the changes made by the users involved in this step, only after the exit user routes the form to the next step. When an exit user isn’t defined, the changes made to the form by the users involved in the Collaborative step are saved to the form, but the change log is generated only when the form is routed.

Let’s us consider the following scenario:

● User A(Exit User) User B(Non-Exit User): Both users A and B can make the changes, but only User A can finalize the changes and route the form

● User A(Exit User) User B(Exit User): Both users A and B can finalize the changes and route the form

● User A(Non-Exit User) User B(Non-Exit User): In this case, both users A and B can finalize the changes but the form isn’t routed until both the users finalize the form. Change logs are generated for both the users when any of them clicks the finalize button.

The change log is generated against the V4Admin user when the exit user isn’t defined in the C-step.




Performance and Goals In Performance Management and 360 Degree Multirater, in the Iterative step, change logs are generated for all the changes made by the users involved in this step, but the change log is generated only when the form is routed to the next step.

Performance and Goals In Performance Management and 360 Degree Multirater, during document transfer, when the form gets transferred to the new manager, change logs get generated to capture this routing event, but the ratings and the comments provided by the old manager don’t get captured as it’s saved in the draft version of the form and get deleted once the form is routed to the new manager's inbox.

Performance and Goals In Performance Management, change logs are generated only when a form is routed. Therefore, the audit report captures only the final change made to the form before routing the form to the next step. When a manager makes changes to the form in the OOTA step, the changes made to the form are saved to the form, but the change log is generated only when the form is routed outside the OOTA step. Any changes made to the form before making the final changes are lost and these changes are not captured in the change logs.

Performance and Goals In Performance Management, change logs are not generated when changes are made to the Custom Fields and Custom Sections of the Performance Management form.

Performance and Goals In 360 Degree Multirater, change logs are not generated when changes are made to the Custom Fields and Custom Sections of the 360 Review form.

Performance and Goals In Goals Management, change logs are not generated when changes are made to the custom fields of the Goal Management plan.

Performance and Goals In Performance Management:

● When the step owner fails to take the required action on the Performance Management form on time, the form gets auto routed. However, the change log generated displays the step owner's name against the routing event.

● When mass routing of forms happens on behalf of another Admin, the proxy user ID column on the change log report appears blank.

● When more than 20 forms get routed it gets executed as a job and the change log gets generated against the system admin, also known as the V4Admin.


Change Audit


Performance and Goals In 360 Degree Multirater:

● When mass routing of forms happens on behalf of another Admin, the proxy user ID column on the change log report appears blank.

● When more than 20 forms get routed it gets executed as a job and the change log gets generated against the system admin, also known as the V4Admin.

Performance and Goals In Performance Management:

● • For "scale adjusted calculation" in Summary section and Objective-Competency Summary section, change logs do not show the "scale adjusted rating" descriptions, instead it only shows the "scale adjusted calculation" rating.In the Summary section, the "Overall summary rating" displays both the rating and the rating description in the change log. For example, a rating of 4.0 displays the rating description as "Exceeds Expectations". But the "Unadjusted calculated overall rating" and the "Adjusted calculated overall rating" display only the adjusted rating, which is 3.6 and not the rating description.Similarly, in the Objective-Competency Summary section, "Overall competency rating" and "Overall objective rating" display both the rating and the rating description in the change log. For example, a rating of 4.0 displays the rating description as "Exceeds Expectations". But the "Objective-Competency summary rating", "Calculated competency rating", "Calculated objective rating", "Adjusted calculated competency rating", and "Adjusted calculated objective rating" display only the adjusted rating, which is 3.6 and not the rating description.

● Irrespective of the Rating Options, both the self-rating and the shared rating are recorded in the change log.

● Change logs do not record the difference between the default rating that comes from the Metric Lookup Table and the newly updated rating. It only records the newly updated rating as a new entry.

Performance and Goals In 360 Degree Multirater:

● For "scale adjusted calculation" change logs, the "scale adjusted rating" descriptions are not shown. Instead, it shows the "scale adjusted calculation" rating. For example, a rating of 4 is shown as the "scale adjusted calculation", instead of the description "Exceeds Expectations”.

● Irrespective of the Rating Options, the official rating is recorded in the change log.



Performance and Goals In Performance Management, change logs aren’t generated for the “Recall feedback” routing action.

Performance and Goals In Performance Management, while not a limitation, it’s good to know that change logs are generated while sending out Get Feedback requests, and also while routing the form back to the step owner.

Performance and Goals External users in Performance Management aren’t created as platform users in the system and they don’t have a User Id. External users are identified by their full name and e-mail address.

While not a limitation, it’s good to know that you can search for external users in Performance Management, and generate a “Changed By” report for all the changes made by the external users, by choosing External User Search on the Create Data

Privacy Reports tab in Admin Center Change Audit

Reports .

NoteThe necessary filters for module and functional area are preselected as the external user search applies to only Performance Management.

Performance and Goals In Performance Management, while not a limitation, it’s is good to know that change logs are generated when the form gets routed to the next step in the route map, when ratings and comments are updated during a routing event, when an attachment is uploaded or deleted from the form, and when Ask for Feedback responses are received from the managers as well as from the external users. It also generated to track personal data changes made by an external user.

Performance and Goals In 360 Degree Multi-rater, while not a limitation, it’s good to know that change logs are generated when the form gets routed to the next step in the route map, when ratings and comments are updated during a routing event, and feedback is received from the raters. It’s also generated to track personal data changes made by an external rater.

Performance and Goals In Performance Management and 360 Degree Multi-rater, while not a limitation, it’s good to know that, after the reports are generated, the report entry stays for a duration of ~30 days. However, data collected in the central reporting table is purged after 48 hours. So, the report has to be resubmitted if you haven’t downloaded it previously.


Change Audit


Performance and Goals In Performance Management and 360 Degree Multi-rater, while not a limitation, it’s good to know that you don’t need to schedule it. We configure a global job for each Data Center, which runs on daily basis. The global job kicks off a company job for each company, when audit switch is enabled, to extract data on daily basis. The extraction job moves the data from shadow tables (SQL storage - Oracle/HANA) to NoSQL storage.

Performance and Goals The latest version of Continuous Feedback supports change audit reports.

Recruiting Following are some of the limitations for Recruiting Management:

● Changes related to Interview Scheduling aren’t logged.● Changes related to correspondence aren’t logged.● Changes related to integration on assessment and back

ground checks aren’t logged.● For Candidate Profile MDF extension objects, only the

changes related to data of primary candidate ID are logged.

NoteThe secondary login, that is, Provisioner ID and Provisioner E-mail is included.

Succession Change audit scope for succession planning data includes both internal (person search) and external (external candidate search) successors.

Compensation and Variable Pay For Compensation, Variable Pay and Total Compensation Plan, the Change Audit report includes both standard Compensation fields, such as comments, performance ratings, and salary information, and custom Compensation fields that are modified or deleted in the worksheets. Note that only the custom fields that are configured as Reportable are audited. Additionally, the system generates all the audit data in the report when a new worksheet is launched.

Onboarding 1.0 To search for changes to personal data in change audit, use Onboardee Search to specify the new hire.



Onboarding Changes to new hire data during the onboarding process are captured by fields belonging to Employee Central and MDF objects.

NoteFor Change Audit report generation, you can search new hire records through the Person Search widget in the

Admin Center Change Audit Reports Create

Personal Data Report tool.

Permissions and creation of report is covered as part of centralized Data Privacy and content.

To search for changes to personal data in change audit, use Person Search to specify the new hire.

Performance and Goals In Performance Management, change logs are generated when changes are made to the Customized Weighted Rating section in the Performance Management form.

5.2.1 Change Audit Reporting on Shared Users

To track changes made via a shared user account, we only allow one person at a time to access the account with secondary login and we include the Provisioning user's email address in the audit report.

SAP SuccessFactors allows you to set up shared users that can be accessed by multiple people for certain purposes, such as system maintenance or troubleshooting. For example, the sfadmin user is typically shared by multiple Product Support representatives and accessed using the secondary login feature in Provisioning. We ensure that only one person at a time can log on to a shared user account using secondary login. For data protection and privacy, you can create audit reports that list all personal data that was accessed by a shared user account and the email address of the person that was logged on to the account at the time.


Change Audit

5.3 Enabling Change Audit

Enable change audit logging so that authorized users can create audit reports tracking changes to different types of data.

Prerequisites

You have both View Read and Change Audit Configuration and Edit Read and Change Audit Configuration permission.

Context

NoteThis task is only necessary to enable change audit for the following solutions: Compensation (except Rewards and Recognition), Performance & Goals (except Continuous Performance Management), Succession & Development (except Mentoring), Employee Profile, User Management, Proxy Management, and Role-Based Permissions.

For other SAP SuccessFactors solutions, change audit reporting does not require this task because change audit is always enabled. These solutions include: Employee Central, Onboarding, Recruiting, Mentoring, Rewards and Recognition, and Continuous Performance Management.

Procedure

1. Go to Admin Center Manage Audit Configuration .2. On the Change Audit tab, switch on the Change Audit option.

The Personal Data Audit option is switched on by default.3. Switch the following options on or off, based on your audit requirements.

Setting Description

Personal Data Audit Enable this option for data protection and privacy so that you can create change audit reports on personal data.

General Audit Enable this option for other audit purposes, so that you can create change audit reports for other types of data, such as configuration settings or user management.

4. Choose Save.

You get a message telling you that the activation process has started. It usually takes about 24 hours.


5. Confirm that the activation process has completed successfully.

○ Come back later to the Manage Audit Configuration page to verify that the toggle switch is enabled. If so, it means that the process is complete— but it doesn't guarantee the process was successful.

○ Wait for an email notification to confirm if the process was successful or not. If it fails for some reason, follow instructions in the email to contact us for help.

Results

Change audit logging is enabled for the following solutions: Compensation (except Rewards and Recognition), Performance & Goals (except Continuous Performance Management), Succession & Development (except Mentoring), Employee Profile, User Management, Proxy Management, and Role-Based Permissions.

Next Steps

Give the Generate Change Audit Reports permission to the appropriate roles.

If you’re using Career Site Builder, you may need to take additional steps.



Related Information

Creating a Change Audit Report for Career Site Builder [page 299]

5.4 Process for Generating Change Audit Reports

Use change audit reports to track changes in your system.

A wide variety of change audit reports are available, for different audit processes. For example, you can create change audit reports on changes to someone's personal data or a change audit report on changes to feature setting configuration.

Here's an overview of the process:

1. Create the type of change audit report you need.2. Wait for the report to be generated. You’re notified by email when the report is complete.


Change Audit

NoteChange Audit data generated in the first day is only available after 8 am the next day in UTC. Depending on the time when the Change Audit data is generated, it’s only available in 8 to 32 hours.

3. Download and save the report within 48 hours. After 48 hours, completed reports are purged from storage.4. Interpret audit data in the report to understand the changes made in your system.

Creating a Change Audit Report [page 283]Create a change audit report to track changes in your system, such as changes to personal data or configuration settings.

Downloading a Change Audit Report [page 289]Download and save your Change Audit report when is available so that you can investigate changes made in your system.

Interpreting a Change Audit Report [page 290]Learn how to read and interpret the data in a change audit report so that you can understand specific changes made to your system.

Viewing or Deleting Recurrence Schedules for Change Audit Reports [page 292]View a list of recurrence schedules, delete ones that are no longer needed, and check the status of completed recurring reports.

Standard Data Included in All Change Audit Reports [page 292]Learn about the standard data that is typically included in all change audit reports.

5.4.1 Creating a Change Audit Report

Create a change audit report to track changes in your system, such as changes to personal data or configuration settings.

Prerequisites

● You've enabled the change audit function and the acctivation process has completed successfully.● You have the Generate Change Audit Reports permission. Data Privacy Officers should have this permission.● If you plan to set up a recurrence schedule that saves reports to SFTP, be sure that you have the technical

details required to set up the connection. If you plan to use file encryption, be sure that you’ve already imported your PGP public key on the PGP Key Management page.

Context

You can use this procedure to audit changes to most types of data, but not Compensation configuration data. Compensation audit reports are generated and exported using a different procedure on the Compensation Plan Activity Audit page.


NoteChange Audit data generated in the first day is only available after 8 am the next day in UTC. Depending on the time when the Change Audit data is generated, it’s only available in 8 to 32 hours.

Procedure

1. Go to Admin Center Change Audit Reports .2. Select the appropriate tab, based on your audit requirements.

○ Select Create Personal Data Report to create an audit report on changes to personal data across the HXM Suite, for data protection and privacy.

○ Select Create Configuration Data Report to create an audit report on changes to configuration of your system.

○ Select Create Business Data Report to create an audit report on other types of changes.3. Select the type of report you want to create.

A dialog opens where you can configure the report settings.4. For a personal data report, specify the person you want to report on.

○ To see changes to personal data about a specified employee, select Change On Subject User and use the Person search to specify the employee.

○ To see changes to personal data made by a specified employee, select Change By User and use the Person search to choose the employee.

○ To see changes to personal data about an external candidate, use the External Candidate search to specify the candidate.

○ To see changes to personal data about a new hire who is still in the onboarding process, for Onboarding 1.0 use the Onboardee search to specify the new hire.

○ To see changes to personal data about a new hire who is still in the onboarding process, for Onboarding use the Person search to specify the new hire.

○ To see changes to personal data about an external rater in Performance Management, use the External User search to specify the external rater.

5. For a personal data report, select the modules and functional areas you want to include in the search.

NoteTo optimize system performance, limit your search to only the required data. The more modules you choose, the longer the report takes to compile.

6. Configure the time range you want to report on, up to a maximum of 7 days.

RememberAudit reports cover a maximum time range of seven days. If you want to audit a longer period of time, create multiple reports. For example, if you want to audit data for a full month, run four separate reports of seven days each.

7. Configure other settings, as required for the change audit report you're creating.


Change Audit

Each change audit report is set up differently. Some may require more configuration.

Report Configuration Settings

Role-Based Permissions Select the report type RBP Role Change Report, RBP Group Change Report, RBP User Role Change Report, or RBP Static Group Membership Change Report.

Employee Profile Data Change Select the report type Background Data Change or Feedback Data Change.

MDF Configuration Data ○ Change By Person○ Configuration Type○ Object Type○ Search Deleted Object Type (on/off)

MDF Change History Data ○ Change By Person○ Object Type○ External Code○ Search Deleted Object Type (on/off)

8. Use the Recurrence switch to set up a recurrence schedule.

○ No means that there’s no recurrence and we try to generate the report as soon as you submit it. No is the default setting.

○ Yes means that you want to the report to be generated on a recurring schedule that you define.

To define a recurrence schedule, fill out the following information.

Field Description

Schedule Name The name of the recurrence schedule on the View Schedules tab.

Method The location of the generated report file.○ Select Offline to access the report within the application, on the Access Reports

tab.○ Select Secure File Transfer Protocol (SFTP) to access the report in your SFTP

folder.

SFTP settings If you select the SFTP access method, set up the required technical details to connect to your SFTP server. Then continue to create your report.

Recurring Pattern When and how often you want the report to be generated (Daily, Weekly, Monthly, Yearly).

Start Date and time when the recurrence begins.

End Date and time when the recurrence ends.

NoteIf you set up a recurrence schedule, the dates you select as the time range apply to the first occurrence of the report only. With each recurrence, the dates are adjusted accordingly. For example, if you set up an initial time range of April 1 to April 7 with a monthly recurrence starting on April 15, the first occurrence of the report on April 15 includes changes between April 1 and April 7, the second occurrence on May 15 includes changes between May 1 and May 7, and so on.

9. Submit the request to generate a report.


Results

If you didn’t set up a recurrence schedule, the report generation job is scheduled immediately but it may take some time to prepare. It may take just a few minutes, but, if there’s a lot of data, it can take longer. You receive an email notification when the report is complete (or if it has failed).

If you set up a recurrence schedule, the first report is generated on the exact date and time configured in the recurrence pattern, following the start date. Each subsequent report is generated on the configured day, at the configured time, but on the dates are adjusted accordingly.

Next Steps

Wait to receive an email notification and use the link provided, within 48 hours, to go directly to the page where you can view and download the report in CSV format.

RememberAudit reports are automatically purged after 48 hours. Be sure to check the report you are interested in within 48 hours of generation and archive it if necessary. Otherwise, you may have to run it again.

Alternatively, if you don't want to wait for the email, you can always check job status and download completed reports by going to Change Audit Reports Access Reports .

Task overview: Process for Generating Change Audit Reports [page 282]

Related Information

Downloading a Change Audit Report [page 289]Interpreting a Change Audit Report [page 290]Viewing or Deleting Recurrence Schedules for Change Audit Reports [page 292]Standard Data Included in All Change Audit Reports [page 292]

Data Privacy Auditing for Learning Native Only Customers [page 295]


Change Audit

5.4.1.1 Importing a PGP File Encryption Key

Import a PGP Public Key to encrypt files generated using SFTP Outbound Integrations.

Prerequisites

You must have generated a PGP key pair so that you can import the PGP public key.

Context

If you want to send sensitive data, it is always recommended to encrypt the data at message level. Security Center offers message level encryption using PGP (Pretty Good Privacy) encryption methodology.

Procedure

1. Go to Admin Center Security Center PGP File Encryption Keys .2. To import your PGP Public key for encryption, select Import a Key.

The Import Key dialog box opens.3. Enter a name for your key in the Name field.4. Choose Choose File to select your file.

Some common file formats used for PGP Public keys are: .pub and .asc.5. To finish, choose Import Key to import your file.

Note○ The size of the file varies based on the key size that you have set on the tool to generate a PGP key. The

size of the generated key is generally between 512 and 4096 bytes.○ You cannot upload PGP keys with same name.

Your imported PGP Key is encrypted and listed in the Keys table. To delete a key, choose from Actions.

Results

You can use these keys in various admin tools that support PGP encryption, such as Integration Center or Change Audit Reports.


Related Information

Information on PGP Message Format

5.4.1.2 Configuring SFTP Settings for a Recurring Change Audit Report

Configure SFTP settings if you want to access a recurring change audit report in an SFTP folder, instead of in the user interface.

Prerequisites

● You are in the process of creating a new change audit report and have set the Recurrence switch to Yes.● If you plan to use file encryption, you have already imported your PGP public key on the PGP Key Management

page.

Procedure

1. In the report creation dialog, set Method to Secure File Transfer Protocol (SFTP).2. Set up server access.

Provide information about the SFTP server where you want to use.

Option Description

SuccessFactors hosted SFTP server

Select SuccessFactors hosted SFTP server to use your SAP SuccessFactors SFTP server. Most customers use this option.

Host Address and Port If you cannot use the SAP SuccessFactors SFTP server, type the host address and port of your SFTP server.

FTP Login Type the user ID that SAP SuccessFactors uses to authenticate to the SFTP server. The user ID must have access to the server and to the file path where you want to put the file.

FTP Password Type the password that SAP SuccessFactors uses to authenticate to the SFTP server.

3. Click Test Connection to test server access.4. Set up file access.

Provide information about the directory where you want the file to be saved.


Change Audit

http://help.sap.com/disclaimer?site=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4880

Option Description

File Path The directory path, from the SFTP user ID home, where the file is stored.

NoteThe path should begin with a forward slash. For example: /audit/rbp

File Encryption Select a PGP encryption key imported on the PGP Key Management page.

If no keys have been imported, No Encryption is the only option.

5. Click Test Permission to test server access.6. When both tests are successful, you can continue setting up your report.

Next Steps

Finish setting up the change audit report, as required, and then click Submit.

5.4.2 Downloading a Change Audit Report

Download and save your Change Audit report when is available so that you can investigate changes made in your system.

Prerequisites

● You created the report.● The report was created using the Change Audit Reports page in Admin Center.

Context

You can only download audit reports that you created.

Use this procedure to audit most types of changes, except for Compensation configuration data. Compensation audit reports are generated and exported using a different procedure on the Compensation Plan Activity Audit page.


Procedure

1. Go to Admin Center Change Audit Reports .2. On the Access Reports tab, find the report you want to download.

○ If you see a download action icon, the job is complete and the report is ready for download.○ If you don't see a download action icon and the report was created recently, the job may be incomplete or

failed.○ If you don't see a download action icon and the report is not recent, the old report has been purged and you

need to create a new one.3. Click the download action icon to download your report.4. Save the downloaded zip file locally and extract the CSV file containing your change audit report.

Next Steps

Open the CSV file as a spreadsheet so that you can read the report.


Related Information

Creating a Change Audit Report [page 283]Interpreting a Change Audit Report [page 290]Viewing or Deleting Recurrence Schedules for Change Audit Reports [page 292]Standard Data Included in All Change Audit Reports [page 292]

5.4.3 Interpreting a Change Audit Report

Learn how to read and interpret the data in a change audit report so that you can understand specific changes made to your system.

Prerequisites

● You have successfully created and downloaded your Change Audit report in CSV format.● You can open the generated CSV as a spreadsheet.


Change Audit

Procedure

1. Open the CSV file containing your Change Audit report as a spreadsheet.2. Adjust formatting of the spreadsheet to make it more readable.

○ Autofit column widths so that you can read column headers○ Align text at the top and enable text-wrapping so that you can see all the data○ Use filters or sorting or other formatting to make data easier to find, as needed

RememberDon't forget to save changes to the file locally so that it's ready the next time you need it.

3. Read general information about the report at the top of the sheet, such as when it was generated and the date range it covers.

4. Find and read information about the changes you are interested in. Each row in the spreadsheet corresponds to a single change.

Each row contains standard data that's included in all change audit reports, as well as some data that is specific to the type of report.○ Who? You can see information about the user who made the change and the user who's personal data was

changed.○ Where? You can see information about the module, functional area, and specific context where the change

was made.○ What? You can see the old and new values of the field that was changed.○ When? You can see the date and time when the change was made.

NoteSome values may be blank. Data is only present if it exists in audit logs for that specific change. Not all columns in the report may be relevant for that type of change.

Columns in the report may vary. Most columns are standard and usually present (even if blank) in all change audit reports. But some reports may omit the standard columns altogether, or add new ones, as appropriate for that specific type of report.

When you generate the Change Audit report for a specific user, you can view the change profile history of all candidates in the CSV file.


Related Information

Creating a Change Audit Report [page 283]Downloading a Change Audit Report [page 289]Viewing or Deleting Recurrence Schedules for Change Audit Reports [page 292]Standard Data Included in All Change Audit Reports [page 292]Standard Data Included in All Change Audit Reports [page 292]


5.4.4 Viewing or Deleting Recurrence Schedules for Change Audit Reports

View a list of recurrence schedules, delete ones that are no longer needed, and check the status of completed recurring reports.

Prerequisites

You have the Generate Change Audit Reports permission.

Procedure

1. Go to Admin Center Change Audit Reports .2. On the View Schedules tab, choose one of the following actions.

○ View a list of all recurrence schedules active in your system.○ Use search to find a recurrence schedule on the list.○ Use (delete) to remove a schedule and end the recurring report generation.○ Use (detail view) to check the status of all completed recurring reports.○ Use (refresh) to refresh the page and check for recently created schedules.


Related Information

Creating a Change Audit Report [page 283]Downloading a Change Audit Report [page 289]Interpreting a Change Audit Report [page 290]Standard Data Included in All Change Audit Reports [page 292]

5.4.5 Standard Data Included in All Change Audit Reports

Learn about the standard data that is typically included in all change audit reports.

NoteThe following tables describe standard data points that may be included in all change audit reports. Most reports display this information, when present. But for any given report, if no data is present, some columns may be blank.


Change Audit

Information about the report

Field Description

Report Name The name of the report as it appears in the user interface

Report GUID An internal ID used by the job scheduler

Report Creator User ID The person who created the report

Time Range (Start) The start of the time and date range included in the report, in Coordinated Universal Time (UTC).

Time Range (End) The end of the time and date range included in the report, in Coordinated Universal Time (UTC).

Information about who made the change

Field Description

Changed By User First name, last name, and username of the person (or user account) who made the change

Proxy: Logged in User First name, last name, and username of the logged-in proxy user who made the change (via the "Changed By" user's user account)

Secondary User Provisioner ID and email address of the person who used secondary login in Provisioning to make the change (via the "Changed By" user's user account).

Information about the change

Field Description

Subject User First name, last name, and username of the data subject user, the person whose data was changed

Module Name of the SAP SuccessFactors solution that the changed data record belongs to

Functional Area Functional area or major feature that the changed data record belongs to

Functional Sub Area Subcategory of the functional area that the changed data record belongs to


Field Description

Context Key-Value pairs Contextual data tells you more about where the change was made. Contextual data is defined in a set of numbered key-value pairs that differ in each type of change audit report: <Context 1 Key>, <Context 1 Value>, <Context 2 Key>, <Context 2 Value>, and so on.

NoteContextual data varies for each type of report type. To understand a given change audit report, you need to understand the meaning of each context key-value pair in that type of report.

ExampleIn an RBP Role Change report, you might see a <Context 1 Key> of "Role" and a <Context 1 Value> of "System Admin". The key "Role" tells you that a change was made to an RBP role and the value "System Admin" tells you the name of the RBP role in your system that was changed.

In a ChangedOn report about someone's personal data, you might see a <Context 1 Key> of "Admin Action" and a <Context 1 Value> of "Manage Users". The key "Admin Action" tells you that a change was made in Admin Center and the value "Manage Users" tells you it was made via the Manage Users page.

Field Name Field name of the data record that changed

ExampleIn an RBP Role Change report, a field name "Permission" tells you it's a change to permissions in the role. Or a field name of "Role name" tells you it's a change to the name of the role.

In a ChangedOn report about someone's personal data, the field name is the name of the user data record that changed, such as "Last Name" or "Address".


Change Audit

Field Description

Old Value and New Value Old and new values of the data record that was changed

NoteField values in change audit reports can't be more than 4000 characters. Longer values are truncated, so some changes may not be visible in the report. Try to limit the value of fields you need to audit to less that 4000 characters.

Operation Performed Type of operation that made the change.

● I is for Insert of a new recordU is for Update of a record

● D is for Delete of a record

Timestamp Time and date of the change, in Coordinated Universal Time (UTC).

Effective Start Date Effective start date, for effectivedated records

Effective Sequence The sequence of changes made during a single effectivedated transaction. This field applies mainly to SAP SuccessFactors Employee Central.

Parent topic: Process for Generating Change Audit Reports [page 282]

Related Information

Creating a Change Audit Report [page 283]Downloading a Change Audit Report [page 289]Interpreting a Change Audit Report [page 290]Viewing or Deleting Recurrence Schedules for Change Audit Reports [page 292]

5.5 Data Privacy Auditing for Learning Native Only Customers

Although most customers should audit personal data from central SAP SuccessFactors privacy tools, we make data privacy reports available inside Learning for customers who are native-only (have not adopted the SAP SuccessFactors platform).

You run data privacy reports in SAP SuccessFactors Learning if you have not adopted SAP SuccessFactors platform or cannot use it. Otherwise, we recommend that you run data privacy reports from the central system so that you can see all users and get all changes, not just changes from Learning.


CautionWhen you audit personal information from Learning, you see learning data only.

For native-only customers, we offer these personal data audit reports:

● The User Personal Information report shows you a snapshot of the current personal information stored in SAP SuccessFactors Learning. It does not show changes over time.

● The User Personal Information Change report shows changes to users' data over time. You run it from one of two views:○ You can run it to audit one administrator and see all the changes made by the administrator to all users'

personal data.○ You can run it to view an instructor, a learner (user), or administrator and all the changes made to the

instructor, learner, or administrator.

Auditing Changes Made to User Personal Information in SAP SuccessFactors Learning [page 296]Audit changes to user personal information to see each change made to individual users and who made those changes to the data.

Auditing Changes Made by a Learning Administrator in SAP SuccessFactors Learning [page 298]Audit the changes made by a learning administrator to your users' personal data as part of your data privacy practice.

5.5.1 Auditing Changes Made to User Personal Information in SAP SuccessFactors Learning

Audit changes to user personal information to see each change made to individual users and who made those changes to the data.

Context

As part of your data privacy practice, you can audit all changes made to users and when the changes were made. We recommend that you audit changes made to users in the central SAP SuccessFactors data privacy tools so that you see changes to Learning and also changes in other parts of the suite (performance, goals, baseline employee data, and so on). When you run the report from within Learning, you see the Learning data only.

NoteYou run User Personal Information Changes on one user at a time. You cannot schedule it as a recurring job or customize it.

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go Reports.


Change Audit

2. Find and open User Personal Information Change.

NoteWe also offer a report called User Personal Information in the same group. It is for reporting the current snapshot of a user's personal information.

3. To hide user IDs from the results of the report, select Mask User IDs.4. Locate the field that corresponds to the type of user whose personal information you want to report.

○ If you want to report changes to the personal information of a learner, select the user's ID in User.○ If you want to report changes to the personal information of an administrator, select the administrator's ID

in Admin ID.○ If you want to report changes to the personal information of an instructor, select the instructor's ID in

Instructor.5. In Report Subject, select Changes to the user.6. In Data, select the type of data that you want to see in the report.

This Choice Retrieves this data

Personal Information Personal information includes phone numbers, email addresses and so on. If you are using commerce features, you also see any changes made to this user for Commerce issues.

Learning Assignments Learning assignments include changes to what courses a user is assigned.

Learning History Learning history includes changes to the learning completions: courses that users have finished.

7. Set a date range for the report and then click Schedule Job.

Task overview: Data Privacy Auditing for Learning Native Only Customers [page 295]

Related Information

Auditing Changes Made by a Learning Administrator in SAP SuccessFactors Learning [page 298]


5.5.2 Auditing Changes Made by a Learning Administrator in SAP SuccessFactors Learning

Audit the changes made by a learning administrator to your users' personal data as part of your data privacy practice.

Context

As part of your data privacy practice, you can audit changes made to personal data by learning administrators. We recommend that you run the audit report in the central SAP SuccessFactors data privacy tools so that you can audit Learning and also other parts of the suite (performance, goals, baseline employee data, and so on). When you run the audit report Learning, you see the Learning data only.

NoteYou run User Personal Information Changes on one user at a time. You can’t schedule it as a recurring job or customize it.

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go Reports.2. Find and open User Personal Information.

NoteWe also offer a report called User Personal Information in the same group. It is for reporting the current snapshot of a user's personal information.

3. To hide user IDs from the results of the report, select Mask User IDs.4. In Admin ID, select the admin that you want to report for.

When you run a report to see the personal changes made by administrators, the user and instructor IDs are irrelevant.

5. In Additional Data, select the type of data that you want to see in the report.6. Set a date range for the report and then choose Schedule Job.

Task overview: Data Privacy Auditing for Learning Native Only Customers [page 295]

Related Information

Auditing Changes Made to User Personal Information in SAP SuccessFactors Learning [page 296]


Change Audit

5.6 Creating a Change Audit Report for Career Site Builder

Learn how to create change audit reports for Career Site Builder.

Prerequisites



NoteIf Career Site Builder is integrated with SAP SuccessFactors Recruiting, run a separate report from each to get complete data. Most of the data is duplicated between the two reports, but for candidates configured with Candidate Account Simplification, the Career Site Builder report has data related to Agents for Talent Community Members.

Check that you have the correct permissions. This feature is available in the Career Site Builder and, for Client Admins with the permission Data Subject Reports, it is available as a sub-permission in Data Privacy & Security Settings.

Procedure

1. In the Career Site Builder, go to Settings Data Privacy & Security Settings and select Data Subject Reports.

2. Enter an e-mail address in User Search to search for Talent Community Members or Client Admin users.

NotePartial and multiple e-mail address matching is not supported in the search results and the search will start only when the string entered resembles a valid e-mail address.

3. Select the required report locale.4. Download the individual's Change Report as required.

Results

Career Site Builder generates a timestamped change audit report, which contains details such as first name, last name, created by, created by API, Agents Information.


6 Read Audit

Read auditing capabilities enable you to track access to sensitive personal data.

Companies store a wide range of personal data about people, from the basic information (such as name and date of birth) to the potentially sensitive information (such as national ID or ethnicity). Your data protection and privacy policy may require you to keep track of who has accessed sensitive personal data.

SAP SuccessFactors provides a read audit function that enables you to determine who has accessed the sensitive personal data of employees or external candidates at your company.

NoteNot all personal data, nor all personally identifiable information, is necessarily considered sensitive. Read auditing is only available for small number of records that we've identified as sensitive.

Related Information

Getting Started with Read Audit [page 300]Disabling or Enabling Read Audit [page 306]

6.1 Getting Started with Read Audit

Before you set up and use Read Audit, there are some general prerequisites you need to complete.

Procedure


Check Item Action

Have you adopted the SAP SuccessFactors Platform solution?

If you haven’t adopted the SAP SuccessFactors Platform solution yet, please get in touch with your SAP contact and ask them to start the process. Note that adopting Platform takes time, so we recommend you start as soon as possible.


Read Audit

Check Item Action


Important notes and limitations Important Notes About Read Audit [page 301]

3. Start setting up the read audit function in your SAP SuccessFactors systems.

6.2 Important Notes About Read Audit

Before you start using Read Audit, understand the following important notes and how they impact your SAP SuccessFactors system.

Important Notes About Read Audit


All With the 1H 2020 release, read audit reporting is enabled by default in all Preview and Production systems, in all data centers.

NoteWe recommend that you disable read audit in instances where it's not needed, such as in test and development environments, to reduce the volume of read audit logs and improve system performance.

All Read audit data is pushed to the database every 8 hours. After a user accesses sensitive personal data in an instance, it can take up to 8 hours for the audit log to appear in a read audit report.

All RestrictionRead access logging for OData API has been temporarily disabled for integration scenarios, by default, to reduce performance impact. If you want to have it enabled for a specific tenant, contact Product Support and provide the business justification so we can evaluate the request. While it's disabled, read access to sensitive data via OData API isn't logged and isn't included in read audit reports.

There’s no such restriction on SFAPI and the Employee Central Compound Employee API. Read access to sensitive data via these APIs is logged and included in read audit reports.

In SAP Work Zone for HR and Qualtrics, data accessed through APIs and displayed on the UI are read audit logged.

Setting Up and Using Data Protection and PrivacyRead Audit PUBLIC 301


All The Subject User (ID) column in the report indicates which user's sensitive personal data was accessed. In case of bulk operations, such as employee export, a single aggregated entry with fixed value -9223372036854775808 (Person ID) in the Subject User (ID) is displayed in the report instead of the full list of subject user IDs.

Metadata Framework During provisioning features (enabling or upgrade), quota allocation for Read Access Log fields may exceed the set limit. In such a scenario, Read Access Logging is disabled or set to OFF. We recommend you to reconsider the Read Access Log fields in your system and enable logging from the LSPD Configuration page.

Platform CautionRead audit reports do not include sensitive information that is stored in custom fields or in free-text fields, such as comments. For greater data protection and privacy, do not use custom fields to capture sensitive information and ensure than users of your system don't enter sensitive information in free-text fields, such as comments.

Platform Audit reports cover a maximum time range of seven days. If you want to audit a longer period of time, create multiple reports. For example, if you want to audit data for a full month, run four separate reports of seven days each.

Platform Audit reports are created by scheduled jobs. You’ll be notified by email once the report is ready to view.

Platform There is a total storage limit of 1 GB for reports. On the Access Reports tab, you can see the size of each report and how close you are to reaching the overall storage limit.

Platform Audit reports are automatically purged after 48 hours. Be sure to check the report you are interested in within 48 hours of generation and archive it if necessary. Otherwise, you may have to run it again.

Platform The download of exports from Monitor Jobs is not read audited. As such, you need to use role-based permissions to specify that users can only view their own exports. Otherwise, users would be able to view the exports of other users in a way that can’t be tracked.

Platform Changing user IDs may impact audit reporting. Caution About User ID Conversion [page 14]

Platform When payloads are enabled for OData API and SFAPI audit logs, sensitive personal data can appear in the API audit logs in API Center. Read access to the API audit logs isn't logged and isn't included in read audit reports.

Platform To be included in read audit reports, attachments in Document Management need to be associated with the data subject user, not the uploader. In cases where this association hasn't been done yet, read audit data may be inaccurate or incomplete.

In "changed by" reports, Document Management data shows as blank, so you need to open the attachment to see who the data subject is. In "changed on" reports, Document Management data isn’t shown.

Platform When read audit is enabled, downloading of preview and complete purge reports in Purge Request Monitor is logged whether the purge reports contain sensitive data or not.


Read Audit


Intelligent Services When read audit is enabled, all event payload data in Intelligent Services Center is masked whether it includes sensitive personal data or not. You see "Hidden for privacy compliance" instead of actual field values in event payloads. If you don't want the data to be masked, you can disable read audit following the instructions in Disabling or Enabling Read Audit [page 306].

Employee Central Integration

The Employee Central Compound Employee API considers read audit. Note that any reports that include Compound Employee API users would likely have to gather and publish a huge amount of information and that the API's execution time would increase.

CautionIn the interests of system performance, we recommend that you exempt your Compound Employee API users (that don’t correspond to a real person) from the read audit process.

Employee Central Payroll

Read Access Logging is available for Employee Central Payroll but it doesn’t use the standard SAP SuccessFactors Platform solution. Read Access Logging for Employee Central Payroll.

Employee Central Global Benefits

The following fields can be configured as sensitive:

● Reference ID● Benefits Salary Amount● Custom Fields

NoteRead Access Logging is not supported for Global Benefits for SAP Analytics Cloud reporting.

For more information, refer to Configuring Read Audit in Global Benefits [page 315].

Learning The Learning module doesn’t consume or store ethnicity, minority status, or national ID information from the Platform. Learning, therefore, doesn't need to log read access to these fields.

Onboarding 1.0 Read audit reports for Onboarding 1.0 can be generated on forms, fields, sensitive fields viewed from email queue, sensitive fields viewed from reports generated using the Data Subject Information page, and attachments.

You can configure predelivered forms, attachments and data fields as sensitive and include it in the read audit logs. For more information about configuring read access logs for forms, attachments, and data fields, refer to the “Read Audit in Onboarding” section.


https://help.sap.com/viewer/185f14fbe60d4bbb8d7d5e4f8d89b24b/latest/en-US/811f4561c32845daada1d18c46bdc656.html


Onboarding Read audit reports for Onboarding can be generated on forms, fields, and attachments.

Read audit reports on context and reason are captured for sensitive personal data that are read from:

● UI● API (accessing from API)● File Name (documents downloaded and sent through email as an attachment)● Reports● US Form I-9 and E-Verify process

When a document containing sensitive fields is generated, uploaded, downloaded, emailed, or attached for viewing, read audit logs is captured to determine if the sensitive fields on the document has been viewed.

You can configure predelivered forms, attachments and data fields as sensitive and include it in the

read audit logs from Admin Center Manage Data .

Recruiting Custom fields can be configured as email tokens in Recruiting email templates and offer letters. These email tokens resolve into the appropriate values when emails and offer letters are generated. When read audit is enabled, custom fields configured as sensitive and also configured as email tokens aren't logged when emails and offer letters are generated. This is also applicable to standard fields that are configured as custom=true and marked as sensitive in candidate profile and job application templates. Further, custom fields defined in the Candidate Profile Extension MDF object and configured as sensitive aren't logged.

For information about configuring personal data fields as sensitive in Recruiting, refer to Important Considerations for Configuring Sensitive Fields in Recruiting [page 329].

Recruiting When read audit is enabled, the fileContent property is hidden from query responses for all Recruiting attachments (module property value is RECRUITING).

Performance and GoalsSuccession and Development

When read audit is enabled, standard user information fields identified as sensitive personal data are hidden on the user interface and in APIs. As a result, no read audit logs are necessary or generated.

Reward and Recognition

The Reward and Recognition module stores information in standard, custom, or custom objects fields as there is no sensitive personal data identified. Therefore, Reward and Recognition doesn't support read access to these fields.

6.3 Read Access Logging and Shared Users

To maintain read access logging, we do not allow more than one person to access the system through an ID at one time.

SAP SuccessFactors allows you to set up shared users that can be accessed by multiple people for certain purposes, such as system maintenance or troubleshooting. For example, the sfadmin user is typically shared by multiple Product Support representatives and accessed using the secondary login feature in Provisioning. We ensure that only one person at a time can log on to a shared user account using secondary login. For data


Read Audit

protection and privacy, you can create audit reports that list all personal data that was accessed by a shared user account and the email address of the person that was logged on to the account at the time.

6.4 Setting Up Read Audit

Set up the read audit function so that you can track read access to sensitive personal data.

Prerequisites

● You're working in a Preview or Production data center environment.

NoteWith the 1H 2020 release, read audit reporting is enabled by default in all Preview and Production systems, in all data centers.

Procedure

1. Enable the read audit function in Admin Center.2. Configure sensitive personal data fields for each module to allow read access logging.3. Exclude technical user accounts, such as API users, from read audit logging so that they aren't included in read

audit reports.

1. Disabling or Enabling Read Audit [page 306]Disable or enable read audit logging so that you can disallow or allow authorized users to create audit reports tracking read access to sensitive personal data.

2. Configuring Read Audit [page 307]Configure read audit in each module and allow read access logging for sensitive personal data fields.

3. Excluding User Accounts from Read Audit [page 332]Specify user accounts to exclude from read audit logging and read audit reports. Exclude technical user accounts, such as API users, that are used for system-to-system integration but that don't correspond to a real person.


6.4.1 Disabling or Enabling Read Audit

Disable or enable read audit logging so that you can disallow or allow authorized users to create audit reports tracking read access to sensitive personal data.

Prerequisites

You have the following role-based permissions:

● View Read and Change Audit Configuration● Edit Read and Change Audit Configuration

Context

Read Audit is an admin opt-out feature. That means it's enabled by default until you manually disable it in Admin Center.

Procedure

1. Go to Admin Center Manage Audit Configuration .2. On the Read Audit tab:

○ To disable read audit, switch off the Read Access Logging option.

NoteWe recommend that you disable read audit in instances where it's not needed, such as in test and development environments, to reduce the volume of read audit logs and improve system performance.

○ To enable read audit, switch on the Read Access Logging option.3. Choose Save.

When you enable read audit, you get a message telling you that the activation process has started. It usually takes about 24 hours.

4. Come back to Manage Audit Configuration later to verify that the operation is successful.

5. If you want to enable read audit for Onboarding 1.0, also go to Onboarding 1.0 Settings Features Data Protection and Privacy and choose Activate to enable Read Audit.

Results

Read audit logging is disabled or enabled.


Read Audit

Next Steps

After you enable read audit, proceed to configure sensitive fields for each module.

Task overview: Setting Up Read Audit [page 305]

Next task: Configuring Read Audit [page 307]

6.4.2 Configuring Read Audit

Configure read audit in each module and allow read access logging for sensitive personal data fields.

Prerequisites

You have set up read audit in your instance.

You have the corresponding permissions to access the configuration pages.

Procedure

1. Go to Admin Center Manage Audit Configuration Read Audit .2. On the Manage Audit Configuration page for read audit, choose View Details in the Allowable Sensitive Personal

Data Fields section.

A list of fields that can be configured as sensitive personal data fields displays. You can see a green tick ( ) after the fields already configured as sensitive.

3. Review the quota and already configured sensitive personal data fields and decide which ones to configure as sensitive in the next step. Use the table below to find the detailed configuration tasks for your module.

To configure sensitive fields for... Follow this task

User Management For system administrators: Configuring Read Audit in Business Configuration UI [page 310]

For company provisioners: Configuring Read Audit in Succession Data Model [page 311]

Compensation Configuring Read Audit in Compensation [page 313]

Employee Central For MDF-based objects: Configuring Read Audit in the Metadata Framework (MDF) [page 317]


To configure sensitive fields for... Follow this task

For HRIS fields: Configuring Read Audit in Business Configuration UI [page 310]

For Global Benefit: Configuring Read Audit in Global Benefits [page 315]

For Payment Information objects: Configuring Read Audit for Payment Information [page 315]

Employee Profile For system administrators: Configuring Read Audit in Business Configuration UI [page 310]

For company provisioners: Configuring Read Audit in Succession Data Model [page 311]

Onboarding Configuring Field Objects for Read Audit in Onboarding [page 321]

Onboarding 1.0 Configuring Read Audit for Fields in Onboarding 1.0 [page 324]

Recruiting Important Considerations for Configuring Sensitive Fields in Recruiting [page 329]

4. Choose Go to Configuration Page and configure the sensitive personal data fields for each module.5. When you finish, choose Reload to update the configuration status for the list.

Results

The configuration status and the quota for sensitive personal data fields is updated.


Previous task: Disabling or Enabling Read Audit [page 306]

Next task: Excluding User Accounts from Read Audit [page 332]

Related Information

About the Read Audit Configuration Page [page 309]Sensitive Personal Data Fields Before 2H 2020 [page 330]


Read Audit

6.4.2.1 About the Read Audit Configuration Page

Understand what standard field groups and custom fields mean and how their configurations are calculated in the quota for sensitive personal data fields.

Before you configure read audit for your system, keep in mind that there's a limit to the total number of fields you can conffigure as sensitive personal data fields. The limit is reflected on the UI as quota. The quota is divided into two parts:

● Standard fields are delivered by SAP SuccessFactors and grouped by their meaning. For example, national ID and social security number have the same meaning, so they are grouped together. You can configure any number of fields in the same group as sensitive and it only counts as one field in the quota.

● Custom fields are configured differently for each customer. They can be either a reserved custom field in the data model, such as custom01, or an MDF field created by customers. Each custom field that is configured as sensitive counts as one field in the quota.

The quotas for standard fields and custom fields are independent of each other and are calculated separately. You can find the detailed quota and usage information for each type of fields in the Quota and Usage section on the Read Audit tab of the Manage Audit Configuration page.

Allowable Sensitive Personal Data Fields

The Allowable Sensitive Personal Data Fields section provides an overview of the fields that can be configured as sensitive and included in read audit reports. In the detailed page, the allowable sensitive personal data field list is divided by modules with configuration status and statistics for each module.


● About the Read Audit Configuration Page [page 309]● About the Read Audit Configuration Page [page 309]● About the Read Audit Configuration Page [page 309]● About the Read Audit Configuration Page [page 309]● About the Read Audit Configuration Page [page 309]● About the Read Audit Configuration Page [page 309]● About the Read Audit Configuration Page [page 309]● About the Read Audit Configuration Page [page 309]● About the Read Audit Configuration Page [page 309]● About the Read Audit Configuration Page [page 309]

6.4.2.2 Configuring Read Audit in Business Configuration UI

You can use Business Configuration UI to configure log read access for all HRIS elements including country/regionspecific HRIS elements, and for Employee Profile User Info, Standard, and Background Elements.

Prerequisites

You’re an administrator with access to the Business Configuration UI.

Context

By default, fields for HRIS elements aren’t configured as read audit fields. You can choose fields for HRIS elements that you want to include in log read access.

For Employee Profile, you can configure log read access for the following fields:

● User Info● Standard● Background Elements (Data and Rating fields)

Procedure

1. Go to Admin Center Manage Business Configuration.2. To configure log read access for HRIS elements, perform the following:

a. Go to Employee Central HRIS Elements in the navigation pane.b. Under HRIS Fields, select the HRIS field that requires to be configured.c. Choose Details and select True from the Log Read Access dropdown.


Read Audit

d. Save your changes.3. To configure log read access for Employee Profile; User Info and Standard elements, perform the following:

a. Go to Employee Profile User Info in the navigation pane.b. Under User Info, select the required User Info element that requires to be configured.c. In the User Info page, select True from the Log Read Access dropdown.d. Save your changes.

NoteIn case you’re performing the procedure for Standard element in Employee Profile, select the required standard element and follow Step 3.b to Step 3.d.

4. To configure log read access for Background Elements (Data and Rating fields), perform the following:

a. Go to Employee Profile Background Elements in the navigation pane.b. Under Data Fields or Rating Fields, select the field that requires to be configured.c. Choose Details and select True from the Log Read Access dropdown.d. Save your changes.

Results

You've set a field of your choice as sensitive and have included the same for read audit.

Related Information

Field Level ConfigurationConfiguring Read Audit in Succession Data Model [page 311]

6.4.2.3 Configuring Read Audit in Succession Data Model

You can configure log read access for HRIS elements including country/regionspecific HRIS elements, and for Employee Profile; User Info, Standard, and Background Elements using Succession Data Model.

Prerequisites

You have access to Provisioning for your company instance.


https://help.sap.com/viewer/ad84af95610e409c84e0ca8261aab640/2111/en-US/8ea514e111c243728eef656c0f044229.html

RememberAs a customer, you don’t have access to Provisioning. To complete tasks in Provisioning, contact your implementation partner. If you’re no longer working with an implementation partner, contact SAP Cloud Support.

Context

By default, HRIS fields for HRIS elements aren’t configured as read audit fields. You can choose fields for HRIS elements that you want to include in log read access.

For Employee Profile, you can configure log read access for the following fields:

● User Info● Standard● Background Elements (Data and Rating Fields)

Procedure

1. Log in to provisioning2. Click on your instance in provisioning3. Scroll down to the Succession Management section.4. Choose the relevant link to work with the desired data model file.

To work with... Select Link

Succession Data Model (SDM) Import/Export Data Model

Country/Region Specific SDM Import/Export Country/Region Specific XML for Succession Data Model

CautionWe recommend that when uploading the country/regionspecific data models, you remove any countries/regions and fields that you don’t need before uploading the XML for the first time. If you upload the complete data model, the upload takes longer due to the number of countries/regions in the XML file.

5. Export or Import the XML file.○ To export the XML file, use the radio button by Export, and Choose Submit○ Open the downloaded file in an XML editor and search for the field that requires to be configured.○ To enable log read access for a field set attribute logreadaccess to true.○ Save the exported file as a new file so you have a backup.○ To import, use the radio button by Import. Use Browse to find the file on your local machine and then

choose Submit.


Read Audit

Related Information

Configuring Read Audit in Business Configuration UI [page 310]

6.4.2.4 Configuring Read Audit in Compensation

You can choose to enable read audit from Compensation Home admin UI to monitor and log read access of sensitive data for Compensation, Variable Pay, and Total Compensation Plan forms.

Context

When users access the information, report audit happens and logs are generated using the form template ID. The generated report includes form template name, template ID, users who have accessed the data, and when.

NoteThe report doesn't log access to each form field individually.

Logging happens when users access the data from the following pages, or reloads the pages:

● Forms● Executive Review● Export report of Executive Review● Compensation Profile

Read auditing isn't available on:

● Compensation statements● Aggregate reports● Rollup reports● Table reports● OData API

RememberIf pagination and filtering are turned ON on forms, Executive Review and reports, access to complete form data isn’t logged in the report. Only the data that the user is viewing on that respective page is logged.

Procedure

1. Go to Compensation Home from Admin Center.

2. Choose Action for all plans Company Settings Manage Read Audit Configuration .3. Enable Read Access Logging.


4. Save your changes.

Results

Read audit is enabled for all plans, and data is logged and available for tracking in read audit reports.

6.4.2.5 Configuring Read Audit in Workforce Analytics on SQL (Standalone Companies)

You can configure fields as sensitive in Workforce Analytics on SQL for Standalone organizations.

Prerequisites

Enable GDPR switch in your instance.

Context

This functionality is specific to customers having Standalone organizations only.

Procedure

1. Login to WFA application.2. Choose Admin on the landing page.3. Choose Cube Read Logging Configuration page.4. Select GDPR Access check box.5. Choose Save GDPR Config.6. Select the required fields to be marked as sensitive under the Is Sensitive tab7. Choose Save.

6.4.2.6 Configuring Read Audit in Employee Central


Read Audit

6.4.2.6.1 Configuring Read Audit in Global Benefits

You can choose to enable read audit from Configure Object Definitions admin UI to monitor and log read access of sensitive data for Global Benefits.

Context

The following fields can be considered as sensitive:

● benefitsSalaryAmount field of benefitInsurancePlanEnrollmentDetails object for Insurance type benefit

● referenceId field of benefitSavingsPlanContingentBeneficiaries and benefitSavingsPlanPrimaryBeneficiaries objects

● Custom fields created for benefit objects

Procedure

1. Go to Admin Center > Configure Object Definitions.2. Select Legislative Sensitive Data Configuration from the Search dropdown. Search for the object for which you

want to configure the Read Audit field. The Legislatively Sensitive Data Configuration page is displayed.3. Choose Take Action > Make Correction.4. Go to Read Access Log Configuration section and choose the field for which you want to configure the Read

Access Log from the Field Name dropdown.

For custom objects, all the composite association fields are listed in the Field Name dropdown.5. You can also enable logging for this field by choosing Yes from the Enable Logging dropdown. Save your

changes.

Results

You've set a field of your choice as a sensitive personal data field and have included the same for read audit.

6.4.2.6.2 Configuring Read Audit for Payment Information

Read Audit reports can be configured and enabled for Payment Information fields

There are two standard payment information fields and 12 countryspecific payment information fields that contain sensitive data and can be enabled for read audit.

Standard Payment Information Fields


● Account Number● IBAN

Country-Specific Payment Information Fields

● Brazil - Bank Control Key● Chile - Bank Control Key● France - Bank Control Key● Iraq - Bank Control Key● Italy - Bank Control Key● Mexico - Bank Control Key● Mexico - CLABE Number● Colombia - Proof of Identity● New Zealand - Payment Reference● Venezuela - Payment Reference● South Africa - Account Holder Relationship● United Kingdom - Bulding Society Roll Number

You can view these fields by following these steps

1. Go to Admin Center Manage Audit Configuration Read Audit2. Choose View Details under Allowable Sensitive Personal Data Fields. You can see the standard/custom fields

under the Employee Central tab.

Configuring Fields for Read Audit

1. Go to Admin Center Go to Configuration Page . This will redirect you to Configure Object Definitions2. Choose Legislatively Sensitive Data Configuration, then choose PaymentInformationV3. By default, the fields

are not read audit enabled.3. To enable the fields, under Enable Logging, choose Yes for the relevant fields and save the configuration.


Read Audit

The system will generate the read access logs if any of the RAL configured fields has been read/viewed.You can also add custom fields to Read Access Log Configuration, if the custom field is defined in object definition. You enable custom fields for RAL in the same way as standard fields.

6.4.2.7 Configuring Read Audit in the Metadata Framework (MDF)

You can create custom MDF objects and mark them as Legislatively Sensitive Personal Data (LSPD) so that you can configure them as sensitive personal data fields and enable read access logging.

MDF custom objects marked as LSPD can be configured either on the module configuration pages where the objects belong, or centrally in MDF using the Configure Object Definition page or the Extension Center tool.

Configuring Read Access Logging Field Using LSPD Configuration [page 318]You can include a field for read audit by using the LSPD Configuration page. You can configure a field as Read Access Log field and enable read audit logging for this field.

Enabling Read Access Log of MDF Objects in Extension Center [page 319]You can enable read access log for MDF objects containing personally sensitive data in Extension Center.


6.4.2.7.1 Configuring Read Access Logging Field Using LSPD Configuration

You can include a field for read audit by using the LSPD Configuration page. You can configure a field as Read Access Log field and enable read audit logging for this field.

Prerequisites

Ensure that the Legislative Sensitive Data Configuration for the object exists.

Context

You can choose to configure and enable read access logging for custom object fields. However, in predelivered objects, few fields are by default configured as reading access logging fields. You can enable read access logging for them using the LSPD Configuration page.

You can’t enable read access logging in the following scenarios:

● If the field is an Auto Number or Data Source data type field.● If the field is configured as a Searchable field.● If the field is configured as a System field.● If the field is configured as a Context field.

Procedure

1. Go to Admin Center > Configure Object Definitions.2. Select Legislative Sensitive Data Configuration from the Search dropdown. Search for the object for which you

want to configure the Read Audit field. The Legislatively Sensitive Data Configuration page is displayed.3. Choose Take Action > Make Correction.4. Go to Read Access Log Configuration section and choose the field for which you want to configure the Read

Access Log from the Field Name dropdown.

For custom objects, all the composite association fields are listed in the Field Name dropdown.5. You can also enable logging for this field by choosing Yes from the Enable Logging dropdown. Save your

changes.

Results

You've set a field of your choice as Read Access Log and have included the same for read audit.


Read Audit

Task overview: Configuring Read Audit in the Metadata Framework (MDF) [page 317]

Related Information

Enabling Read Access Log of MDF Objects in Extension Center [page 319]

6.4.2.7.2 Enabling Read Access Log of MDF Objects in Extension Center

You can enable read access log for MDF objects containing personally sensitive data in Extension Center.

Procedure

1. Go to the Object Detail page of the object in Extension Center.2. Choose a user type field of the object as the Data Subject Field.

Data Subject Field indicates the person whom the information is about.

Status and Data Subject Field Type are read-only.

NoteYou can't add the following types of field as the Data Subject Field Type:○ The field isn't a custom field.○ The field is transient.○ The field has been selected as a RAL or context field.○ The parent field of a composite child entity.○ The Private or Sensitive Information attribute of the field is set to Yes.

3. Choose a module and a functional area to indicate where the read access log comes from.4. Add context fields if more context information is needed for the read access log.

NoteYou can't add the following types of field or association as a context field:○ The field isn’t a custom field.○ The field data type is Attachment, CLOB, or Data Source.○ The field is transient.○ The field has been selected as a RAL or data subject field.○ The parent field of a composite child entity.○ The Private or Sensitive Information attribute of the field is set to Yes.


○ Generic Object, Foundation Object, PickList, or Translatable fields of a referenced object.○ The association type is Valid When or Join By Column.○ The association of a referenced object.

5. Add custom fields as the Read Access Logged Fields.

NoteYou can't add the following types of field or association as a RAL field:○ The field isn’t a custom field.○ The field data type is Auto Number or Data Source.○ The field has already been selected as a context field.○ The field is configured as a searchable field.○ The field has been selected as a context or data subject field.○ Generic Object, Foundation Object, PickList, or Translatable fields of a referenced object.○ The association type is Valid When or Join By Column.○ The association of a referenced object.


Task overview: Configuring Read Audit in the Metadata Framework (MDF) [page 317]

Related Information

Configuring Read Access Logging Field Using LSPD Configuration [page 318]

6.4.2.8 Configuring Read Audit in Onboarding

Read audit reports for Onboarding can be generated on forms, fields, and attachments.

You can define whether you want to perform read audit on a form, attachment, or a field based on your interpretation of whether a form, attachment, or a field contains sensitive personal data.

You can configure a predelivered form and data fields as sensitive and include it in the read audit logs.

NoteIf you choose not to include any specific forms or fields in the read audit log, there’s default list of forms and fields that get included in read audit reports.

Ethnicity, National ID Number/Social Security Number, and Minority are considered as sensitive personal data fields by default.


Read Audit

6.4.2.8.1 Onboarding

6.4.2.8.1.1 Configuring Field Objects for Read Audit in Onboarding

You can configure Sensitive Personal Data (SPD) fields in addition to the 3 SPD fields that are and included in read access reports.

Prerequisites

Enable the following role-based permissions:

● Manage Data● Onboarding Read Access Logging Configuration

For more information on how to enable these fields, refer to the "Role-Based Permissions for Administrators in Onboarding and Offboarding" topic.

Context

All the sensitive fields, which include predelivered and custom fields for Onboarding are listed under the Onboarding tab in Admin Center Manage Audit Configuration .

There are seven standard fields and 10 custom fields.

The seven standared/predelivered fields are:

● Race● Ethnicity● National ID● Disability Status● Criminal Conviction● Compensation and Salary● Back Account and Credit Card

Out of these seven standard fields, Race, Ethnicity, and National ID are enabled for read audit by default. Rest of the standard and custom fields are disabled by default.

Configure Onboarding Read Access Logging Configuration objects to enable or disable read audit for standard and custom fields.

NoteFor every Onboarding Read Access Logging Configuration object, there’s one field.


Procedure

1. Go to Admin Center Manage Audit Configuration Read Audit .2. Choose Go to Configuration Page link, under Onboarding tab.

The list of all the prepopulated standard and custom fields are displayed on this page.3. To configure the standard and custom fields for read audit, enter Onboarding Read Access Logging

Configuration in the Search box on the Manage Data page.

The list of all the prepopulated standard and custom field objects are listed under the second search box.4. To configure a standard or a custom field for read audit, select the field object from the list.

For example, if you choose disability-status from the list, the enabled field is set to No by default, and all the forms where this field is being used are listed under the relatedFields. Click on the forms to see the Field Label details.

The fieldType for standard fields is Predelivered. For custom fields, the fieldType is Custom.

NoteIf you’re configuring national-id for read audit, it gets enabled for I-9 and E-Verify. To verify, go to

Admin Center Configure Object Definitions . Select Legislatively Sensitive Data Configuration from the search box and choose I-9UserData object. Scroll down to Enable Logging, the fields under Read Access Log Configuration are set to Yes.

5. To enable read audit for this field, choose Take Action Make Correction , and set enabled to Yes.

You can define the fields that are read audit enabled and which category it belongs to. Based on that the Onboarding Read Access Logging Configuration object related fields on the forms get populated. Therefore, while configuring you're actually enabling or disabling a category and not a specific field.

If a sensitive field is removed by setting enabled to No, then the form isn’t included for read audit.

For forms, you need to define if a form is sensitive or not. It is not dependent on the fields.

NoteRace, Ethnicity, and National ID are enabled as sensitive fields by default. However, you can choose to disable it as per your requirement.

6. Choose Save.

NoteA quota allocation error might appears if you've exceeded the quota for the sensitive personal data fields. The maximum number of standard fields that can be configured for read audit is five. The maximum number of custom fields that can be configured is 10.

If you enable a sensitive field, which has already been enabled by another module, the quota doesn't get consumed, and the error message doesn't appear.


Read Audit

Results

A checkmark appears next to the field on the Manage Audit Configuration page, under Onboarding tab.

Related Information

Role-Based Permissions for Administrators in Onboarding and Offboarding

6.4.2.8.1.2 Configuring Forms for Read Audit in Onboarding

You can define whether you want to perform read audit on a particular form based on your interpretation of whether a form contains sensitive personal data or not.

Prerequisites

Enable the Manage Data role-based permissions under Administrator Permissions Metadata Framework .

Context

By default, some of the forms are included for read audit. You can choose the forms that you want to include or exclude in Read Access Logs.

Procedure

1. Go to Admin Center Manage Data .2. Enter ComplianceForm in the search box, and choose the form that you want to include for read audit from

the search menu.

The Sensitive field on the compliance form is set to Yes by default.

3. To exclude a form from read audit, select Take Action Make Correction and set the Sensitive field to No.


https://help.sap.com/viewer/c94ed5fcb5fe4e0281f396556743812c/latest/en-US/f706e27bcc9d44afb31ac14515876931.html

Results

If the Sensitive field is set to Yes, read audit is performed on the form before it's sent to Data Management System (DMS), or to DocuSign, or as an attachment in e-mail notifications.

6.4.2.8.2 Onboarding 1.0

6.4.2.8.2.1 Configuring Read Audit for Forms in Onboarding 1.0

You can choose whether you want to include a form for read audit by enabling the read audit functionality for the form.

Procedure

1. Log on to the SAP SuccessFactors Onboarding application.2. From the dropdown on the home page, select On/Offboarding.

3. Select On/Offboarding Dashboard Reference Files Forms .4. Select the Forms Group from the left navigation pane that houses the form you want to edit.5. Select the form and click Edit from the menu.6. Enable Perform Read Audit and click Update.

Results

You've included a form of your choice for read audit.

6.4.2.8.2.2 Configuring Read Audit for Fields in Onboarding 1.0

You can choose whether you want to include a field for read audit by enabling the read audit functionality for that field.

Procedure

1. Go to Admin Center Manage Audit Configuration Read Audit .2. Select View Details.


Read Audit

3. Choose Go to Configuration Page link, under Onboarding 1.0 tab.4. Select Data Dictionary.5. Scroll down to Read Audit tag on the left navigation pane.6. Select the field under Tag Name that you want to include in read audit and click Read Audit on the toolbar.

NoteTo exclude the field from read audit, choose Read Audit option on the toolbar once again. The option gets grayed out once you've disabled it.

7. To enable read audit for custom fields, select Fields under Custom Fields tag name.8. Select the custom field for which you want to enable read audit and choose Read Audit.

NoteA quota allocation error might appears if you've exceeded the quota for the sensitive personal data fields. The maximum number of standard fields that can be configured for read audit is five. The maximum number of custom fields that can be configured is 10.

If you enable a sensitive field, which has already been enabled by another module, the quota doesn't get consumed, and the error message doesn't appear.

Results

You've set a field of your choice as sensitive and have included the same for read audit.

6.4.2.8.2.3 Configuring Read Audit for Attachments in Onboarding 1.0

You can choose whether you want to include an attachment for read audit by enabling the read audit functionality for the attachment from the panel designer.

Procedure

1. Log on to the SAP SuccessFactors Onboarding application.2. From the dropdown on the home page, select On/Offboarding.

3. Go to On/Offboarding Dashboard Settings Panels .

4. From the left navigation pane, select Onboarding Post Hire Verification Panels .5. Select a panel.6. Drag and drop File Upload button on the panel designer.


7. Under Properties - File Upload, scroll down to Perform Read Audit option and set it to Yes.

NoteAll the SAP standard panels having Upload Control is eligible for read audit by default. If you don't want any include any of the standard panels for read audit, you can remove the panel from the Value field under

Accounts Account Options on the home page.

8. Click Save.

Results

You've enabled read audit for an attachment.

6.4.2.9 Configuring Read Audit in Recruiting Using Manage Templates

Read audit reports are generated when a user accesses information about a candidate in fields configured as sensitive in candidate profile or job application templates. You can use the Manage Templates tool, available from Admin Center to configure fields as sensitive in candidate profile or job application templates.

Prerequisites

● Manage Recruiting Templates is enabled in Provisioning.

RememberAs a customer, you don't have access to Provisioning. To complete tasks in Provisioning, contact your implementation partner. If you're no longer working with an implementation partner, contact Product Support.

● Manage Recruiting template Role-based permission is enabled.

Procedure

1. Navigate to Admin Center Manage Templates .2. Select the Recruiting Management tab to configure either of these two templates:

○ Select the Job Application template.○ Select the Candidate Profile template.

When you select either of the two choices, you’re directed to the template list page.


Read Audit

3. Select the appropriate template.4. Select Template Settings and then select Click to modify next to Fields defined.5. Set the Is Sensitive and the Anonymize attributes for the required field to True.6. Select Done to save changes and close the dialog box.7. Select Save as Draft to save and review all changes.8. Select Publish to publish your changes for the template temporarily.

Results

Read audit is enabled for the fields you configured as sensitive.

NoteThe settings for sensitive fields sync with all active and inactive candidate profile or job application templates in which these fields are configured. During this process, if a field is marked as sensitive in your configured template but not in other templates in the system, the field's setting is automatically changed to sensitive in all templates. This action ensures consistent settings for sensitive fields across templates.

Related Information


6.4.2.10 Configuring Read Audit for Recruiting in Provisioning

Personal data fields in Recruiting are determined as sensitive based on the settings configured in the candidate profile template and job application templates. You can edit candidate profile or job application templates in Recruiting to configure fields as sensitive.

Prerequisites

● Recruiting is enabled in Provisioning.● You have access to Provisioning.



Procedure

1. Do one of the following to edit the candidate profile template form or a job application template form, as applicable:

○ Go to Provisioning Managing Recruiting Edit Candidate Profile Template .

○ Go to Provisioning Managing Recruiting Edit Job Requisition Application Template .2. Copy and paste the entire code from the template form to an XML editor.3. Perform the following steps in the Field definition section:

a. To configure the race or disabilityStatus field as sensitive, set the field's anonymize and sensitive attributes to true.

Sample Code

<field-definition id="race" type="text" required="true" custom="false" anonymize="true" sensitive="true">

b. To configure a custom field as sensitive, set the field's anonymize and sensitive attributes to true.

Sample Code

<field-definition id="customPersonal1" type="text" required="true" custom="true" anonymize="true" sensitive="true">

4. Save the template.5. Do one of the following, as applicable:

○ Go to Provisioning Managing Recruiting Edit Candidate Profile Template .

○ Go to Provisioning Managing Recruiting Edit Job Requisition Application Template .6. Copy the modified code from your configured template and paste it into the template form.7. Choose Save Form.

Results

Read audit is enabled for the fields you configured as sensitive.

NoteThe settings for sensitive fields sync with all active and inactive candidate profile or job application templates in which these fields are configured. During this process, if a field is marked as sensitive in your configured template but not in other templates in the system, the field's setting is automatically changed to sensitive in all templates. This action ensures consistent settings for sensitive fields across templates.

For more information about configuring candidate profile and job application templates, refer to the Setting Up and Maintaining SAP SuccessFactors Recruiting guide.


Read Audit

Related Information


6.4.2.11 Important Considerations for Configuring Sensitive Fields in Recruiting

You can mark personal data fields of candidates as sensitive in candidate profile and job application templates. Read audit reports are generated when a user (recruiter, candidate, or someone else) accesses sensitive personal data about a candidate.

Important considerations for configuring sensitive fields

● The following fields can be configured as sensitive:○ Standard fields: ssn, ethnicity, race, and disabilityStatus.○ Custom fields: A maximum of 10 custom fields can be configured as sensitive across candidate profile and

job application templates.

NoteTo configure a field as sensitive, ensure that both the sensitive and the anonymize attributes for the field are set to true.

● After you upload a candidate profile template or a job application template, the following actions occur:○ If a field is configured as sensitive in the uploaded template, the same field is automatically marked as

sensitive in other active or inactive templates to ensure consistent settings for sensitive fields across templates.

○ The Recruiting Sensitive Personal Data Field List MDF object in Admin Center, which maintains the list of standard and custom fields configured as sensitive across templates, gets updated.To view this MDF object in Manage Data page, the system administrator has to enable the following permissions in AdminCenter Manage Recruiting Permissions Permission Role Detail (System Admin)

MDF Recruitng Permissions :○ Recruiting Sensitive Personal Data Field List○ Recruiting Sensitive Personal Data Field List.spdField List (RCMSPDField)

● A field already configured as sensitive=true can't be marked as sensitive=false directly from the candidate profile template or a job application template. To mark a field as sensitive=false, delete the field from the Recruiting Sensitive Personal Data Field List MDF object.

NoteWhen you delete sensitive custom fields from the Recruiting Sensitive Personal Data Field List MDF object, the quota allocated for 10 custom fields is freed up.

● Fields configured as sensitive are hidden in the Display Options on the Candidate Summary page and the Candidate Search page.


6.4.2.12 Configuring Read Audit in SAP SuccessFactors Work Zone

In some cases, you need to manually enable read audit in SAP SuccessFactors Work Zone.

Context

In SAP SuccessFactors Work Zone, users access the data from the SAP SuccessFactors system via API calls. The configuration required to enable read audit is done automatically when you complete the onboarding process (see the related information). In case you cannot access read audit in SAP SuccessFactors Work Zone, follow the steps to manually add it .

Procedure

1. In SAP BTP cockpit, find the "SuccessFactors_API" destination and choose the edit icon .2. In the Additional Properties section, choose New Property, and enter sap.header.X-SF-Process-Name as

the property name and WorkZone for HR as property value.

3. Save the configuration change.

Results

Read audit in SAP SuccessFactors Work Zone is logged and available for tracking in read audit reports.

Related Information

Onboarding to SAP SuccessFactors Work Zone

6.4.2.13 Sensitive Personal Data Fields Before 2H 2020

Learn about the sensitive personal data fields included in read audit reports before the 2H 2020 Release.

RememberStarting from 2H 2020, you can configure sensitive personal data fields in each module to enable read audit.

If you have enabled read audit previously, read access to the following sensitive personal data fields continues to be logged. However, we recommend that you review the list before you set up and configure read audit in 2H 2020.


Read Audit

https://help.sap.com/viewer/b03c84105ff74f809631e494bd612e83/LATEST/en-US/edc62f97f50a432bb8dba04626689050.html

If you have disabled read audit previously, the feature remains disabled in 2H 2020. However, you'll find the following fields configured as sensitive by default even though the read access isn’t logged. Take this into consideration when you re-enable read audit.

Basic User Information

The following user data fields (standard elements) are considered sensitive and always included in read audit reports:

● ethnicity● minority● ssn

Employee Central

The following personal data fields (HRIS elements) in Employee Central are considered sensitive and always included in read audit reports:

● ethnic-group● visible-minority● national-id

CautionCountryspecific fields weren’t supported by read audit logging or included in read audit reports in the Q4 2019 release.

Employee Central Benefits

The Reference ID field in Employee Central Benefits may contain sensitive personal data. It appears in the Savings Plan Contingent Beneficiary and Savings Plan Primary Beneficiary objects and many customers may use it to capture national ID information, so it's considered sensitive and always included in read audit reports.

Onboarding 1.0

Onboarding 1.0 offers predelivered compliance forms for US, UK, Canada, Australia, and India. All predelivered compliance forms are considered sensitive and are included in Read Access Logs independent of having sensitive personal data fields.


Onboarding

Onboarding currently supports custom compliance forms only and doesn’t offer predelivered compliance forms. Custom forms aren’t included in Read Access reports.

Recruiting

If configured in the job application template or candidate profile template as standard fields (custom="false"), the following personal data fields in Recruiting are considered sensitive and included in read audit reports:

● ethnicity● ssn

NoteWith the Q4 2019 release, custom fields (custom="false") are not included in read audit reports.

6.4.3 Excluding User Accounts from Read Audit

Specify user accounts to exclude from read audit logging and read audit reports. Exclude technical user accounts, such as API users, that are used for system-to-system integration but that don't correspond to a real person.

Context

Technical user accounts regularly process large amounts of data so including them in a read audit can impact system performance and fill the resulting log with a significant amount of irrelevant information.

Procedure

1. Go to Admin Center Manage Audit Configuration Read Audit User Exceptions .2. Choose Add User Exceptions.3. Use the search box to find users and add them to the exception list.

Results

Specified user accounts are excluded from read audit logs and reports. You can remove a user from the exception list at any time using the Delete icon.


Read Audit

NoteThe specified users are only excluded when they access sensitive personal data through an API. If anyone manually logs into the account and views sensitive data in the user interface, they still appear in read audit reports.


Previous task: Configuring Read Audit [page 307]

6.5 Read Audit Reports

Learn how to create, download, and interpret read audit reports.

Read audit reports allows you to track the access to sensitive personal data fields in your system. Here's an overview of the process:

1. Choose a type of access and create a read audit report.2. Wait for the report to be generated. You’re notified by email when the report is complete.3. Download and save the report within 48 hours. After 48 hours, completed reports are purged from storage.4. Interpret audit data in the report to understand the sensitive personal data accessed in your system.

Creating a Read Audit Report [page 333]Create a read audit report to see who has accessed sensitive personal data about a given person.

Read Audit Reports Include Sensitive Personal Data [page 335]Read audit reports include sensitive personal data only, not all personal data.

Interpreting a Read Audit Report [page 336]Learn how to read and interpret the data in a read audit report so you can understand read accesses made to sensitive personal data in your system.

6.5.1 Creating a Read Audit Report

Create a read audit report to see who has accessed sensitive personal data about a given person.

Prerequisites

● You're working in a Preview or Production data center environment.

NoteWith the 1H 2020 release, read audit reporting is enabled by default in all Preview and Production systems, in all data centers.


● Read audit is enabled in your system.● You have Generate Read Audit Reports permission.

Procedure

1. Go to Admin Center Read Audit Reports Create Read Audit Report .2. Select the type of user you want to create a report for.

○ For an individual employee or onboardee in Onboarding, choose Person Search.○ For an external candidate in Recruiting, choose External Candidate Search.○ For a new hire onboardee in Onboarding 1.0, choose Onboardee Search.

A dialog opens where you can configure the report settings.3. Specify the person you want to report on.

○ For the Person Search, you have two choices:○ To see who has accessed sensitive personal data about a specified person, select Read On Subject

User and use the Person search to specify the employee.○ To see whose sensitive personal data a specified person has accessed, select Read By User/Data

Operator and use the Person search to choose the employee.○ For the External Candidate Search, use the External Candidate search to specify the candidate.○ For the Onboardee Search, use the Onboardee search to specify the new hire in Onboarding 1.0.

4. Select the modules and functional areas you want to include in the search.

NoteTo optimize system performance, limit your search to only the required data. The more modules you choose, the longer the report takes to compile.

5. Configure the time range you want to report on, up to a maximum of 7 days.

RememberAudit reports cover a maximum time range of seven days. If you want to audit a longer period of time, create multiple reports. For example, if you want to audit data for a full month, run four separate reports of seven days each.

6. Submit the request to generate a report.

Results

The report may take just a few minutes to prepare or, if there’s a lot of data, it can take longer. You receive an email notification when the report is complete (or if it has failed).


Read Audit

Next Steps

Wait to receive an email notification and use the link provided, within 48 hours, to go directly to the page where you can view and download the report in CSV format.

RememberAudit reports are automatically purged after 48 hours. Be sure to check the report you are interested in within 48 hours of generation and archive it if necessary. Otherwise, you may have to run it again.

Alternatively, if you don't want to wait for the email, you can always check job status and download completed reports by going to Read Audit Reports Access Reports .

Task overview: Read Audit Reports [page 333]

Related Information

Read Audit Reports Include Sensitive Personal Data [page 335]Interpreting a Read Audit Report [page 336]

6.5.2 Read Audit Reports Include Sensitive Personal Data

Read audit reports include sensitive personal data only, not all personal data.

Sensitive personal data is information about an identified person that is considered sensitive. When someone reads the data in a sensitive personal data field, their read access to the data is recorded in audit logs. Read audit reports show you a list of users who have accessed sensitive personal data about a given person.

NoteThe Subject User (ID) column in the report indicates which user's sensitive personal data was accessed. In case of bulk operations, such as employee export, a single aggregated entry with fixed value -9223372036854775808 (Person ID) in the Subject User (ID) is displayed instead of one entry for each subject user ID.

Sensitive personal data is a small subset of all the personal data stored in the system. Not all personal data, nor all personally identifiable information, is necessarily sensitive. Read auditing is only available for small number of fields that we've identified as sensitive.

Parent topic: Read Audit Reports [page 333]


Related Information

Creating a Read Audit Report [page 333]Interpreting a Read Audit Report [page 336]

6.5.3 Interpreting a Read Audit Report

Learn how to read and interpret the data in a read audit report so you can understand read accesses made to sensitive personal data in your system.

Report Header Section

The header section contains general information about the audit report, such as who generated the report and the data range it covers.

Report Body

The report body contains detailed information about read access to fields that are configured as sensitive. You can find the following columns in a report:

Columns Description

Read By User (ID)

Read By User (First Name)

Read By User (Last Name)

User ID, first name, and last name of the user who read the sensitive data

NoteFor Recruiting, the columns, Read By User (ID) and Subject User (ID) display the same User ID when external candidates access their own data.

Proxy: Logged in User (ID)

Proxy: Logged in User (First Name)

Proxy: Logged in User (Last Name)

User ID, first name, and last name of the logged-in user acting as a proxy who read the sensitive data

Subject User (ID)

Subject User (First Name)

Subject User (Last Name)

User ID, first name, and last name of the subject whose sensitive information was read

NoteRead access made through bulk operations, such as employee export, generates only one single aggregated entry per operation with fixed value -9223372036854775808 (Person ID) in the Subject User (ID) column, instead of one entry for each subject user ID.


Read Audit

Columns Description

Module

Functional Area

Functional Sub Area

Module and function area information where the sensitive data resides

Timestamp Indicates the time of the access

Access Channel Indicates the channel through which the access was made.

Read Successfully Indicates whether the data was read successfully.

Sensitive Personal Data Field The name of the sensitive personal data field that was read. Read access to each field generates an entry in the report.

NoteWhen the field value is Purge Report, there’s no subject user in this entry. The record shows who downloads the purge report of a purge request.

Context Key/Value Pairs (Context 1 ~ 10)

The context key/value pairs are used to store modulespecific contextual information that helps you identify the sensitive data.

Attachment Name If an attachment is involved in the read access, the name appears here.

Audit Record ID A GUID of the audit record

Application From which application the data was accessed

NoteCurrently, only SAP Work Zone for HR has information for this field.

Parent topic: Read Audit Reports [page 333]

Related Information

Creating a Read Audit Report [page 333]Read Audit Reports Include Sensitive Personal Data [page 335]


6.6 Read Audit in the Employee Central Compound Employee API

How read audit is implemented for the Compound Employee API – read audit is supported in all Compound Employee API modes.

Data Access Timestamp

The Compound Employee API uses the API query session timestamp as the data access timestamp for HRIS and MDF elements. This makes it easier to match the API query response to the respective read audit log records.

Performance

You can expect the Compound Employee API's performance to reduce, the more fields are configured as sensitive or as context fields. Especially the configuration of context fields in referenced objects can reduce API performance drastically, this is the case when this is done for a large number of MDF object types.

CautionIn the interests of system performance, we recommend that you exempt your Compound Employee API users (that do not correspond to a real person) from the read audit process.

Compound Employee API doesn't support the field Cost Center

The following isn't supported for read audit processing in the Compound Employee API.

● job_information/cost_center(When externalKeyMapping is enabled.)If you configure this field as read audit relevant, it isn't exposed in the API response. Instead, a log item is returned. For example:

Sample Code

<log_item> <field_name>cost_center</field_name> <code>COMPOUND_EMPLOYEE/FIELD_NOT_SUPPORTED_FOR_READ_AUDIT_LOG</code> <severity>WARNING</severity> <message_text>Field "cost_center" can't be returned: The field "cost_center" is configured as read access log relevant, but is not supported for read access logging in Compound Employee API.</message_text> </log_item>


Read Audit

6.6.1 Basic Assumptions for Read Audit in the Compound Employee API

What's important to know about read audit.

● Different data is used for read audit processing depending on which mode the Compound Employee API is running in:○ Delta transmission mode: usually the most current data is considered, except if a deletion of the current

data was reported, then snapshot data is considered.○ Snapshot mode: only snapshot data is considered.○ All other modes: the current data is considered.

● Only write read audit entries for elements in the API response:Read audit log entries are only created when the respective segment contains data and is exposed in the API response. No read audit log entries are created for segments that don't contain data relevant to the employee.

● Fields with sensitive personal data are always logged:Empty fields that aren't exposed in the API response are logged, if they are configured as fields containing sensitive personal data.

● Read audit doesn't apply to API filters set through a request. The request is not aborted if it contains a filter parameter for a read audit relevant field.

● Failed Read Audit logging results in an API error:If the API can't create Read Audit log entries, for example because the persistence layer of read audit isn't configured, the entire request is aborted and no data is returned.

● The field person_id_external is not considered as read audit-relevant by the API.

6.6.1.1 Read Audit Terminology

Learn about read audit terminology in the context of the Compound Employee API.

Some read audit terminology and phrases explained.

Term Explanation

Read Audit relevant field Whenever a read audit relevant field is accessed by a user, this access is logged in the read audit log.

Read Audit context field Read audit context fields are defined for some entities. These fields help uniquely identify the entity for which the read audit field is read. Most commonly, Start Date and User ID.


Term Explanation

Read Audit record The read audit record is written in the read audit log and consist of the following:

● Read Audit relevant field● Up to 5 Read Audit context fields and their corresponding

values● Functional Area (employment or personal information)● Sub functional area (entity name)● User ID or Person ID for which the data is read● User who accessed the data● Data access time

Read Audit configuration Read Audit configuration depends on the entity type. In Admin Center, Read Audit for HRIS entities is configured in Business Configuration and for MDF entities it is configured in Configure Object Definition. In Read Audit configuration, you define the fields that are read audit relevant. For MDF entities, you can configure read audit context fields. For HRIS entities, you can't, they are predefined.

Read Audit processing Read Audit processing in the Compound Employee API includes the gathering of relevant read audit data, for example read audit relevant fields and their corresponding context fields and the writing of data to the read audit log.

6.6.2 Read Audit in Delta Transmission Mode

In delta transmission mode only context fields for the current image are considered.

Module specific context fields are only written for the current image in delta transmission mode. This has the following implications:

● There are no separate read audit log entries for previous values. Only one record is logged for both current and previous values.

● Read audit log entries are only written for transactional data. Except for the element action DELETE, where snapshot data is considered for the read audit log entries.

● When the result option changedFieldsOnly is used, read audit log entries are written even for the sensitive personal data fields that didn't change.

● When the result option changedSegmentsOnly is used, read audit log entries are only written for the returned elements.


Read Audit

6.6.3 Read Audit in Snapshot Mode

In snapshot mode, only context information of a composite object structure is obtained.

Whenever snapshot data is the source of read access log entries, the Compound Employee API only considers context fields that belong either to the affected object itself or are maintained through any parent or child association. Context fields through pure generic object references are ignored. For HRIS objects, nothing is ignored.

6.7 Read Audit in Reporting

Learn how read audit works in reporting.

Read Audit in Table Reports [page 341]Read Audit happens for list reports (ungrouped reports) which contain sensitive data. If there are more than one sensitive fields, a log registered for each field.

Read Audit in Advanced Reports (Realms) [page 343]Read audit logging applies to all reports that contain sensitive data in advanced reports (realms).

Read Audit in Story Reports [page 344]Read Audit happens whenever a sensitive field appears in a list report (unaggregated report), or it is used as a filter in the report. If there are more than one sensitive fields, a log is registered for each field.

Protecting Personal Data in Spreadsheet Reports [page 345]Spreadsheet reports (also known as RDF reports) are custom built by certified partners for individual customer. These reports do not leverage the Table report framework, so they will not do Read logging.

Disabling Sensitive Fields in List Views [page 346]You can disable fields in list views in from the List View Admin tool. You need to disable any fields that your organization consider sensitive.

Sensitive Label for Fields in the Canvas Reports [page 347]In the Canvas reports, sensitive fields are shown with SENSITIVE label when you build a query.

6.7.1 Read Audit in Table Reports

Read Audit happens for list reports (ungrouped reports) which contain sensitive data. If there are more than one sensitive fields, a log registered for each field.

The log timestamp represents time for the report query execution (which happens slightly before the report is shown or scheduled to the user). If logging cannot be completed successfully, the user is not allowed to execute the report. The user sees an empty report.

● Scheduling of Table reports: The Table reporting tool logs when a user attempts to access a report with sensitive data. Therefore, the logging happens when the report is generated and the timestamp of the logs also represents the time when the report query is executed.The system does not track whether a user sees the generated report, as the scheduled report file could have left the SAP SuccessFactors system (for example, if it is scheduled to an FTP destination or an another external


source). It is also not tracked if the report is downloaded multiple times – still only one set of logs are produced (as the report was generated only once). Recurring scheduled jobs are logged each time a report is generated.

● View online: When an Table report with sensitive fields is viewed online, the entire report content is logged. We do not track how many pages the user browses or scrolls through.○ If storing of read logs fails “half way through”, then user can see the records which have been logged. For

example, if a report has 1000 rows, but only the first 300 rows got logged before an error happened, then the user will see only 300 rows and not the remaining rows.

● Grouped Table reports: Aggregated (grouped) reports are not logged as there is no user context. If you add one of the following userfields in combination with a sensitive field, data access is logged:○ First name○ Last Name○ Middle Name○ Username○ UserID

For Recruiting Management reports, the following fields are marked as userfields:○ Candidate ID○ Candidate Name○ Candidate email○ Candidate SSN○ Application ID

NoteLogging happens only for aggregated reports if the userfield is part of the visible report result. There will be no logging for aggregated reports if the userfield is only used in the aggregate function (for example, “count of UserID”) or as a filter.

● Null Values: Null values are not logged because all fields which the user is not allowed to see come back as Null values in the report.

● Special behavior of sensitive fields: Sensitive fields in the following Table reporting schemas are blanked out instead of read logged.○ Performance Management○ Goal Management○ Calibration○ Succession○ Compensation Planning○ Variable Pay

Parent topic: Read Audit in Reporting [page 341]

Related Information

Read Audit in Advanced Reports (Realms) [page 343]Read Audit in Story Reports [page 344]Protecting Personal Data in Spreadsheet Reports [page 345]Disabling Sensitive Fields in List Views [page 346]


Read Audit

Sensitive Label for Fields in the Canvas Reports [page 347]

6.7.2 Read Audit in Advanced Reports (Realms)

Read audit logging applies to all reports that contain sensitive data in advanced reports (realms).

We log read actions to the read audit log for sensitive data in advanced reports (Realms). Logging includes reports with sensitive fields that are used in grouped reports or calculated columns. When there is more than one sensitive field, a log is registered for each sensitive field.

NoteThe Legacy Employee Central Reporting user interface and data model (ODS) does not support read audit and data blocking. Please migrate to the latest Employee Central Reporting user interface and data model (Realms).

● All sensitive fields accessed in a report are logged. This includes sensitive fields used in a grouped query, an aggregation or in a calculated column.

● Null values are not logged. Exception to this rule is if the field is used in a calculation - then it is logged regardless of whether it is null or has a value.

● When a report runs, all results in the report are logged even if user only views the first page (first 10 rows).● In query designer, the preview fetches and logs the first 100 rows of the report even if the user sees only the

first page (= first 10 rows).○ During query design time, the user might preview a query multiple times. Normally, this results in new read

logs being generated on each preview. But sometimes the query result is read from the cache to optimize the performance of the query designer. As a result, there might not be new logs created each time user previews the query result.

● Exporting a query (also from the preview) always creates a new set of read logs.● If a sensitive field does not have proper configuration of the module name, functional area, and functional

subarea, the report is not preview or run. The user sees a generic error on the screen.● Logs from Advanced Reporting log the same values for module name, functional area, and functional subarea

as if the field was accessed via the modules. Only difference is that the "channel"-property in the log is "reporting" and that the “context” fields might be empty in certain cases.

● Logs are stored temporarily in the Advanced Reporting report server and sent to the global storage of read logs. This process can delay the logs from appearing in the reports for read logs. Normally, this delay is not noticeable (few minutes).

● When an Admin enables or disables read audit in the Admin Tool, the change is synced to the advanced reporting solution. There is a delay of 30-60 minutes in the synchronization process.

● When a field is marked as sensitive in the source modules, this metadata needs to be synchronized to the Advanced Reporting solution. This synchronization can take up to 24 hours. Allow a day between marking a field as sensitive and validating that the field is being logged when accessed via advanced reporting.



Related Information

Read Audit in Table Reports [page 341]Read Audit in Story Reports [page 344]Protecting Personal Data in Spreadsheet Reports [page 345]Disabling Sensitive Fields in List Views [page 346]Sensitive Label for Fields in the Canvas Reports [page 347]

6.7.3 Read Audit in Story Reports

Read Audit happens whenever a sensitive field appears in a list report (unaggregated report), or it is used as a filter in the report. If there are more than one sensitive fields, a log is registered for each field.

The log timestamp represents the time for the report query execution (which happens slightly before the report appears or is scheduled for the user). If logging cannot be completed successfully, the user is not allowed to execute the report. The user sees an empty report.

● Aggregated (grouped) reports are not logged even if they show a sensitive field, as there is no user context. If you add one of the following userfields in combination with a sensitive field, data access is logged:○ First name○ Last Name○ Middle Name○ Username○ UserID

For Recruiting Management reports, the following fields are marked as userfields:○ Candidate ID○ Candidate Name○ Candidate email○ Candidate SSN○ Application ID

For Employee Central reports, the following fields are marked as userfields:○ Person First Name○ Person Last Name○ SSN

NoteLogging happens only for aggregated reports if the userfield is part of the visible report result. There will be no logging for aggregated reports if the userfield is only used in the aggregate function (for example, “count of UserID”) or as a filter.

● Read logs are not generated when users infer the values of sensitive fields. For example, read logs are not generated if the available filter values for a query potentially reveal the value of the sensitive fields.

● Aggregated reports are logged only when sensitive fields and personal fields are combined in the same visualization.

● Currently, you need to include context fields (effective date and ID of the user/person/candidate) in the reports, so they can be used for logging.


Read Audit


Related Information

Read Audit in Table Reports [page 341]Read Audit in Advanced Reports (Realms) [page 343]Protecting Personal Data in Spreadsheet Reports [page 345]Disabling Sensitive Fields in List Views [page 346]Sensitive Label for Fields in the Canvas Reports [page 347]

6.7.4 Protecting Personal Data in Spreadsheet Reports

Spreadsheet reports (also known as RDF reports) are custom built by certified partners for individual customer. These reports do not leverage the Table report framework, so they will not do Read logging.

Prerequisites

To ensure the data exposed in the spreadsheet reports does not access any sensitive data:

● Run each spreadsheet report and review the content.● (OR) Ask your implementation partner to review the report content.

Context

To find the spreadsheet reports / RDF reports,

Procedure

1. If you have enabled report center,a. Go to Reporting.b. Click Switch to classic view.c. Click Spreadsheet Reports.

2. If you have not enabled report center,

a. Go to Analytics Reporting .b. Click Spreadsheet Reports.


When read access logging is enabled, the system automatically disables standard RDF reports which contain sensitive data. However, Admins have to review and disable or edit the custom RDF reports manually as described above to ensure that the reports are not exposing any sensitive data.

NoteIf RDF reports (even standard RDF reports) have been copied from another instance, they will be treated as custom reports by the system and will not be disabled automatically.

Already scheduled jobs with RDF reports will not be cancelled. If you have setup recurring jobs, you need to ensure that these jobs do not schedule reports with sensitive data. Please contact SAP Cloud Support to change or delete the scheduled recurring jobs.

Task overview: Read Audit in Reporting [page 341]

Related Information

Read Audit in Table Reports [page 341]Read Audit in Advanced Reports (Realms) [page 343]Read Audit in Story Reports [page 344]Disabling Sensitive Fields in List Views [page 346]Sensitive Label for Fields in the Canvas Reports [page 347]

6.7.5 Disabling Sensitive Fields in List Views

You can disable fields in list views in from the List View Admin tool. You need to disable any fields that your organization consider sensitive.

Procedure

1. Go to Admin Tools List Views .2. Click Employee List.3. Disable the sensitive fields.4. Perform the above steps for all other list views.

Task overview: Read Audit in Reporting [page 341]


Read Audit

Related Information

Read Audit in Table Reports [page 341]Read Audit in Advanced Reports (Realms) [page 343]Read Audit in Story Reports [page 344]Protecting Personal Data in Spreadsheet Reports [page 345]Sensitive Label for Fields in the Canvas Reports [page 347]

6.7.6 Sensitive Label for Fields in the Canvas Reports

In the Canvas reports, sensitive fields are shown with SENSITIVE label when you build a query.

The SENSITIVE label helps report creators from using sensitive data in reports, unless it is really needed.


Related Information

Read Audit in Table Reports [page 341]Read Audit in Advanced Reports (Realms) [page 343]Read Audit in Story Reports [page 344]Protecting Personal Data in Spreadsheet Reports [page 345]Disabling Sensitive Fields in List Views [page 346]


7 Information Report

Learn how you can compile a report containing all the personal data that is stored on an employee.

Companies store all kinds of personal data on their employees, from basic information like name and address to more potential sensitive information such as marital status and the results of performance reviews. Employees and former employees have the right to know exactly what personal information has been stored and for what purpose.

If an employee makes such a request, you as the Data Privacy Officer or HR privacy expert need to respond. You can use the Data Subject Information tool to compile a report containing all the personal information that is stored on that employee, and can then provide the report to the employee in PDF or CSV format.

Related Information

Getting Started with the Information Report [page 348]Configuring the Information Report [page 352]

7.1 Getting Started with the Information Report

Before you set up and use the Information Report, there are some general prerequisites you need to complete.

Procedure


Check Item Action

Have you adopted the SAP SuccessFactors Platform? If you haven’t adopted the Platform yet, please get in touch with your SAP contact and ask them to start the process. Note that adopting Platform takes time, so we recommend you start as soon as possible.



Information Report

Check Item Action

Have you enabled Attachment Manager? If you've activated MDF (see above), Attachment Manager has probably been enabled automatically. Please confirm that this is the case in your system, however, and if not then contact SAP Cloud Support and ask them to enable Attachment Manager for you.

Important notes and limitations Important Notes About the Information Report [page 349]

3. Start setting up the Information Report function in your SAP SuccessFactors systems.

7.2 Important Notes About the Information Report

Before you start using the Data Subject Information report, understand the following important notes and how they impact your SAP SuccessFactors system.

Module Limitation

All We recommend that you don’t run the report within 48 hours of hiring or terminating an employee, as in these cases the data gathered by the report might not be fully up-to-date.

All We recommend that you don't try and generate more than 50 reports simultaneously, as this will impact system performance.

All If you want custom MDF objects that contain personal data to appear in the report, you need to make the following settings for the relevant MDF object:

1. In the Admin Center, go to Configure Object Definition History and open the MDF object.

2. Choose Take Action Make Correction , and ensure that API Visibility is set to either Editable or Read Only.

All There are two different types of IDs that a user can have - user ID (which can’t be changed) and assignment ID (which can be changed). If user ID appears in a Data Subject Information report, then, as of the Q4 2019 release, assignment ID will also appear in the report for certain modules.


Setting Up and Using Data Protection and PrivacyInformation Report PUBLIC 349


Module Limitation

Performance Management You can generate information reports for external users. To search for external users, type their name or email address on the Data Subject Information page.

Performance Management You can generate information report only for Performance Management v12 Acceleration forms.

Notewhen the Performance Management features are not enabled in Provisioning, the Information Report generated for internal users does not include the Performance Management data, and an error message appears when running the report for external users.

Performance Management Before, the section and item names were displayed as entity names with sequence numbers in the Information Report. Now, the section and item names for Competency and Objective sections are displayed in the Information Report in the same way they are in the form.

Performance Management You can view the Performance Management and 360 Degree Multi-rater forms deleted by the user, or by using the Delete Forms admin tool. To view these soft deleted forms, select

Include Deleted Forms from Admin Center Role Based

Permission <Permission> Administrator Permissions

Manage Documents .

Performance Management The Information Report for Performance Management does not include custom elements, custom sections, and Employee Profile fields.

Performance Management Currently, the Information Report for Performance Management does not support Signature section comments.

Goals Management Currently, the information Report (data subject report) for Goals Management includes soft deleted data (that is, data that has been deleted but not fully purged). To view the soft deleted data, select Admin Access for Goal ODATA API Export

from Admin Center Manage Permission Roles System

Admin Permission Settings Objectives .


Information Report

Module Limitation

Learning To see Learning data in the centralized platform information report, you must have a learning student ID that matches both learning administrator ID and a platform user system ID. For example, if the platform ID is jdoe, the student ID and the admin ID in Learning should both be jdoe. The student ID should have a role with the Learning security workflow Run User Personal Information Report.

Compensation and Variable Pay Compensation customers can run information reports for any time period for a single user in the Compensation Administration on the View User Personal Statements page.

Recruiting Following are some of the limitations for Recruiting Management:

● Only the first file name is displayed in the report for multi-attachment field types.

● Navigation fields are displaying twice, for example, one with the ID and one with the value.

NoteThe SHARE_PROFILE option is available in the list of records to be displayed in Candidate Profile section.

Succession Planning You cannot generate information reports for external successors (that is, candidates from Recruiting that are assigned as successors).

Succession Planning The information report includes all succession and MDF talent pool nominations for a user regardless of the status of that nomination, but limited to whichever nomination method is currently active in the system.

TipIf you don't want to report on deleted, rejected, or succeeded nominations, you can purge that data before running the information report using the DRTM Succession purge request and the Succession Nominations: inactive nominations only purge object.

Calibration The information report for Calibration does not include ratings from data sources other than Employee Profile. For example, potential rating from Performance Management is not included.


Module Limitation

Onboarding 1.0 For report generation, you can search new hire records through

the Onboardee Search widget in the Admin Center Data

Subject Information tool.

Onboarding For report generation, you can search new hire records through

the Person Search widget in the Admin Center Data

Subject Information tool.

Performance and Goals The latest version of Continuous Feedback supports Data Subject Information Reports.

7.3 Configuring the Information Report

Before you run the Data Subject Information report, you need to specify exactly which fields and entities you want to appear. In this way, you can tidy up your reports so that they don’t contain unnecessary empty sections that aren’t relevant for your company. You can save a different configuration template for each locale, and reports will then be generated based on the template for the data subject's particular locale.

Prerequisites

You have been assigned the following permissions. You find them in the Admin Center under Manage Permission Roles:

● Administrator Permissions Admin Center Permissions Configure/Sort Information on Data Subject

● Administrator Permissions Admin Center Permissions Read Execution Manager Event Payload or Event Report

● Administrator Permissions Metadata Framework Admin Access to MDF OData API

Procedure

1. Go to Admin Center Data Subject Information .2. Here are a few tabs you can use to configure the Data Subject Information report:

On this tab You can

Configuration See all the possible entities that can be displayed for both employees and external candidates. For example, talent rat


Information Report

On this tab You can

ings, team goals, and so on. Click an entity, and you see all the related fields that will be displayed in a report. Ensure that the checkbox is selected for any fields that you want to appear in the report, and that you've specified a purpose for each one.

Note○ The purpose informs the user why you've stored

this particular item of personal data. By default, the purpose simply states the module in which the data is stored (for example, Employee Central), so we strongly recommend that you configure a purpose that more clearly states the specific business reason at your company.

○ If at any point you want to add or remove an entity from the list, you can do so using the On/Off toggle switch.

○ If you configured any customerdefined entities, you'll find them on the Extensions tab.

General Configuration Choose which language the report should be displayed in, the date and time format, and whether blank fields should be included in the report.

Sort Modules Specify the order in which modules should appear in the report.

3. Choose Save.

Results

The configuration settings you made are applied to all reports generated for that locale from now on.

Note● Entities are location-independent. That means if you removed an entity while making your configuration

settings, it will be removed from reports generated in all locales.● In general, we recommend that you don’t configure anything until all currently running reports have

finished generating, as otherwise there's a chance the settings might conflict.


7.3.1 Creating a Custom MDF Object for the Information Report

Create a custom MDF object for the Information Report.

Procedure

1. In Admin Center, go to Configure Object Definitions.

2. Choose Create New Object Definition .3. Under the externalCode field, ensure that the Data Type is set to User.4. Add whatever fields you require to the custom object, ensuring that you always enter externalCode as Subject

User Field.5. Once you've added all the fields you need, save the object definition.

Related Information

Configuring a Custom MDF Object as Legislatively Sensitive Personal Data (LSPD) [page 354]Adding Data to a Custom MDF Object for the Information Report [page 355]Running an Information Report with a Custom MDF Object [page 360]

7.3.2 Configuring a Custom MDF Object as Legislatively Sensitive Personal Data (LSPD)

In order to use a custom object for the Information Report, you need to configure it as Legislatively Sensitive Data (LSPD).

Procedure

1. In Admin Center, go to Configure Object Definitions.

2. Choose Create New Legislatively Sensitive Data Configuration .3. Enter the following:

○ Object Type: The external code of the object you created for the Information Report.○ Data Subject Field: externalCode○ Data Subject Field Type: User○ Module Name: The relevant module name. For example, Employee Central.○ Functional Area: The relevant functional area. For example, Employment Information.


Information Report

4. Save the configuration and carry out OData API Metadata Refresh And Export.

Related Information

Creating a Custom MDF Object for the Information Report [page 354]Adding Data to a Custom MDF Object for the Information Report [page 355]Running an Information Report with a Custom MDF Object [page 360]

7.3.3 Adding Data to a Custom MDF Object for the Information Report

Add data to a custom MDF object for the Information Report.

Procedure

1. In Admin Center, go to Manage Data.

2. Choose Create New cust_gdpr .3. Add all the necessary details, and ensure that you enter the corresponding user in the externalCode field.4. Save the object.

Related Information

Creating a Custom MDF Object for the Information Report [page 354]Configuring a Custom MDF Object as Legislatively Sensitive Personal Data (LSPD) [page 354]


7.4 Running the Information Report

Compile a report containing all the personal information your company has stored on a particular employee or external candidate.

Prerequisites

● You have been assigned the following permissions as necessary. You find them in the Admin Center under Manage Permission Roles:

If you want to Then you need these permissions

Access and run the report ○ Administrator Permissions Admin Center

Permissions Search Information on Data Subject

○ Administrator Permissions Admin Center

Permissions Read Execution Manager Event Payload

○ Administrator Permissions Metadata Framework

Admin Access to MDF OData API

Gather personal data from Goals Goals Admin Access for Goal ODATA API Export

Gather personal data from Calibration Manage Calibration > OData API Calibration Export

NoteIf you want to include talent ratings in the report, you

also need the permission Manage Documents

Admin Access to Talent Rating OData API .

Gather personal data from 360 Degree Multi-Rater Manage Documents Admin Access to Forms OData

API

Gather personal data from Performance Management Manage Documents Admin Access to Forms OData

API

Gather personal data from Continuous Performance Management

Manage Continuous Performance Admin Access to all

Continuous Feedback Data

Gather personal data from Succession Planning (All) Under Succession Planners, choose:○ Succession Planning Permission○ Succession Management and Matrix Report Permis

sions


Information Report

If you want to Then you need these permissions

Succession Planning (MDF Positions) Under Miscellaneous Permissions Position , choose:○ View Current○ View History○ Create○ Correct○ Delete

Succession Planning (MDF Talent Pool) Under Miscellaneous Permissions Talent Pool , choose:○ View Current○ View History○ Create○ Correct○ Delete

Under Succession Planners, choose:○ View Talent Pool nominations

Gather personal data from Career Development Manage Career Development Admin Career

Development Plan Export Data

Gather personal data from Employee Profile Manage User Export Extended User Information

NoteEnsure that you have the permissions set to run information reports for a specific solution.

● You have been assigned a role that can access personal data for employees in your company. If you don’t have this role, any reports you generate will contain errors.

● You have configured the report as described in Configuring the Information Report [page 352].

Procedure

1. There are two ways to access Data Subject Information, depending on which version of the Admin Center you’re using.

Version of the Admin Center Where to find Data Subject Information

NextGen Admin On a tile directly in the Admin Center

OneAdmin Under Admin Tools

2. Once in the tool, go to the Data Subject Search tab.3. Depending on who you want to generate a report for, choose either Person Search (for Onboarding internal

employees and external users) or External Candidate Search (for people who have applied for a position at your


company) or Onboardee Search (for Onboarding 1.0 new hires who have not completed employment verification).

4. Start typing the person’s name, and then select them from the drop-down list of suggestions.

The list of people you can see here depends on the role-based permissions you've been assigned.5. Choose Generate Report.

Results

The reports run in the background. It might not appear on the Report tab immediately, in which case you can try refreshing the screen or waiting a few minutes. Please do not resubmit the report right away, as this will cause multiple copies of the same report to build up in the queue.

Related Information

List of Role-Based Permissions

7.4.1 Running an Information Report with Workforce Analytics Data

Generate data subject information report with the personal data stored in Workforce Analytics. The tool is targeted for the Data Protection Officer (DPO).

Procedure

1. Go to Admin Center Data Subject Information .

2. Click Configure Analytics .3. Click Workforce Analytics Data.


Information Report

https://help.sap.com/viewer/b569eee64d3f4159b2b5272ba7d6b127/latest/en-US/d77b76e71cf54201a4049906b9d8145a.html

4. In the Workforce Analytics section of the data subject information reporting tool, you can see all fields (that are configured in Workforce Analytics) listed. On this configuration page, the Data Protection Officer (DPO) can:a. Select the fields data that should show up on report using the Searchable checkbox.b. Mark up to three fields Searchable.

NoteMark at least one field Searchable before you can search for users. You can search for a data object using the fields you select as Searchable.

c. Add a purpose for each field.5. Click Save and go to Data Subject search.6. Click Workforce Analytics search.

7. Enter the search criteria.Matching records are listed.

8. Select user records and click Generate Report.9. Click Reports.


The Report with user name is generated. The report name is in the format SearchField1_SearchField2_SearchField3_DATETimeStamp

10. Download the report in PDF or excel format.

Results

After one or more fields are marked as Searchable, you can search for a particular user and generate a data subject information report for that user. The report contains a new dataset for each dateeffected change that has occurred to the user as this is how Workforce Analytics stores data at the lowest level.

7.4.2 Running an Information Report with a Custom MDF Object

Procedure

1. Go to Admin Center Data Subject Information .

2. Choose Configuration Extensions .3. Select the custom MDF object from the pane on the left-hand side.

If the object doesn't display correctly on the first try, choose Refresh Configuration.4. Generate a report for user for which you added the data in Adding Data to a Custom MDF Object for the

Information Report [page 355].

The report will contain the custom data you specified. For example:

Related Information

Creating a Custom MDF Object for the Information Report [page 354]Configuring a Custom MDF Object as Legislatively Sensitive Personal Data (LSPD) [page 354]Adding Data to a Custom MDF Object for the Information Report [page 355]


Information Report

7.4.3 Target Populations for Information Report

When a Data Protection Officer runs or accesses the Data Subject Information report, they will only see data for employees they're responsible for.

For example, let's say Data Protection Officer #1 is allowed to see data for target population A and B when running the People Search, and Data Protection Officer #2 is allowed to see data for target population B and C.

Reports for this target population Will be seen by

A Data Protection Officer #1

B Data Protection Officer #1 and Data Protection Officer #2

C Data Protection Officer #2

NoteWhen running the external candidate search, the onboarding and offboarding search, or the WFA reports search, Data Protection Officers will only be able to see reports they have generated. They will not be able to see reports generated by any other officer.

7.5 Downloading the Information Report

Once you’ve run the Data Subject Information report, download it and then provide it to the person that requested it.

Prerequisites

You have been assigned the Print Information On Data Subject permission. You can find this in the Admin Center under Manage Permission Roles Administrator Permissions Admin Center Permissions Print Information on Data Subject .

Procedure

1. In Data Subject Information, go to the Reports tab.

You see a list of results organized chronologically, including the name of the person on which the report has been compiled. Under Status, you can see whether the report has been successfully compiled, compiled with warnings (for example, missing information due to lack of relevant permissions), or failed.


NoteIf a report has failed and you want to determine why, choose View Job in Execution Manager. This displays a log containing all the info gathered by the report, as well as the potential causes of the failure.

2. Under Actions, choose whether you want to download the report in PDF or CSV format.

Results

You have a report containing all the personal data that your company stores on a particular person. You can then provide the report directly to the person who requested it.

Note● The default max file size for a report is 5MB. If a report exceeds that size, then the file will be split. If you

want, you can increase this limit to 10MB using the Attachment max file size setting in Provisioning.● Reports are always generated in the language of the data subject's locale.● Downloaded reports are stored in the same online repository you use for other document types such as

resumes and work permits. As such, the number of reports you can store is directly limited by the capacity of your repository.

7.6 Creating an Information Report for Career Site Builder

Learn how to create information reports for Recruiting Marketing.

Prerequisites



NoteIf Career Site Builder is integrated with SAP SuccessFactors Recruiting, run a separate report from each to get complete data. Most of the data is duplicated between the two reports, but for candidates configured with Candidate Account Simplification, the Career Site Builder report has data related to Agents for Talent Community Members.

Check that you have the correct permissions. This feature is available in the Career Site Builder and for Client Admins with the permission Data Subject Reports available as a sub-permission in Data Privacy & Security Settings.


Information Report

Procedure

1. In the Career Site Builder, choose Tools Data Privacy & Security Settings Data Subject Reports .

2. NotePartial and multiple email address matching is not supported in the search results and the search will start only when the string entered resembles a valid e-mail address.

In User Search, you can search for Talent Community Members or Client Admins users. You use their e-mail addresses.

3. Select the required report locale.4. Download the individual's Information Report as required.

Results

Career Site Builder generates an information report containing details such as first name, last name, created by, created by API, Agents Information.

7.7 Auditing User Information Stored in SAP SuccessFactors Learning for Native Users

If you have native users, you can run the personal information report from SAP SuccessFactors Learning.

Context

We recommend that you run the information report in SAP SuccessFactors platform. Some customers, however, must run the report in Learning because they have native-only users: users who do not have a record in platform. When you run the report from within Learning, you see the Learning information only.

NoteYou run User Personal Information on one user at a time. You cannot schedule it as a recurring job or customize it.

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go Reports.


2. Find and open User Personal Information.

NoteWe also offer a report called User Personal Information Change in the same group. It is for reporting changes over time to personal information; not the current information alone.

3. To hide user IDs from the results of the report, select Mask User IDs.4. Locate the field that corresponds to the type of user whose personal information you want to report.

○ If you want to report the personal information of a learner, select the user's ID in User.○ If you want to report the personal information of an administrator, select the administrator's ID in Admin

ID.○ If you want to report the personal information of an instructor, select the instructor's ID in Instructor.

5. In Additional Data, select the type of data that you want to see in the report.

This Choice Retrieves this data

Personal Information Personal information includes phone numbers, email addresses and so on. If you are using finance features, you also see financial information.

Learning Assignments Learning assignments include the courses a learner is assigned.

Learning History Learning history includes the courses that a learner has completed.

6. Click Schedule Job.

7.8 Downloading Information Reports for Compensation Statements

You can view a list of Compensation, Variable Pay and Combined Statements, and download Information Reports for any time period for a single user on the View User Personal Statements page. You can also download all the statements together for any defined time period.

Prerequisites

● Ensure that the View User Personal Statements option is enabled on the Permission setting page.● The statements MUST be created using the SAP SuccessFactors Compensation Statements templates.


Information Report

Context

To get a single Compensation, Variable Pay, or Combined statement for a user, you can still download the statements from the Employee Files page. You can also download Personal Compensation Statements, Personal Variable Pay Statements, and Personal Combined Statements in the PDF format in People Profile.

NoteCompensation Personal Statements, Variable Pay Statements and Combined Statements are not supported in Mobile.

Procedure

1. Go to Admin Center.2. In the Tools Search Field, type Compensation Home.

3. Under Plans, choose a template.

4. Click Action- All Plans Action for all plans .

5. On the Action for all plans page, click Import/Export Data View User Personal Statements .6. In the User Search field, type a user’s name.7. From the Statement Type dropdown, choose the type of statements to view

By default, the type is set to All.8. To get statements for a specific period of time, enter the Start Date and End Date fields.9. Click Get Statements.

You can download all the generated statements at once by clicking Print All.


8 Consent Agreements

Consent agreements inform individuals that the software is storing their personal data, and explain why this is necessary.

Software applications need to store personal data for various reasons. Informing individuals and explaining why are important from a data protection and privacy perspective. One way to do this is with a consent agreement that appears when an individual opens an application for the first time.

Create and configure data privacy consent statements in SAP SuccessFactors to let individuals know exactly what personal data becomes stored if they proceed. They can then make an informed decision about whether to continue.

Related Information

Creating Data Privacy Consent Statements [page 369]

8.1 Getting Started with the Consent Agreements

Before you set up and use consent agreements, there are some general prerequisites you need to complete.

Procedure

1. Familiarize yourself with your local data protection and privacy laws.2. If you haven’t adopted the SAP SuccessFactors Platform, communicate with your SAP contact to request a

start of the process.

RecommendationStart this process as soon as possible, because adopting SAP SuccessFactors Platform takes time.

3. In your SAP SuccessFactors system, go to the Upgrade Center and enable the Extension Center to activate MDF automatically.

4. Read and understand the impact of configuring consent agreements for various SAP SuccessFactors modules by referring to Important Notes About Consent Agreements.


Consent Agreements

Results

You're now ready to start setting up data privacy consent statements in your SAP SuccessFactors system.

Related Information

Important Notes About Consent Agreements [page 367]

8.2 Important Notes About Consent Agreements

Before you start using consent agreements, understand the following important notes and how they impact your SAP SuccessFactors system.

Modules Limitation

All Consent is available for Learning, Onboarding (ONB), and Performance Management, as well as Recruiting (including Recruiting Posting). Career Site Builder uses consent agreements configured through Recruiting.


Learning If you're a Learning customer and you have not adopted platform, you can set up consent for native users but you cannot set up consent if you have adopted platform.Set up consent for Learning Sites users in Learning, even if the users are stored in platform. Sites are pages where your extended enterprise can find training. They’re different from Learning Marketplace.

Setting Up and Using Data Protection and PrivacyConsent Agreements PUBLIC 367


Modules Limitation

Onboarding 1.0 Onboardees can be required to acknowledge an internal, external, or login consent statement prior to entering any data in Onboarding.The Data Privacy Consent feature isn’t enabled by default for all new customers. Administrators must enable the Data Pri

vacy Consent feature in On/Offboarding Settings

Features .The consent statement can be updated by the administrator on the backend in the administrative interface where the consent statement is created. Administrators have access to previous versions of the consent statement and administrators can set statements to be effective for a specific country/region.The platform feature covers the login to the SAP SuccessFactors Platform but doesn't cover the current Onboarding product data panels. Before using the pre-day one feature in Onboarding and before they become an employee, users aren’t actually logging into the SAP SuccessFactors HXM Suite. Users, however, provide information. Onboarding captures user data through the Onboarding data panels.

Onboarding Specific consent statement should be created for type Onboarding external. It will be applicable for new hires until they’re hired.

Administrators must enable the Data Privacy Consent feature for Onboarding.

Note

In Admin Center Set DPCS Statement Status , when you search for Onboarding users, the search result displays the Onboarding external users only. Once the user is hired and becomes an internal user, there’s no use of setting the Onboarding Data Privacy Consent Statement status as Accept/Decline. However, in View History and View Audit Log page, when you search for Onboarding users, the result displays only the external users.

Recruiting Limitations in SAP SuccessFactors Recruiting for consent statement in-progress pass-throughs:

● Not valid for non-workbench scenarios.● Not supported for OData and Imports.● Not supported for DRM 1.0.

If your Career Site Builder is not integrated with Recruiting, create and configure your consent statement using the Data Privacy Consent Statement page within Career Site Builder.


Consent Agreements

Modules Limitation

Succession Planning For Succession Planning via Recruiting that's configured to allow nomination of external candidates – ff your Recruiting solution is configured to send email notifications when candidates are created manually, that also includes any candidates created as a result of being added as external successors in Succession Planning.

8.3 Creating Data Privacy Consent Statements

Create data privacy consent statements (DPCS) to display a popup message that explains how your organization handles personal data.

Prerequisites

● Enable the Provisioning Company Settings Data Privacy Consent Statement 2.0 option (not the deprecated 1.0 version).


● You have the Data Privacy Consent Statement Settings permission.

NoteTo know the permissions that are required for your solution, refer to List of Role-Based Permissions from the Related Information section of this page.

Context

When individuals choose to decline the consent statement, they can't log in or enter any of their data into the SAP SuccessFactors system.

Procedure

1. Go to the Admin Center.


2. Enable the relevant checkboxes to control the Data Privacy Settings for your solution.3. Enter Data Privacy Statement in the Tools Search field, then select it in the search result to access the

tool.

The Manage Data Privacy Consent Statements screen appears, and allows you to manage and create new statements. The screen also displays all your consent statements, as well as your deleted statements.

4. Select Create New Statement to open the screen to configure General Settings and Statement Message.5. Configure the fields in the General Settings section:

Option Description

Name The name of the statement. Once you create the statement, you can’t change the Name field.

Type Choose a consent statement type from the following list:

○ Login – displays a statement when individuals first log in to SAP SuccessFactors. They must accept the statement to use the SAP SuccessFactors system.

○ Recruiting Internal – displays a statement before internal candidates complete a candidate profile or apply for a job.

○ Recruiting External – displays a statement to external candidates, which they have to accept before they can create a candidate profile.

○ Third Party – displays a statement before a third-party user can enter their data.○ Onboarding Internal – displays a statement to Onboarding 1.0 internal users, which they have to accept

before they can enter their data.○ Onboarding External – displays a statement to Onboarding 1.0 external users, which they have to accept

before they can enter their data. Onboarding has consent statements that are specific to onboarding external users until they’re hired. This statement displays to onboarding external users, which they have to accept before they can enter their data.

NoteYou can select this option only if you have enabled Onboarding in your system.

Redirect URL for Decline

Enter a site address for users who decline the Data Privacy Consent Statement.

URLs must start with http:// or https://. If your redirect URL isn’t valid, an error message displays and you can't save or publish the statement.

RememberIf you select Onboarding Internal or Onboarding External, you must provide a redirect URL for users who choose to decline the consent statement.

Assigned Countries/Regions

A statement displays when an individual's country/region matches the country/region configured for the statement. You can only configure one statement per country/region for each type of statement (Login, Recruiting Internal, Recruiting External, Onboarding Internal, and Onboarding External). The Set this as system default statement checkbox lets you set a default statement for employees not associated with a country/region, or for employees who are in a country/region that hasn’t been associated with a statement.

You've completed the General Settings section.

6. Select Statement Message to create the default statement.7. Enter a title in the Title for the default statement.8. Enter the text for the default statement in the Statement Message field.


Consent Agreements

The default statement displays when a statement isn’t available in a person's chosen (default) language.9. Select Print Preview to display a preview of your statement.10. Choose Add Language to add translated statements, and select from the configured languages in the

dropdown list.

Enter the translated Statement Message for each language.11. Choose Save As Draft to save your work if you aren’t ready to publish.12. Choose Save & Publish when you’ve added all the translations and you’re ready for the statement to appear.

Unpublished statements aren't visible. Each time a statement is published, a new version is created.

Related Information

Setting Up and Using the Consent Statement Life Cycle in SAP SuccessFactors Learning [page 383]Enabling Data Privacy Consent for Onboarding [page 375]Important Notes About Consent Agreements [page 367]List of Role-Based Permissions

8.4 Viewing and Editing Data Privacy Consent Statements

SAP SuccessFactors administrators can manage existing and deleted data privacy consent statements.

Prerequisites

● There's at least one consent statement.● You have the Data Privacy Consent Statement Settings permission.

Context

The Manage Data Privacy Consent Statement screen allows organizations to present users with a notification that details how they handle personal data. You can manage existing and deleted consent statements, as well as view the history of these statements and delete them.

Procedure

1. Go to Admin Center Tools , then search for and select Data Privacy Statement.


https://help.sap.com/viewer/b569eee64d3f4159b2b5272ba7d6b127/2111/en-US/d77b76e71cf54201a4049906b9d8145a.html

The Manage Data Privacy Consent Statements screen appears.2. Select the DPCS Statements tab to view the following columns:

Option Description

Name The name of the consent statement.

Active Indicates whether the consent statement is in active use.

Type The type of consent statement: Login, Recruiting Internal, Recruiting External, Third Party, Onboarding Internal, or Onboarding External.

Show At Every Login

Indicates whether the Login type displays every time users log in.

Assigned Countries/Regions

The number of assigned countries/regions for a particular consent statement.

Last Modified The last date a particular consent statement was modified.

Action Options in this column are:

○ View History – allows administrators to view the history log of the selected published consent statement, which includes the following:○ All versions of the statement.○ Version numbers.○ Name of the administrator who published the consent statement.○ The Audit Log column. View Audit Log displays the audit log for an Internal or External user, or to

view all users who have accepted or declined a particular consent statement.○ Delete – deletes the consent statement.

3. Use the dropdown list to select the type of user: Internal users or External users.4. Enter a user name in the search field.

The search field display possible matches as you begin to enter a name. Choose from this list select Search.

The search results show the following columns:○ First Name○ Last Name○ Username/Candidate○ Date – the date and time that the user accepted or declined the consent statement.○ Language – the language of the consent statement.○ Action – shows the accept or decline action performed by the user.○ Initiated By – the name of the person who performed the Accept or Decline action for the consent

statement.Administrators can select Download detailed report to download, view, and save a log file (dpcs_log_report.csv) with the search results on the View Audit Log screen.


Consent Agreements

8.5 Setting the Data Privacy Consent Statement Status

Administrators can set or change the status of data privacy consent statements (DPCS) on behalf of users.

Prerequisites

● Enabled the Provisioning Company Settings Data Privacy Consent Statement 2.0 option (not the deprecated 1.0 version).


● You have the Data Privacy Consent Statement Settings permission.● You understand how to create and manage consent statements through theManage Data Privacy Consent

Statements screen.

Context

When individuals don't log in themselves, they don't see the consent statement to accept or decline it. In such situations, an administrator can accept or decline the consent statement on their behalf through the Set DPCS Statement Status screen.

Procedure

1. Go to Admin Center Tools , then search for and select Set DPCS Statement Status.

The Set DPCS Statement Status screen appears. The screen allows an administrator to accept or decline a consent statement on behalf of a user.

2. Use the dropdown list to select the type of user: Internal users, External users, or Onboarding users.3. Enter a user name in the search field.

The search field display one or more possible matches as you begin. Choose a user name from this list of results and select Search.

The search results show the following columns:○ Statement – the name of the consent statement for the specific user.○ Type – the type of user: Internal, External, or Onboarding.○ Publish Date – the publication date of the consent statement.○ Published By – the name of the Admin user who published the consent statement.


○ Status – the status of the consent statement, the values are:○ Not Presented – this status appears until individuals log in and view, then accept or decline the consent

statement. SAP SuccessFactors prevents those who decline the consent statement from logging in. If they try to log in again later, the consent statement reappears.

○ Accepted○ Declined

○ Action – the View Statement option allows administrators to view the specific consent statement for the user. The column also includes Accept and Decline.

4. Optional: Choose a status in the Action column:

Option Description

Accept Allows an administrator to accept a consent statement for the user.

Decline Allows an administrator to decline a consent statement for the user.

8.6 Deactivating User Consent in Performance Management

The only functionality in Performance Management that requires user consent the Ask for Feedback feature when it's used by an external user.

Context

Ask for Feedback sends e-mail to users asking for feedback, and recipients can reply directly to that e-mail with their feedback.

If you don't want to maintain consent agreements for Performance Management, disable Ask for Feedback for external users who don't have login access to the system. Doing so will remove them from your review process when asking for feedback.

Procedure

1. Go to Admin Center.2. Go to Form Template Settings and select the Performance Management template for which you want to disable

external user feedback.3. Enable Disable the external email address feedback option.


Consent Agreements

8.7 Enabling Data Privacy Consent for Onboarding

Administrators must enable the Data Privacy Consent feature for Onboarding.

Context

The Data Privacy Consent feature is not enabled by default for all new customers.

Procedure

1. Go to On/Offboarding Settings Features .2. Under Misc (Miscellaneous), click Data Privacy Consent.3. Click Activate to enable the Data Privacy Consent feature.

8.8 Enabling the Data Segmentation Field of Recruiting Data Privacy Consent Statements

You can add a custom field to your data privacy consent statements. With this field, you can extend the standard statements to include custom defined information.

Prerequisites

● The SAP SuccessFactors Recruiting solution is enabled in your company instance.● The data segmentation feature is enabled in your company instance.● The Data Privacy Consent Statement 2.0 option is enabled in Provisioning.● You have the Data Privacy Consent Statement Settings and the Platform Feature Settings permissions.

Procedure

1. Go to Admin Center Company Settings Platform Feature Settings .

A list of SAP SuccessFactors Platform features displays.2. Select Enable the Custom Field of Data Privacy Consent Statements.


NoteAs an administrator, you can't deselect the option once the option is selected. To deselect the option, contact Product Supportafter you delete all existing Recruiting data privacy consent statements that are using the Data Segmentation field.


Results

You've successfully enabled the Data Segmentation field for SAP SuccessFactors Recruiting data privacy consent statements.

8.8.1 Creating a Recruiting Data Privacy Consent Statement with the Data Segmentation Field

In addition to the Countries/Regions field, now you have one more dimension — custom fields — to create data privacy consent statements.

Prerequisites

● The SAP SuccessFactors Recruiting solution is enabled in your company instance.● The data segmentation feature is enabled in your company instance.● The Data Privacy Consent Statement 2.0 option is enabled in Provisioning.● You have the Data Privacy Consent Statement Settings permission.● The Enable the Custom Field of Data Privacy Consent Statements is enabled in Admin Center.

Procedure

1. Go to Admin Center Company Settings Data Privacy Statement .

The Manage Data Privacy Consent Statements page displays.2. Choose Create New Statement.

The General Settings page displays.3. Provide a name for your statement.

NoteYou can’t change the name when the statement is created.


Consent Agreements

4. Select Recruiting Internal or Recruiting External for the Type field.5. Optional: Provide a URL to redirect candidates if they decline the data privacy consent statement.6. Select countries and regions for your statement.

When a user's country or region matches the country or region configured for the statement, the statement displays.

7. Select from the customized values for the Data Segmentation field.

NoteYou can only create one statement for each combination of a country or region with a customized field.

8. Optional: Set your statement as the default statement.

The default statement displays when a statement isn’t available in the user's chosen language.9. Choose Validate to check whether your statement is duplicated with any previously published statement.

NoteYou can’t publish a statement when it's duplicated with previously published statements.

10. Go to the Statement Message tab to provide a title and message body for your statement.11. To add translated statements for other languages, select Add Language and enter the translated statement

messages for other languages.12. If there’s no duplication with any published statement, you can publish the statement.

You can also choose to save the statement if you aren’t ready to publish it.

Results

You’ve successfully created a Recruiting data privacy consent statement with the Data Segmentation field.

8.8.2 Data Privacy Consent Statements for Career Sites

The data privacy consent statement that appears in the public career site is configured through the Admin Center as long as Career Site Builder is integrated with SAP SuccessFactors Recruiting.

In an integrated system, Career Site Builder contains no fields or settings to configure data privacy consent statements directly.

The instructions in this section are only for a Career Site Builder that is not integrated with SAP SuccessFactors Recruiting.




8.8.2.1 Enabling a Privacy Policy for Career Sites

Enable a setting in Career Site Builder to allow the display of a data privacy consent statement in the public career site.

Procedure

1. In Career Site Builder, go to Settings Data Privacy & Security Settings .2. In the Global section, move the slider for Data Privacy Consent Statement to ON.

Results

You've now enabled a privacy policy for the career site.

Next Steps

You can now create a data privacy consent statement.



8.8.2.2 Creating and Publishing Data Privacy Consent Statements in Career Site Builder

Create and publish data privacy consent statements for candidates to complete during the subscribe or apply process on their Business Card. Only candidates who accept the consent statements can continue subscribing or applying.

Prerequisites

Check that you have the Data Privacy Consent Statement permission.


Consent Agreements

Context



Locales

Configure a consent statement for all your configured locales. If you don't create a statement for a locale, the Publish button doesn't work if you're publishing the consent statements for the first time.

If you add a locale after you've published a statement, you can edit the data privacy consent statement as required — you need not create a new version.

Procedure

1. In the Career Site Builder, go to Tools Data Privacy Consent Statement .2. Select + Add.

You see the Data Privacy Consent Statement Version. New (Draft) page, along with Cancel, Save Draft, Publish and the option to preview.

If Add isn't available, it means you already have a draft version open. You can only have one draft open at any one time.

3. Enter a name for the data privacy consent statement.4. Choose Save Draft.

Your draft version will appear on the right in red with date and time. The locales configured will also appear.5. Select a locale from the left pane, and complete the fields in the Consent Statement Details page that appears:

Option Description

Checkbox Label The text that appears on the Business Card and captures the candidate's consent. An example is I have reviewed the Data Privacy Consent Statement.

External URL (Optional) Use a redirect link to point to an external web page rather than display the data privacy consent statement in the career site page itself. If you enter a value in this field, all other fields except Checkbox Label become non-applicable.

Instructions Appears directly above the consent statement content area to provide candidates with further instructions, such as scrolling if the statement is lengthy.

Disclaimer Appears at the bottom of the consent statement content area. It can describe additional context or information.

Accept Statement

Appears at the bottom of the consent statement content area, and is text that is used for the acceptance button.

Decline Statement

Appears at the bottom of the consent statement content area, and is text that is used for the decline or reject button.


Option Description

Consent Statement

The information required for your consent statement.

NoteIf you change anything in the Consent Statement field in a published statement, you must republish a new version, so that candidates see and can accept your revised consent statement.

You can edit all other fields at any time, however, without republishing the consent statement.

RecommendationTo make it easy for candidates to exercise their right to be forgotten (to have their private information removed), include the link to the Remove PII page (https://<companysite>.com/talentcommunity/managePII/) in either the Accept Statement or the External URL fields.

6. Choose Save.

You've saved your draft consent statement, and can now preview it.7. Repeat this step for each of your locales.8. Select your draft consent statement then choose Publish to publish it.

Publishing a version automatically archives the previous version because you can only have one published version at a time.

8.8.2.3 Things You Can Do With the Data Privacy Consent Statement in Career Site Builder

There are a number of things you can do with the Data Privacy Consent Statement in a non-integrated Career Site Builder to present your own privacy policy for your Talent Community (TC) members, according to your organization's data protection and privacy policy.



Things You Can Do Description

Create a privacy policyPrivacy policies (DPCS) are created per locale in Settings

Data Privacy Consent Statement .


Consent Agreements


See what versions have been published whenIn Career Site Builder, choose Settings Data Privacy

Consent Statement and you will see the versions color coded on the left of the screen:

● Green – current version● Red – draft version● Grayed out – previous version

Stop changes being made to the consent statement The tool doesn't allow you to do this. Making any changes to the Consent Statement field on a published DPCS requires you to republish the statement. This means that you will never have candidates using your site based on an outdated DPCS.

Adding a DPCS for a new locale If a new locale is added after you have published a DPCS, edit the DPCS for the new locale.

Track acceptance of the DPCS Use the following fields in Members Search to find which candidates haven't consented to the current version:

● DPCS Version – possible values are Current and Non Current

● Linked Member – possible values are Linked and Not Linked

Make it easy for members to exercise their "Right to be forgotten" or "Not Accept" a new version of the DPCS

Include the link to the Remove PII page at https://<clientdomain.com>/talentcommunity/managePII/ in either the External URL or Acceptance Statement fields on the DPCS.

Proactively notify members about new versions Use the following fields in Members Search to find which candidates haven't consented to the current version and need to be notified:

● DPCS Version – possible values are Current and Non Current

● Linked Member – possible values are Linked and Not Linked

Find the TC members who have not consented to the latest version of the DPCS

Use the following fields in Members Search to find which candidates haven't consented to the latest version:

● DPCS Version – possible value is Non Current● Linked Member – possible values are Linked and Not

Linked

Add the DPCS to the business card This is done automatically.

Archive previous versions of the DPCS This is done automatically when you publish the new version.



Prevent the manual addition of TC members Disable the switch Allow Manual Public User Creation in

Settings Data Privacy & Security Settings .

Related Information

Creating and Publishing Data Privacy Consent Statements in Career Site Builder [page 378]

8.8.2.4 Import and Export of the Data Privacy Consent Statement

Describes how a published Data Privacy Consent Statement (DPCS) can be migrated from staging to production using Import & Export in Career Site Builder.



● The DPCS can be exported/imported separately from the other features.● You can only export a published DPCS. A drafted or archived DPCS will not be exported.● If you choose to export "From a previous configuration", please note that only the current published

configuration will be exported.

● No backup data for DPCS is maintained. This means that when you export the site data in Tools Import & Export , that you can only export the current configuration for the DPCS.

● The setting for the switch DPCS will not be exported.● Only matched locale data between two instances is imported/exported.● When the DPCS is imported, it will have the status Draft

Related Information

Things You Can Do With the Data Privacy Consent Statement in Career Site Builder [page 380]


Consent Agreements

8.9 Setting Up and Using the Consent Statement Life Cycle in SAP SuccessFactors Learning

Use the Data Privacy Consent Statements (DPCS) life cycle in SAP SuccessFactors Learning if your company seeks consent from users to store personal information.

Procedure

1. Familiarize yourself with your local data privacy laws. After you know how you are legally required to process personal data at your company, you’ll have a better understanding of your need for consent statements.

2. If you learn that you need consent statements, write new consent statements or locate your current consent statements and save them as PDF files.

NoteWe recommend that you create one PDF file for each SAP SuccessFactors Learning locale that you support so that users can read the statement in their native languages.

3. When you have new consent statements, add them as draft consent statements.4. When you are ready to promote the new consent statements to your users, publish them.5. After you have published at least one set of consent statements, enable them for either internal or external

users.6. Periodically, review the consent statements.

Supported Configurations for Consent Agreements in SAP SuccessFactors Learning [page 384]Consent agreements support most configurations for the ways that users sign in to SAP SuccessFactors Learning, but they do not support all configuration.

Adding Data Storage Consent Statements to SAP SuccessFactors Learning [page 385]Add data storage consent for SAP SuccessFactors Learning if your data privacy and protection policies require that users consent to your storage of their personal data.

Publishing Consent Statements in SAP SuccessFactors Learning [page 388]Publish Data Privacy Consent Statements (DPCS) in SAP SuccessFactors Learning when you’re ready to expose them to users for review and agreement.

Enabling SAP SuccessFactors Learning Consent Statements [page 389]Enable SAP SuccessFactors Learning to show data storage consent statements to employees or to users of Learning sites (external users).

Reviewing SAP SuccessFactors Learning Consent Agreements [page 390]Review SAP SuccessFactors Learning consent agreements to make sure that you’re showing users the correct version.

Viewing and Revoking Personal Consent Statements in SAP SuccessFactors Learning [page 391]View and revoke consent statements in SAP SuccessFactors Learning if you previously accepted a consent statement but you changed your mind.


8.9.1 Supported Configurations for Consent Agreements in SAP SuccessFactors Learning

Consent agreements support most configurations for the ways that users sign in to SAP SuccessFactors Learning, but they do not support all configuration.

Summary of Supported Configurations for Consent Agreements

When you enable consent agreements, they are supported in most scenarios except when SAP SuccessFactors Learning is integrated with platform but when users are allowed to sign in through the basic Learning login page.

Detail of Supported Configurations for Consent Agreements

In the following table, the columns have the following meanings:

● Sign In Method: The sign-in method can be either Platform or Learning-only users. It refers to the page that users sign into when they want to use SAP SuccessFactors Learning. Platform sign-in pages are the most common and give the user access to SAP SuccessFactors. A few customers, however, still allow users to log in through the basic Learning login page or through a site login page.

● Tenant Type: Most customers are platform tenants, meaning that they have adopted Platform to integrate with the rest of SAP SuccessFactors.

● User Type: Internal users are employees in your organization or company. External users are part of your extended enterprise and not employees. They access Learning sites for courses.

● User Exists in Platform: A few platform customers continue to create users in Learning as Learning-only users. These users are not known to SAP SuccessFactors Platform.

● Consent Enabled: Is consent agreements enabled for the organization or company?

Sign In Method Tenant Type User TypeUser Exists in Platform Consent Enabled? Details

Platform Platform Internal Yes No External learners cannot sign in from the platform sign-in page.

Legacy Plateau Login

Platform Internal No Yes Not supported


Platform Internal Yes Yes Not supported


Consent Agreements

Sign In Method Tenant Type User TypeUser Exists in Platform Consent Enabled? Details


Platform External No Yes Some platform customers created external users before platform integration was enabled for sites.

8.9.2 Adding Data Storage Consent Statements to SAP SuccessFactors Learning

Add data storage consent for SAP SuccessFactors Learning if your data privacy and protection policies require that users consent to your storage of their personal data.

Prerequisites

Before you upload consent statements, create the consent statements with your legal team and then translate them into each language (locale) in your Learning system. Save the consent statements as PDF files.

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go to System Administration Application Administration Consent Statements .

2. Choose Add Statement.3. In Title type a title to help you and your users understand the consent statement.

For example, type Consent to Store Personal Data.

4. In Title, click the localization icon Open localization popup to translate the title into all available languages.Title is the label for the consent statement when presented to users.

5. In Document Links, choose Add Document Links.6. In Add Document Links, select the language of the consent statement in Locale and then choose Browse to find

and upload the consent statement.7. Choose Upload.

8. For each additional language in your system, choose Add Document Links and repeat the process to upload translated copies of the consent statement.

9. Choose Save as draft.


NoteAlthough you can choose Publish to publish immediately, we recommend that you save it as a draft first. By saving it as a draft, you can see draft, published, and archived statements together before you decide to publish.

10. Choose Back Back to go back to the overview of consent statements.

Guidelines for SAP SuccessFactors Learning Consent Statements [page 386]When you upload a consent statement to SAP SuccessFactors Learning, it should meet the guidelines for usage.

Deleting Draft SAP SuccessFactors Learning Consent Statements [page 387]Delete draft SAP SuccessFactors Learning consent statements when you make a mistake uploading documents and you want to prevent others accidentally publishing bad versions of consent statements.

Personal Data Consent for SAP SuccessFactors Learning [page 387]Personal data consent, which is the ability for users to consent to saving personal data in SAP SuccessFactors works differently for Learning than for other parts of SAP SuccessFactors.

8.9.2.1 Guidelines for SAP SuccessFactors Learning Consent Statements

When you upload a consent statement to SAP SuccessFactors Learning, it should meet the guidelines for usage.

Guideline Description

Accessible to Screen Readers We recommend that you create documents that are accessible to screen readers so that users of screen reader technology can understand the text of the consent statement.

Translated We support multiple languages for consent statements. We recommend that you create a consent statement for each locale that you’ve enabled in SAP SuccessFactors Learning.

Reviewed and archived We track the versions of consent documents to match the version of the consent that a user agreed to with the time and date of consent. We don’t recommend that you use SAP SuccessFactors Learning for the revisions of documents that you pass, for example, among your legal team to develop consent forms. Instead, we recommend that you follow your company process and that you archive according to your company policy.

Parent topic: Adding Data Storage Consent Statements to SAP SuccessFactors Learning [page 385]

Related Information

Deleting Draft SAP SuccessFactors Learning Consent Statements [page 387]Personal Data Consent for SAP SuccessFactors Learning [page 387]


Consent Agreements

8.9.2.2 Deleting Draft SAP SuccessFactors Learning Consent Statements

Delete draft SAP SuccessFactors Learning consent statements when you make a mistake uploading documents and you want to prevent others accidentally publishing bad versions of consent statements.

Procedure


2. Click Draft.

3. For each consent statement file (language) that you want to delete, click Delete .

Next Steps

If you deleted an incorrect statement, you usually want to replace it with the correct statement. Go back to the consents page to upload new drafts.

Task overview: Adding Data Storage Consent Statements to SAP SuccessFactors Learning [page 385]

Related Information

Guidelines for SAP SuccessFactors Learning Consent Statements [page 386]Personal Data Consent for SAP SuccessFactors Learning [page 387]Adding Data Storage Consent Statements to SAP SuccessFactors Learning [page 385]Guidelines for SAP SuccessFactors Learning Consent Statements [page 386]

8.9.2.3 Personal Data Consent for SAP SuccessFactors Learning

Personal data consent, which is the ability for users to consent to saving personal data in SAP SuccessFactors works differently for Learning than for other parts of SAP SuccessFactors.

Personal data consent for SAP SuccessFactors Learning applies, in most cases, to external users: users who access Learning through sites. Internal users are your employees and their consent is usually covered under employment contracts. But if your business needs consent from internal users, we support it.

In SAP SuccessFactors Learning, we simply display the consent documents that you create and record users' agreement to a particular version of the document. Usually with your legal team, you manage the text of the


document, the revision process of the document, and the retirement of a consent document. We recommend that you establish a process for creating and reviewing the consent statements.

Parent topic: Adding Data Storage Consent Statements to SAP SuccessFactors Learning [page 385]

Related Information

Guidelines for SAP SuccessFactors Learning Consent Statements [page 386]Deleting Draft SAP SuccessFactors Learning Consent Statements [page 387]

8.9.3 Publishing Consent Statements in SAP SuccessFactors Learning

Publish Data Privacy Consent Statements (DPCS) in SAP SuccessFactors Learning when you’re ready to expose them to users for review and agreement.

Prerequisites

Before you can publish consent statements, you add them as drafts to the system.

Context

While statements are in draft, they don’t appear to end users. The draft status gives you time to upload the statements, translate the titles of the statements, and so on. When you’re ready to expose the statements to users, you publish them.

Procedure


2. In Statements, click Published to see the consent statements that you’re about to archive.

Although this step isn't required, we do recommend it because the statements that are currently published are automatically archived when you publish the draft versions. Make sure that you're ready to archive all published consent statements.

3. Go back to the list of consent statements.


Consent Agreements

4. Click Draft, and then check all draft statements.

We recommend that you check the draft statements one more time because you’re about to expose them to users.

5. Click Publish.

When you click Publish to publish draft consent statements, the current published statements are archived and the draft statements replace them. Users who agreed to the last published statements must now agree to the new language (the consent statements that you just published). If they do not agree, then they can't access the system.

Related Information

Deleting Draft SAP SuccessFactors Learning Consent Statements [page 387]Guidelines for SAP SuccessFactors Learning Consent Statements [page 386]

8.9.4 Enabling SAP SuccessFactors Learning Consent Statements

Enable SAP SuccessFactors Learning to show data storage consent statements to employees or to users of Learning sites (external users).

Prerequisites

Before you enable consent statements, add at least one batch of the statements and publish them. After you’ve published at least one batch, users can see something when you enable the statements.

Procedure


2. In Application Administration, decide to enable for internal or external users.

Choice Description

Enable for Internal Users Select Enable for Internal Users if you want employees to see the consent statement. This choice is uncommon because employees' consent to store data is often handled by other means, such as an employment contract.


Choice Description

This choice is relevant for Learning-only users. Integrated customers must add consent statements in SAP SuccessFactors Platform. The Enable for Internal Users setting doesn’t apply to integrated internal users.

Enable for External Users Select Enable for External Users if you want your extended enterprise to see the consent and if you’re using Learning sites.

8.9.5 Reviewing SAP SuccessFactors Learning Consent Agreements

Review SAP SuccessFactors Learning consent agreements to make sure that you’re showing users the correct version.

Procedure

1. Go to SAP SuccessFactors Learning Administration and then go to System Admin Application Administration Consent Statements .

2. In Statements, choose Published to see the consent agreements that users currently see.

3. Choose Back Back to go back to the overview of consent statements.4. In Statements, choose Draft to see the consent agreements that you’ve staged but that aren’t yet viewable by

users.

5. Choose Back Back to go back to the overview of consent statements.6. In Statements, choose Archived rows to see the consent agreements that you’ve archived.

TipIn Statements, you can see the date that the archived copies were superseded by a newly published set.

7. Choose Back Back to go back to the overview of consent statements.

Next Steps

If you see anything that needs to be changed, upload new copies of consent agreements and republish. You can’t revert from archived versions.


Consent Agreements

8.9.6 Viewing and Revoking Personal Consent Statements in SAP SuccessFactors Learning

View and revoke consent statements in SAP SuccessFactors Learning if you previously accepted a consent statement but you changed your mind.

Procedure

1. Log in to SAP SuccessFactors and then select Learning.2. Click Options and Settings.3. In Data Privacy Consent, click Data Privacy Consent Statement to view the consent statement that you

accepted.The Data Privacy Consent section also tells you when you accepted the statement.

4. To revoke your consent, click Decline.5. Contact your system administrator to deactivate or delete your account.


9 Data Protection and Privacy in SAP SuccessFactors Learning

SAP SuccessFactors Learning offers these data protection and privacy features. To help you navigate the configuration content, we have collected it in one place.

Feature Description Additional Information

Standard purge process Standard purge of Learning data and users is handled by master data purge and Data Retention Time Management (DRTM) in Platform.


Purge process for native-only users Some Learning customers do not use SAP SuccessFactors Platform as their system of record for users.

When you purge users or user data and you do not use Platform, you configure Automatic Processes in Learning to handle the purge.


Purge Process for Native-Only Learning Configurations [page 228]

Purge process for integrated Learning Sites

Integrated Learning Site users are unusual. Learning Sites are places where your extended enterprise can get access to courses. Integrated Learning Site users are users of those sites that are stored in SAP SuccessFactors Platform so that they can also access SAP Jam and mobile features.


Purge consideration for customers under compliance

Learning allows some customers to preserve a small amount of data after a purge has run. This is extremely uncommon. It is for a small set of customers whose learning compliance time is longer than their purge time.

Enabling the SAP SuccessFactors Learning Audit Purge Log [page 236]

Standard audit reporting If you are using SAP SuccessFactors Platform, then you can follow the standard audit processes.



Data Protection and Privacy in SAP SuccessFactors Learning


Audit reporting for native-only users. Some Learning customers do not use SAP SuccessFactors Platform as their system of record for users. This is unusual.

When you audit data and you do not use Platform, you run reports in Learning.

Data Privacy Auditing for Learning Native Only Customers [page 295]

Standard information reporting If you are using SAP SuccessFactors Platform, then you can follow the information reporting processes.


Information reporting for native-only users

Some Learning customers do not use SAP SuccessFactors Platform as their system of record for users. This is unusual.

When you want to run information reporting and you do not use Platform, you run reports in Learning.

Auditing User Information Stored in SAP SuccessFactors Learning for Native Users [page 363]

Consent statements for all Learning customers.

If you are a Learning customer, you set up consent statements in SAP SuccessFactors Learning Administration.

Setting Up and Using the Consent Statement Life Cycle in SAP SuccessFactors Learning [page 383]

Setting Up and Using Data Protection and PrivacyData Protection and Privacy in SAP SuccessFactors Learning PUBLIC 393

10 Data Protection and Privacy in Metadata Framework

The Metadata Framework offers these data protection and privacy features. To help you navigate the configuration content, we've collected it in one place.


Standard purge process Standard purge of metadata is handled by master data purge and Data Retention Time Management (DRTM) in platform.


MDF custom object purge Whenever you register MDF custom object purge object as a member of a module purge group, the data is purged using MDF custom object purge.

DRTM Data Purge for MDF Custom Objects [page 258]

Things to watch out for in Data Purge As an Admin, we recommend you to review notes about limitations, exceptions, and other details that may apply to MDF.


Setting up data blocking for MDF objects You can configure the roles that will not have full access to historical data for MDF objects.

Setting Up Data Blocking for MDF Objects [page 270]

Change audit If you are using SAP SuccessFactors Platform, then you can follow the standard change audit process.

Change Audit [page 272]

Things to watch out for in change audit As an Admin, we recommend you to review notes about limitations, exceptions, and other details that may apply to MDF.

Important Notes About Change Audit for Personal Data [page 274]

Information Reporting If you are using SAP SuccessFactors Platform, then you can follow the information reporting processes.

Information Report [page 348]

Things to watch out for in information reporting

As an Admin, we recommend you to review notes about limitations, exceptions, and other details that may apply to MDF.

Important Notes About the Information Report [page 349]

Things to watch out for in User Consent As an Admin, we recommend you to review notes about limitations, exceptions, and other details that may apply to MDF.



Data Protection and Privacy in Metadata Framework

11 Data Protection and Privacy in SAP SuccessFactors Recruiting Management

The Recruiting Management offers these data protection and privacy features. To help you navigate the configuration content, we've collected it in one place.


Data Purge

Applications and Candidate Purge in Recruiting

For data protection and privacy in Recruiting, it’s possible to purge candidate profiles and job applications using DRTM. You can configure your instance to use DRTM as per the prerequisites listed here.

Applications and Candidates Purge in Recruiting [page 396]

Purging audit data for both active and inactive users

To use DRTM audit purge, you should configure a retention time for audit data in Recruiting.

Purge of Audit Data [page 44]

Things to watch out for in data purge As an Admin, we recommend you to review notes about limitations, exceptions, and other details that might apply to Recruiting.


Veto behavior in data purge A veto prevents data from being purged from the system.

Veto Behavior in Data Purge [page 110]

Change Audit

Change audit If you’re using SAP SuccessFactors Platform, then you can follow the standard change audit process.

Change Audit [page 272]

Things to watch out for in change audit As an Admin, we recommend you to review notes about limitations, exceptions, and other details that might apply to Recruiting Management.


Information Report

Information Reporting If you’re using SAP SuccessFactors Platform, then you can follow the information reporting processes.


Setting Up and Using Data Protection and PrivacyData Protection and Privacy in SAP SuccessFactors Recruiting Management PUBLIC 395


Things to watch out for in information reporting

As an Admin, we recommend you to review notes about limitations, exceptions, and other details that might apply to Recruiting Management.


Consent Agreements

Things to watch out for in User Consent As an Admin, we recommend you to review notes about limitations, exceptions, and other details that might apply to Recruiting Management.


11.1 Applications and Candidates Purge in Recruiting

For data protection and privacy, it is possible to anonymize candidate profile and applications data using DRTM. The applications will be anonymized based on the criteria defined in Recruiting.

RememberIn Recruiting, all the purge jobs anonymize the data without deleting it.

There are two types of DRTM purge request types for Recruiting:

1. DRTM Inactive Candidate Purge (anonymization) - Candidates are anonymized in Recruiting based on the period of inactivity (logged in date) and candidate's country/region of residency that the candidate selects while creating an account.

2. DRTM Inactive Application Purge (anonymization) - Job applications are anonymized in Recruiting based on their status, the country/region of the job requisition, and the option selected in Admin Center Manage Recruiting Settings (application last modified date, application dispositioned date, or job requisition closure date).

Prerequisites for Purging Applications and Candidate Profiles [page 397]Understand the prerequisites for using candidate and application purge with Data Retention Time Management (DRTM).

Purging Applications in Recruiting Management [page 401]To purge the applications in Recruiting Management, you must create the purge request in Data Retention Management.

Purging Candidate Profiles in Recruiting [page 406]To purge a candidate profile in Recruiting, you must create a purge request in Data Retention Management.

XML Fields That Do Not Support Anonymization [page 410]Review the candidate fields and application fields that do not support anonymization.


Data Protection and Privacy in SAP SuccessFactors Recruiting Management

11.1.1 Prerequisites for Purging Applications and Candidate Profiles

Understand the prerequisites for using candidate and application purge with Data Retention Time Management (DRTM).


Action Description

Enable Data Privacy Consent Statement 2.0 in Provisioning. Go to Provisioning Company Settings and enable Data Privacy Consent Statement 2.0.

Once you enable this feature, the following Withdrawn statuses are added to your application pipeline:

● Declined DPCS● Deleted On Demand By Admin● Deleted On Demand By Candidate● Withdrawn By Candidate

Enable Data Privacy Settings in Provisioning. Go to Provisioning Managing Recruiting Edit Candidate

Privacy Options .

Ensure that you select DPCS 2.0.

Enable Data Retention Management in Provisioning. Go to Provisioning Company Settings and enable Enable Data Retention Management. You can set the minimal number of approvers.

You can also enable this option from Admin Center:Enabling Data Retention Management [page 114]

Schedule RCM Entity Anonymization Job in Provisioning.

Without this job, the following scenarios aren't picked for anonymization:

● Candidates delete their profile.● Candidates decline DPCS.● Admin deletes profiles on behalf of candidates.

1. Go to Provisioning Managing Job Scheduler

Manage Scheduled Jobs .2. Click Create New Job.3. Select the Job Type as RCM Entity Anonymization Job.4. Enter the job name, owner, and the schedule details for

the job.It's a best practice to configure the job to run daily.

5. Click Create Job.


Action Description

Mark the fields for anonymization Go to Admin Center Manage Templates .

For the fields to be anonymized, you must mark them as anonymize="true" in the application and candidate profile templates. For example, you can mark the firstName field for anonymization as shown:

<field-definition id="firstName" type="text" required="true" custom="false" public="false" readOnly="false" anonymize="true">

Note● For candidate profile, if you've mistakenly marked a

field incorrect and anonymize is run, then the only option to rectify this is to use SFAPI to mask the data. OData API isn't supported.

● Once the application is anonymized, you can't make any changes even using SFAPI and OData API.

Enable DRTM Recruiting purge group and purge objects Go to Admin Center Upgrade Center and select DRTM Recruiting under Optional Upgrades.

This creates the Recruiting purge group and purge objects such as Application and Candidate.

Enabling Generic Objects Go to Admin Center Upgrade Center and enable Extension Center.

This activates MDF (Generic Objects) automatically.

Grant role-based permission to access Manage DataGo to Manage Permissions Roles Administrator

Permissions Metadata Framework and select Manage Data.

Grant role-based permissions to allow people to create and/or approve DRTM purge requests

Grant the following role-based permissions under Manage Data Purge:

● Create DRTM Data Purge Request● Manage and Approve DRTM Data Purge Request



Action Description

Grant role-based permissions for:

● DRTM Job Application● DRTM Candidate Profile● DRTM Purge Freeze

Select all the options for Visibility and Actions under User

Permissions Data Retention Management for:

● DRTM Job Application● DRTM Candidate Profile● DRTM Purge Freeze

Do not select field overrides.

Enable Data Retention Time Management for each country/region.

Enable data retention for each country/region for which you need to purge the either candidate or applications data so that you can configure data retention times and create DRTM purge requests for that country/region. Select the desired country/region and set the Data Retention Enabled to Yes.


Configure retention time for job application purge. Before you purge the applications through DRTM, you must configure the retention time for the necessary DRM enabled countries in Manage Data for DRTM Job Application object:

1. Go to Admin Center Manage Data .2. Search for DRTM Job Application and select Application

from the next search box.3. Select the purgeObjectType as Application and enter the

effectiveStartDate.4. For each country/region, configure the Inactivity Time Unit

and Period of Inactivity and save the configuration.

Job applications are purged based on the country/region of the job requisition.


Action Description

Configure retention time for candidate puge. Before you purge the candidate profiles through DRTM, you must configure the retention time (Inactivity period and Period of Non-Acceptance of DPCS) for the necessary DRM enabled countries in Manage Data for DRTM Candidate Profile object:

1. Go to Admin Center Manage Data .2. Search for DRTM Candidate Profile and select Candidate

from the next search box.3. Select the purgeObjectType as Candidate and enter the

effectiveStartDate.4. For each country/region, configure retention times using

the following settings:○ Non Acceptance Time Unit (unit for the Period of Non-

Acceptance of DPCS )○ Period of Non-Acceptance of DPCS (applicable only

for new candidate profiles that are created on behalf of the candidates such as:

Submitted by agenciesReferred by employeesAdded by Add Candidate feature (single/bulk)

○ Inactivity Time Unit (unit for the last login of the candidate)

○ Period of Inactivity (select Details to configure the period of inactivity)

Configure the DRTM purge settings and Deletion of Correspondence Enable or disable the options available under Admin Center

Manage Recruiting Settings DRM 2.0 settings and

Admin Center Manage Recruiting Settings Deletion of

Correspondence .

Parent topic: Applications and Candidates Purge in Recruiting [page 396]

Related Information

Purging Applications in Recruiting Management [page 401]Purging Candidate Profiles in Recruiting [page 406]XML Fields That Do Not Support Anonymization [page 410]



11.1.2 Purging Applications in Recruiting Management

To purge the applications in Recruiting Management, you must create the purge request in Data Retention Management.

Procedure

1. Go to Admin Center Data Retention Management .2. Select the following options for the purge request:

Purge request options Values

Purge request type DRTM Inactive Job Application Purge

Name of the purge request DRTM Inactive Job Application Purge

Define Purge Rule Select the country or region for which you want to purge the inactive job applications.

Add approvers Enter the approver name.

3. You can either launch the purge request immediately or schedule it for the later time.

NoteIf a candidate (both internal and external) is marked for Purge Freeze, the applications belonging to that candidate will not be purged.

For more information on Purge Freeze, see Putting a Legal Hold on Data

Next Steps

To access the list of applications that are picked for purge, go to Admin Center Purge Request Monitor . Admins can approve the purge request, upon which, the applications are purged. To approve or decline the purge request, refer to Approving or Declining a Purge Request.

Task overview: Applications and Candidates Purge in Recruiting [page 396]

Related Information

Prerequisites for Purging Applications and Candidate Profiles [page 397]Purging Candidate Profiles in Recruiting [page 406]


https://help.sap.com/viewer/2becac773fcf4f84a993f0556160d3de/latest/en-US/9fe15a90ecb146048b6cadc44e94d452.html

XML Fields That Do Not Support Anonymization [page 410]


11.1.2.1 Application Purge Behavior

Applications are purged in the Recruiting Management using DRTM based on their status as defined in the table.

When the Status Group is… Status Name is… And the action is…

Application Data of Candidates Attachment Status

Withdrawn Statuses Deleted on Demand By Candidate

Running RCM Entity Anonymization job

On running the job, Applications that marked for anonymization are anonymized except for Disqualified Applications. Applications in disqualified statuses are anonymized based on the retention period that you've configured as part of the DRTM Job Application object.

Applies to both internal and external candidates.

NoteWhen the candidate or admin deletes the profile or when the DPCS is declined, applications are marked for anonymization.

Attachments on applications are deleted.

Deleted On Demand By Admin

Declined DPCS

Withdrawn By Candidate Go to Admin Center

Data Retention

Management Create

New Purge RequestDRTM Inactive

Application Purge

Applications are purged as per the retention period.


When an internal candidate withdraws an application, attachments are deleted.





Go to Admin Center

Data Retention

Management Create

New Purge RequestDRTM Inactive User

Purge


Applies to application data of internal candidates.

In-Progress Statuses Any Any Applications aren’t purged.

Attachments aren’t deleted.

Forwarded Statuses Forwarded, Invited To Apply Go to Admin Center

Data Retention

Management Create


Candidate Purge

The applications get purged when the Candidate Profile gets purged.

Applies to external candidate.

Attachments are deleted.

Go to Admin Center

Data Retention

Management Create


Purge



DraftGo to Admin Center

Data Retention

Management Create


Candidate Purge




Go to Admin Center

Data Retention

Management Create


Purge

System Statuses Default Any Applications aren’t purged.

Attachments aren’t deleted.




Requisition ClosedGo to Admin Center

Data Retention

Management Create


Application Purge

Applications are purged

if the Manage

Recruiting SettingsConsider job applications with the status "Requisition

Closed" for purgingoption is enabled.

Applies only to external candidates.


Go to Admin Center

Data Retention

Management Create


Purge


if the Manage

Recruiting SettingsConsider job applications with the status "Requisition

Closed" for purgingoption is enabled.


Hired On Other Requisition Go to Admin Center

Data Retention

Management Create


Application Purge


if the Manage

Recruiting SettingsConsider job applications with the status "Hired On Other Requisition" for

purging option is enabled.

Applies only to external candidates.






Go to Admin Center

Data Retention

Management Create


Purge


if the Manage

Recruiting SettingsConsider job applications with the status "Hired On Other Requisition" for



Auto DisqualifiedGo to Admin Center

Data Retention

Management Create


Application Purge




Go to Admin Center

Data Retention

Management Create


Purge



OnBoard Statuses AnyGo to Admin Center

Data Retention

Management Create


Application Purge




Go to Admin Center

Data Retention

Management Create


Purge






Disqualification Statuses

AnyGo to Admin Center

Data Retention

Management Create


Application Purge




Go to Admin Center

Data Retention

Management Create


Purge



11.1.3 Purging Candidate Profiles in Recruiting

To purge a candidate profile in Recruiting, you must create a purge request in Data Retention Management.

Context

Inactive candidates can be purged by creating a purge request in Data Retention Management. Inactive candidates are candidates who haven’t logged in to their accounts for the number of days configured as the inactivity period.

For customers who don’t want to lose candidate data by way of the purge action, they can contact the candidates through email asking them to activate their accounts by logging in to the system. It is possible to configure the number of days before the purge date, when email alerts are triggered to notify inactive candidates to take action before their profiles are purged.

NoteThese email notifications aren't triggered for candidates who haven't accepted the Data Privacy Consent Statement (DPCS) for the configured retention time.

Procedure

1. Go to Admin Center Data Retention Management .



2. Select Create New Purge Request.3. Select the following options for the purge request:

Purge request options Values

Select a purge request type DRTM Inactive Candidate Purge

Name of the purge request DRTM Inactive Candidate Purge

Define Purge Rule Complete the following fields:○ Country/Regions: The country or region for which you

want to purge inactive candidate profiles.○ (Optional) Notify candidates before: Enter the number

of days before the purge date, when email alerts need to be sent to inactive candidates before their profiles are purged. These alerts are triggered only once for each candidate.

Add approvers Enter the approver name.

4. If you've specified the number of days in the Notify candidates before field, then configure the Imminent Candidate Purge Notification to send email alerts to candidates.

Note○ Email alerts aren't triggered if you haven't entered a numeric value in the Notify candidates before field,

or if the Imminent Candidate Purge Notification email trigger isn't configured.

5. You can either launch the purge request immediately or schedule it for the later time.

Email alerts are sent to inactive candidates for scheduled purge jobs only. No email alerts are triggered if the purge requests are launched immediately.

Next Steps

To access the list of candidates that are picked for purge, go to Admin Center Purge Request Monitor . Administrators can approve the purge request, upon which, the candidates are purged. To approve or decline the purge request, refer to Approving or Declining a Purge Request.

Task overview: Applications and Candidates Purge in Recruiting [page 396]

Related Information

Prerequisites for Purging Applications and Candidate Profiles [page 397]Purging Applications in Recruiting Management [page 401]XML Fields That Do Not Support Anonymization [page 410]



11.1.3.1 Configuring Imminent Candidate Purge Notification

You can configure email notifications to send to inactive candidates. These email notifications ensure that the candidate can perform necessary actions in advance to avoid the permanent deletion of their profiles from the system.

Prerequisites

Enable Intelligent Services Center framework.

Procedure

1. Go to Admin Center Recruiting Email Triggers .2. Enable Imminent Candidate Purge Notification email trigger.3. Add an appropriate email template based on the notification content that you want to send to the candidates.4. Select Validate Standard Tokens and Save the email trigger.

11.1.3.2 Candidate Purge Behavior

Candidates are purged in Recruiting based on the Application status.

Once the purge request is launched, all the candidates are purged based on the following criteria:

● When the candidate or the administrator deletes the profile.● The candidates who haven’t logged in for the configured retention time (Inactivity Time Unit).● The candidates who haven’t accepted the DPCS for the set retention time (Period of Non-Acceptance of DPCS).

All applications that are associated with the candidates are purged based on the criteria mentioned in the Application Purge Behavior [page 402].

NoteWhen a candidate profile is purged, disqualified applications of the candidate aren’t moved to the status - Deleted on Demand by Candidate. The disqualified applications are purged according to the data retention period defined in the system.

To ensure that the candidate is aware of this, it is recommended that customers mention in their Data Privacy Consent Statement that applications are retained in the system even after the candidate profile has been anonymized. Retaining such unsuccessful or disqualified applications helps to record that the applications were rejected fairly and not due to a bias.



It’s also recommended that the Data Privacy Consent Statement indicates which data isn’t purged and for how long it’s retained.

Using the following options, you can purge external candidate's or internal candidate's profiles:

● To purge external candidate profile, select the purge request types as Purge Inactive Candidate or DRTM Inactive Candidate Purge option.

● To purge the internal candidate profile, you can select the purge request type as Purge Inactive User or DRTM Master Data Purge option.

The candidate is not purged based on the following scenarios:

● For excluding an external candidate profile from being purged in case the candidate has active applications, enable Do not purge if there are existing applications in the system for that candidate option from Admin Center Manage Recruiting Settings DRM 2.0 settings . With this option enabled, candidate profile is purged based on the status of the application that exists for the candidate, as follows:

If the Application Status is ... Candidate profile ... Attachment Status

In-Progress Isn’t purged. Attachments on the candidate profiles are deleted.

Draft, Closed, Withdrawn, Disqualified, Forwarded

Is purged.

Requisition Closed Is purged, if the Manage Recruiting

Settings Consider job applications with the status "Requisition Closed" for


Hired On Other Requisition Is purged, if the Manage Recruiting

Settings Consider job applications with the status "Hired On Other

Requisition" for purging option is enabled.

Note○ When a candidate profile is purged, the Interview data (that includes interview rating, comments, and

notes), background check information, and assessment results are not anonymized.○ If the candidate is marked for purge freeze, that profile is excluded from purge.

● For excluding internal user from being purged, enable User has non-anonymized applications option from Admin Center Data Retention Management Create New Purge Request Purge Inactive User Exclude

users from the following purge criteria .


11.1.4 XML Fields That Do Not Support Anonymization

Review the candidate fields and application fields that do not support anonymization.

Candidate Fields That Do Not Support Anonymization

Field Field Type

Custom Date

Percent

Boolean

Number

Instruction

Currency

Background data fields Date

Int

Float

Application Fields That Do Not Support Anonymization

Field Field ID/Field Type

Standard jobTitle

applicationDate

lastModified

reviewDate

statusId

jobsApplied

Custom Date

Percent

Boolean

Number

Instruction

Currency

Parent topic: Applications and Candidates Purge in Recruiting [page 396]



Related Information

Prerequisites for Purging Applications and Candidate Profiles [page 397]Purging Applications in Recruiting Management [page 401]Purging Candidate Profiles in Recruiting [page 406]


12 Data Protection and Privacy in Time Management

Time Management, comprising both Time Off and Payroll Time Sheet, offers these data protection and privacy features. To help you navigate the configuration content, we've collected it in one place.


Data Purge In Employee Central Time, you can employees' time data completely from the data base.

No chance to get them back, no chance to have any hint in the system what was there before. The data purge is irreversible and should be performed with lots of care therefore. Purging of data is possible for:

● Time Events● Time sheet data● Absence time types● Time account types and time ac

count details● Time alerts● Information on temporary work

schedules● Time account payouts● Time account purchase

Data Purge [page 15]


Data Protection and Privacy in Time Management


Data Blocking You can define different “access periods” for the following objects in Time Management:

● Absences (employee time types of category Absence

● Time Sheet● Time Account Type● Time Account Payout● Time Account Snapshot● Temporary Time Information● Time Alert● Time Collector● Time Account Purchase

For time accounts, time types with the category Absence, and time account snapshots, you can define the access period at type level.

Data Blocking [page 266]

Change Audit Change Audit [page 272]

Information Report An employee must be able to get information on all personnel data stored in a system and connected to him or her. To achieve this, a new report is provided that extracts all time-relevant data in the form of a list.


Setting Up and Using Data Protection and PrivacyData Protection and Privacy in Time Management PUBLIC 413

13 Data Protection and Privacy in Employee Central Payroll

Employee Central Payroll offers these data protection and privacy features. To help you navigate the configuration content, we've collected it in one place.


Data Purge In Employee Central Payroll, you can purge employees' master and time data completely from the data base.

No chance to get them back,no hint in the system about which data previously existed. The data purge is irreversible and should be performed with lots of care. Purging of data is possible for:

● Employee master Data● Employee time data● Application logs

Purging Employee Master Data Replicated to Employee Central Payroll [page 210]

Purge of Time Data Replicated to Employee Central Payroll [page 212]

Purge of Application Logs in Employee Central Payroll [page 213]


Data Protection and Privacy in Employee Central Payroll

14 Data Protection and Privacy in SAP SuccessFactors Performance & Goals

SAP SuccessFactors Performance & Goals offers these data protection and privacy features. To help you navigate the configuration content, we have collected it in one place.


Data Purge Process You can purge Performance & Goals data from your system using the following DRTM objects:

● DRTM Performance Review● DRTM Goal Management Purge● DRTM 360 Review● DRTM Continuous Performance

You can use Master Data purge to purge data of the inactive users in Performance & Goals.

You can also use DRTM Audit Data purge to purge Performance & Goals audit data.


Purging External Users We store some data by or about people who are external to your organization. In Performance Management, you can NOT purge external users identification data, only "Ask for Feedback" responses from external users are purged.

Purge of External Users [page 46]

Things to watch out for in Data Purge As a Performance & Goals administrator, we recommend you to take a look at the Performance Management and 360 Degree Multi-rater limitations and special cases for data purge listed in the "Important Notes" table.


Information Reporting You can follow the standard information reporting processes.


Additional Permissions in Information Reporting

As a Performance & Goals administrator, you need certain permissions to run a report that gathers personal data from Performance Management, 360 Degree Multi-rater and Goals.

Running the Information Report [page 356]

Setting Up and Using Data Protection and PrivacyData Protection and Privacy in SAP SuccessFactors Performance & Goals PUBLIC 415


Things to watch out for in Information Reporting

As a Performance & Goals administrator, we recommend you to take a look at the Performance Management limitations and special cases for Information Reporting listed in the "Important Notes" table.


Change Auditing You can follow the standard change audit processes.


Things to watch out for in Change Auditing

As a Performance & Goals administrator, we recommend you to take a look at the Performance Management and 360 Degree Multi-rater limitations and special cases for Change Auditing listed in the "Important Notes" table.


User Consent In Performance Management the only use case for user consent is when requesting feedback from external users, using Ask for Feedback functionality.

Deactivating User Consent in Performance Management [page 374]


Data Protection and Privacy in SAP SuccessFactors Performance & Goals

15 Data Protection and Privacy in Employee Central Integration with Other Systems Holding Employee Data

Employee Central integration offers these data protection and privacy features. To help you navigate the configuration content, we've collected it in one place.


Data Purge If data is purged in Employee Central that is needed for replication to other systems, integration must react to this. That is, Employee Central's Compound Employee API, the standard integrations we provide for SAP ERP HCM, SAP S/4HANA, and Employee Central Payroll, and the Employee Central Data Replication Monitor used in these integrations all consider data purge.

When configuring retention times for employee data, consider the full transmission start date (FTSD) defined for data replication to other systems: The FTSD should be after the latest retention date of any SAP SuccessFactors entity that is contained in data replication. In other words, no integration-relevant data should be purged after the FTSD. Otherwise, data can no longer be replicated for the employee in question. And if the employee's data was completely purged, this employee can never be replicated again – even if they are rehired later.

Purging data in the replication target system is independent of purging data in Employee Central since retention times might differ in both systems. To purge data in the replication target system, use the default tools provided there. For example, the archiving objects provided for data destruction in the Archive Administration (SARA) transaction in the SAP ERP system.

Data Purge [page 15]

Data Purge in Employee Central Integration with Other Systems Holding Employee Data [page 175]

Setting Up and Using Data Protection and PrivacyData Protection and Privacy in Employee Central Integration with Other Systems Holding Employee Data PUBLIC 417

15.1 Data Protection and Privacy in SAP SuccessFactorsCompensation

SAP SuccessFactorsCompensation offers these data protection and privacy features. To help you navigate the configuration content, we have collected it in one place.


Data Purge You can purge Compensation data from your system using the following DRTM objects:

● DRTM Compensation/Variable Pay Purge

● DRTM Reward and Recognition Purge

You can also use DRTM Audit Data Purge to purge Compensation audit data.


Information Report You can run information reports for a single user, for any time period, in the Compensation Administration on the View User Personal Statements page.

Downloading Information Reports for Compensation Statements [page 364]

Change Audit You can follow the standard change audit processes for Compensation data.


15.2 Data Protection and Privacy in SAP SuccessFactors Employee Central Imports

Employee Central Imports offers these data protection and privacy features. To help you navigate the configuration content, we have collected it in one place.


Data Purge The system automatically purges all the completed import jobs listed on the Monitor Job page depending on the retention period.


418 PUBLIC

Setting Up and Using Data Protection and PrivacyData Protection and Privacy in Employee Central Integration with Other Systems

Holding Employee Data

15.3 Data Protection and Privacy in SAP SuccessFactors Employee Central Apprentice Management

Employee Central Apprentice Management offers these data protection and privacy features. To help you navigate the configuration content, we have collected it in one place.


Data Purge You can purge Employee Central Apprentice Management data from your system using the DRTM Employment Information Purge option.


Information Report You can follow the standard information reporting processes.


Setting Up and Using Data Protection and PrivacyData Protection and Privacy in Employee Central Integration with Other Systems Holding Employee Data PUBLIC 419

16 Data Protection and Privacy in SAP SuccessFactors Reporting

Reporting offers data blocking in some scenarios.


Data Blocking ● The Advanced Reporting framework is enabled to support data blocking.

● Classic Reporting tools do not support data blocking.

● Data blocking does not apply to Table reports that use Group By function.

Important Notes About Data Blocking [page 267]


Data Protection and Privacy in SAP SuccessFactors Reporting

17 Data Protection and Privacy in SAP SuccessFactors Workforce Analytics

Workforce Analytics offers these data protection and privacy features. To help you navigate the configuration content, we have collected it in one place.


Data Purge In Workforce Analytics, the source systems handle data purge, and then those changes are reflected in Workforce Analytics on the next monthly refresh.

When data is purged from the source module, it is also purged from Workforce Analytics on SAP HANA.

Purging the Personal Data in Workforce Analytics [page 104]

Information Report An employee must be able to get information on all personnel data stored in a system and connected to him or her. To achieve this, a new report is provided that extracts all time-relevant data in the form of a list.

Running an Information Report with Workforce Analytics Data [page 358]

Setting Up and Using Data Protection and PrivacyData Protection and Privacy in SAP SuccessFactors Workforce Analytics PUBLIC 421

18 Data Protection and Privacy in Career Sites

Career Site Builder offers these data protection and privacy features. To help you navigate the configuration content, we have collected it in one place.




IP field handling To prevent any Personally Identifiable Information (PII) being derived from IP fields, Career Site Builder handles them as follows:

These IP fields are not available:

● IP Address● IP Domain● IP ISP (Internet Server Provider● IP Zip

The IP latitude and longitude fields have been rounded to two decimal places to prevent identity of a specific address.

You can still turn on IP tracking for member and visitor maps without violating PII.

We've removed any saved searches that contain deprecated IP fields from the Member Search page because they no longer work.

Data Privacy & Security Settings You can use this page to switch your Data Privacy Consent Statement (DPCS) on or off, configure your data retention management settings for candidates, and manage your data subject reports.

Data Privacy Consent Statement (DPCS) Use this to create and publish your privacy policy. This feature also has version control and archiving of your DPCS.

-

Import & Export DPCS Use this feature to import or export your DPCS.

-

Data Privacy Member Search Fields Use these search fields to track acceptance of a DPCS by specified members.

-


Data Protection and Privacy in Career Sites


Data Subject Reports Use Data Subject Reports as well as Client Admins to generate reports on the kinds of personal data your company holds on an individual in the Talent Community.

Creating an Information Report for Career Site Builder [page 362]

Creating a Change Audit Report for Career Site Builder [page 299]

Data Retention Management Allows customers with Recruiting Management and Career Site Builder to configure the removal of candidate data from the system.

-

Right to be forgotten (Career Site Builder Advanced Analytics)

Allows Recruiting Advanced Analytics users to have their user date removed from the application.

On the login page for Advanced Analytics, choose Remove Me to request the purge of your user account.

When users authenticate to the system or before they commit any changes, they are stopped and presented with the option to accept a new DPCS statement.

On the career site profile page, users cannot save updates without accepting the latest DPCS.

-

Users are informed when a cookie containing personal data is put on their machine

In the Command Center, when users choose the option Remember Me, they are informed which cookies and personal data will be stored.

-

Prevent the manual addition of Talent Community members.

Manually added Talent Community members are in a non-searchable or usable state until they accept their consent statement. To support data privacy and compliance, Career Site Builder prevents the manual adding of Talent Community Members. Only the data subjects themselves can add themselves to the system.

-

Setting Up and Using Data Protection and PrivacyData Protection and Privacy in Career Sites PUBLIC 423

19 Data Privacy & Security Settings for Career Site Builder

Career Site Builder has specific settings for its data protection and privacy features. These settings are unique to customers with Career Site Builder.

Task Solution

Create a privacy policy In the Career Site Builder, choose Tools Data Privacy & Security Settings . In the tab Data Protection:

Slide the switch for Data Privacy Consent Statement. to On.

Manage data retention settings for candidates

In the Career Site Builder, choose Tools Data Privacy & Security Settings . In the tab Data Protection in Data Retention Management :

Slide the switch for Candidates/Client Admin to On and use the sliders to set the activity threshold in days for anonymization of candidate and client admin data. Once the threshold is set, user data is anonymized if there hasn't been any user activity in the specified number of days. You can configure separate thresholds for candidates (Talent Community Members) and client admins (users with an account in the Recruiting Dashboard).

Manage data retention settings for client Admin

Generate a report for candidates or Client Admins/Recruiting Dashboard users who want to know about changes to their PII (Personally Identifiable Information)

In the Career Site Builder, choose Tools Data Privacy & Security Settings Data Subject

Reports .

Stop users from manually adding TC members

In the Data Privacy Consent Statement tab, disable the switch Allow Manual Public User Creation. When it is disabled manual addition of candidates is not allowed in Command Center, Recruiting Dashboard, or via TC member API.

Enabled means that manual addition of candidates is allowed.


Data Privacy & Security Settings for Career Site Builder

20 Cookie Handling in SAP SuccessFactors

In SAP SuccessFactors, cookies are created in different modules for different usages and purposes. Find out what cookies are available for each solution in the SAP SuccessFactors HXM Suite.

Cookies in SAP SuccessFactors Platform

SAP SuccessFactors Platform cookies are placed for every use of an SAP SuccessFactors Platform module. Additional cookies can be set if a module has features that are built on a different application server environment. In case of integration with other SAP cloud solutions or SAP solution extensions provided by third-party vendors, additional cookies might be required by these solutions. If a third-party cookie is present, it's indicated in the Purpose and Usage column in the cookie list.

For more information about firstparty and third-party cookies, see the Related Information section.

Cookies in SAP SuccessFactors Learning

SAP SuccessFactors Learning is a loosely coupled module provided from a different application server environment. Therefore, Learning manages a set of separate cookies.

Cookies in SAP SuccessFactors Recruiting

In SAP SuccessFactors Recruiting, additional cookies are used in career sites built with Career Site Builder.

Cookies in SAP SuccessFactors Onboarding

SAP SuccessFactors Onboarding is provided from a different application server environment. Therefore, Onboarding manages a set of separate cookies.

Cookies in SAP SuccessFactors Workforce Analytics

SAP SuccessFactors Workforce Analytics is provided from a different application server environment. Therefore, Workforce Analytics manages a set of separate cookies.

Setting Up and Using Data Protection and PrivacyCookie Handling in SAP SuccessFactors PUBLIC 425

Cookies in SAP SuccessFactors Employee Central Payroll

SAP SuccessFactors Employee Central Payroll integrates with SAP systems. Additional cookies are placed when a user connects to an SAP ABAP system.

Cookies in SAP Litmos Training

SAP Litmos Training is provided from a different application server environment. Therefore, Litmos Training manages a set of separate cookies.

Cookies in SAP SuccessFactors People Analytics

SAP SuccessFactors People Analytics consumes services provided by other applications. Therefore, additional cookies are placed when such services are invoked.

What Are Cookies? [page 426]Cookies are small files placed on your device (computer, tablet or smartphone). When you access a website, a cookie is placed on your device and it will send information to the party that placed the cookie. This topic explains different types of cookies and the attributes that define them.

List of Cookies in SAP SuccessFactors [page 428]This table lists all available cookies in SAP SuccessFactors applications.

20.1 What Are Cookies?

Cookies are small files placed on your device (computer, tablet or smartphone). When you access a website, a cookie is placed on your device and it will send information to the party that placed the cookie. This topic explains different types of cookies and the attributes that define them.

Session and persistent cookies

Our websites may place session and persistent cookies on your device. The difference between a session and a persistent cookie relates to the length of time the cookie lasts. Session cookies are cookies that typically last for as long as you are using your browser, or browser session. When you end your browser session, the cookie expires. Persistent cookies, as the name implies, are persistent and will last after you close your browser. This allows for quicker and often more convenient access to our websites.


Cookie Handling in SAP SuccessFactors

Cookie security

Our web servers make sure that sensitive cookies are sent securely and free from unintended access and scripts by setting the HttpOnly and Secure attributes.

● The HttpOnly attribute guarantees that cookies can't be accessed from scripts on the client side.● The Secure attribute ensures that cookies can only be sent through secure channels, such as https.

If a cookie contains personal information and needs to be stored at the client side, the information is always encrypted and users are reminded about the data privacy.

Cookie domain

The SameSite attribute allows web servers to specify whether a cookie can be used across different domains. The possible values are:

● None: The cookie can be sent across domains.● Strict: The cookie can only be sent to the same domain from which it's created.● Lax (default): The cookie can be sent when the user navigates to the cookies origin domain.

First-party and third-party cookies

SAP websites have firstparty cookies and SAP sometimes allows third parties to place cookies on your device. The difference between a firstparty cookie and a third-party cookie relates to who places the cookie on your device. First-party cookies are cookies that are specific to the website that created them. These cookies enable SAP to operate an efficient service and to track patterns of user behavior to SAP websites.

Third-party cookies are placed on your device by a third party (that is, not by SAP). While SAP might allow third parties to access SAP websites to place a third-party cookie on your device, SAP does not retain control over the information supplied by the cookies, nor does SAP retain access to this information. This information is controlled wholly by that third party according to the respective privacy policy of the third party. These cookies may change as the third parties make changes to their applications without notifying SAP.

Parent topic: Cookie Handling in SAP SuccessFactors [page 425]

Related Information

List of Cookies in SAP SuccessFactors [page 428]


20.2 List of Cookies in SAP SuccessFactors

This table lists all available cookies in SAP SuccessFactors applications.

Some columns are hidden by default. Choose Show/hide columns to display them.

Product/Module Cookie

Persistence HttpOnly Secure

SameSite

Contains Personal Data Purpose and Usage

When Set Lifespan

HXM Suite

route Session Yes Yes None No Internal traffic routing. When a user visits a page.

Browser session

HXM Suite

JSESSIONID

Session Yes Yes None No Used to keep the login information.

When a browser session starts.

Browser session

HXM Suite

ECJSESSIONID

Session Yes Yes None No Used to keep the login information like JSESSIONID, except this cookie is for Employee Central.

When a user uses an Employee Central functionality.

Browser session

HXM Suite

zsessionid

Session Yes Yes None No Cross application session management.


Browser session

HXM Suite

BIGipServer

Session No No None No Internal traffic routing.

NoteThis cookie is deprecated by route.


Browser session

HXM Suite

OptierRQUUID

Persistent

No No No Troubleshooting and analysis.

Created for every page response.

30 seconds





SameSite


When Set Lifespan

HXM Suite

cookie_clickjack_token

Session Yes Yes No Used for clickjacking filter.

The cookie keeps a security token for clickjacking prevention.


Browser session

HXM Suite

loginMethodCookieKey

Configurable

Yes Yes None No Authentication.

The cookie indicates whether the login method is SSO or PWD.

When a user logs in.

PWD: browser session

SSO: 2 years

HXM Suite

deeplinkCookieKey

Session Yes Yes No Deep link redirection. When a user directly accesses a page through a deep link where authentication is required for the page.

The cookie is removed after the redirection for authentication occurs.

Browser session or after the redirection for authentication occurs




SameSite


When Set Lifespan

HXM Suite

assertingPartyCookieKey

Persistent

Yes Yes None No Authentication.

The cookie is used to keep the SAML asserting party name. The value is provided by customer. Normally, it is a domain name used to identify the party.

Created when SAML SSO is used.

2 years

HXM Suite

ms_cookie_set

Session No No No Used for Media Service.

This cookie is used to detect if a browser allows third-party cookies when a widget is rendered in iFrame mode. The value is boolean.

When a Media Service widget is rendered.

Browser session

HXM Suite

bizxCompanyId

Persistent

Yes Yes No To remember the company ID of the current login.

Created when a valid company is provided by the user.

1 year

HXM Suite

bizxThemeId

Session Yes Yes No To remember the logged-in user's preferred theme ID, whose corresponding theme data contains logo information. When the user logs out or loses the login session in a browser session (such as a browser window), the server knows what the user's preferred theme is.

Created when a user logs in or changes the theme.

Browser session

HXM Suite

<URL path of page>-markFromServer

Persistent

No No No Used for trouble shooting and analysis.

Created for every page response.

1 minute





SameSite


When Set Lifespan

HXM Suite

perflog-version

Session No No No Used for trouble shooting and analysis.

When the user adds the query parameter ?perflog-version to the URL.

Browser session

Learning BIGipServerP_<label>-<port>

Session No Used for internal traffic routing.

Set by the VIP in the Ops landscape.

Browser session

Learning DEEP_URL

Session No To support deep link to pages with SSO.

When a user directly accesses a page through a deep link where authentication is required for the page.

The cookie is only valid for the redirection and expires immediately.

Browser session

Expires immediately




SameSite


When Set Lifespan

Learning JSESSIONID

Session Yes Yes No Used for session management.

When a user visits the Learning site.

Browser session

Learning SKIP_LMS_MAINT_NOTIFY

Session No Used for maintenance management.

When a user visits the Learning site during the maintenance period.

Browser session

Learning SITE_ID

Session No To keep track of the current Learning external site ID.

When user uses the Learning external site functionality.

Browser session





SameSite


When Set Lifespan

Learning PSA_CPNT_TYPE_IDPSA_CPNT_IDPSA_CPNT_REV_DATEPSA_CPNT_REV_NUMBERPSA_STUD_CPNT_IDPSA_STUD_CPNT_MOD_ID

Session No To keep track of current launched course information.

These cookies are intended for external content integration.

Data provided for external content.

Component type ID ( PSA_CPNT_TYPE_ID )Component ID ( PSA_CPNT_ID )Component revision date ( PSA_CPNT_REV_DATE )Component revision number ( PSA_CPNT_REV_NUMBER )Content object student component ID ( PSA_STUD_CPNT_ID )Content object student component module ID ( PSA_STUD_CPNT_MOD_ID )

When a user launches a content.

Browser session

Learning PSA_STUD_IDPSA_CURRENT_STUD_IDPSA_STUD_NAMEPSA_WEBROOT

Session Yes Data provided for external content.

The login student ID ( PSA_STUD_ID )

The current student ID ( PSA_CURRENT_STUD_ID )

The user name who launched the course ( PSA_STUD_NAME )

The content root directory ( PSA_WEBROOT )

Configurable

By default, these cookies are not set.

Browser session




SameSite


When Set Lifespan

Learning loginModeCookie

Session No To keep track of the current login mode, whether it is native login or integrated login.


Browser session

Learning TENANT_AUTH_COOKIE

Session No Akamai authentication cookie for iContent hosted courses.

When user launches the iContent courses.

Browser session

Learning LT Session No To keep track of the login role, whether it's an admin or a user.


Browser session

Recruiting

route Session No A standard cookie used for session stickiness between the organization's public career site generated by Career Site Builder, and pages generated by SAP SuccessFactors Recruiting, such as Candidate Profile.

The cookie is required and can't be disabled.

When a user visits the career site.

Browser session

Recruiting

careerSiteCompanyId

Session Used by Akamai to send the request to the correct data center.

The cookie is required. If disabled, users can no longer access the site.

When a user visits the career site.

Browser session





SameSite


When Set Lifespan

Recruiting

rmk12 Persistent

No No No Career Site Builder cookie.

(Legacy) This cookie is part of the Legacy Site Banner settings, and is used only when you have a legacy site banner enabled.

A number that indicates whether the user has acknowledged the cookies policy banner. If the cookie isn’t set, then the banner may be presented. If they cookie is set and its value is 1, the banner may be suppressed. This cookie persists across user sessions, no matter which type of cookies are enabled sitewide.

Users can disable this cookie through browsers or computer configurations. Once disabled, the cookie banner will always be present.

When a user acknowledges the cookie policy by either viewing the cookie policy or dismissing the banner.

30 years

Recruiting

JSESSIONID

Session Yes Yes No Career Site Builder cookie.

Single cookie placed on the users device during their session so the server can identify the user.

This cookie replaces the RMK0, RMK1, and RMK4 cookies.

This cookie is required for login.

When a user visits a Career Site Builder site.

Browser session




SameSite


When Set Lifespan

Recruiting

Load balancer cookies.

The load balancer cookie names differ in each data center and are only present in the Preview environment.

Here are a few examples:

PERSIST (Rackspace)cookie_j2w (DC10, DC12)BIGipServer~partition-saas_prod-<DC number>_staging_lb-<random key> (DC17, DC19,

Session No Career Site Builder cookie.

Cookie for session stickiness preventing a user from bouncing from one instance to another. Typically issued by F5.

When a new user visits a Career Site Builder site.

Browser session





SameSite


When Set Lifespan

and all new DCs online after DC19)

Recruiting

fbsr_[id]datrlocalec_userfrxscsmsluwd

Third-party cookies set by Facebook in Career Site Builder.

NotePresent only if the third-party applications are configured.

For details, go to Cookies and other storage technologies .

When a user uses the Facebook widget.

Recruiting

_ga Persistent

No Third-party cookie in Career Site Builder set by Google Universal Analytics to distinguish users.


For details, go to Google Analytics Cookie Usage on Websites .

Created by Google.

2 years


http://help.sap.com/disclaimer?site=https%3A%2F%2Fwww.facebook.com%2Fhelp%2Fcookies%2F



http://help.sap.com/disclaimer?site=https%3A%2F%2Fdevelopers.google.com%2Fanalytics%2Fdevguides%2Fcollection%2Fanalyticsjs%2Fcookie-usage





SameSite


When Set Lifespan

Recruiting

_gat Session No Third-party cookie in Career Site Builder set by Google Universal Analytics to distinguish users.


For details, go to Google Analytics Cookie Usage on Websites .

Created by Google.

1 minute

Recruiting

linkedin_oauth_[id]

Session No Third-party cookie in Career Site Builder set by LinkedIn as an OAuth token.


For details, go to Cookie Policy .

Initially created when a new user visits a Career Site Builder career site that uses the LinkedIn JS API. Updated by LInked in throughout the user's session.

Browser session






http://help.sap.com/disclaimer?site=https%3A%2F%2Fwww.linkedin.com%2Flegal%2Fcookie_policy




SameSite


When Set Lifespan

Recruiting

linkedin_oauth_[id]_crclidcRTlangbcookieli_atmstbscookieIN_HASHisitUserMatchHistoryAnalyticsSyncHistoryli_sugr

Session No Third-party cookie in Career Site Builder set by LinkedIn as an OAuth token.


For details, go to Cookie Policy .

When a user uses the LinkedIn widget.

Browser session






SameSite


When Set Lifespan

Recruiting

Third-party cookies from AddThis widgets

Example cookie names:

_atuvc_atuvsna_tcsscsshuvcsshsuidouidna_idloc

Third-party cookies in Career Site Builder created by AddThis.


You can disable these cookies in Social Share Tab in Career Site Builder Global Settings.

When a Career Site Builder widget is used.

Onboarding

SessionId

Session Yes Yes None No Standard ASP.NET cookie for application server session management.

When user logs into the Onboarding site.

Browser session

Onboarding

.ASPXROLES

Session Yes Yes None No Standard ASP.NET cookie used to cache role names.


Browser session

Onboarding

QASF_SF

Session Yes Yes None No Standard form authentication ticket cookie.


Browser session

Onboarding

LAST_ACCOUNT_SFQA

Session Yes Yes None No Stores the last logged-in account name.


Browser session



https://help.sap.com/viewer/8477193265ea4172a1dda118505ca631/LATEST/en-US/4526910e790940f8a3fe71b55894a681.html





SameSite


When Set Lifespan

Onboarding

_REDIRECTCOOKIE_

Session Yes Yes None No Used to make sure sessionId cookie is always new when user logs in.


Browser session

Onboarding

LOGIN_DETAILS

Session Yes Yes None Yes Stores encrypted UserName, ProxyUserName, Locale, and referrer URL information from HXM Suite.


Browser session

Onboarding

EP_SignOut

Persistent

No Stores the logout URL of the Onboarding application. This information is used to propagate logout from application when user logs out from Employee Portal.

When user logs into Employee Portal.

1 day

Onboarding

FedAuth

Persistent

Yes Yes None No Standard Sharepoint cookie in Employee Portal. It contains a reference to the SAML token that SharePoint stores in its token cache. The SAML token contains the claims issued to the user by any external identity and federation providers, and by the internal SharePoint security token service (STS).

When user logs into Employee Portal.

5 days

Onboarding

WSS_FullScreenMode

Session No Standard Sharepoint cookie in Employee Portal.

Browser session

Onboarding

stsSyncIconPath


Browser session

Onboarding

stsSyncAppName


Browser session




SameSite


When Set Lifespan

Workforce Analytics

I3LOGIN

Session No Used for Workforce Analytics login.

When a user logs into Workforce Analytics.

Browser session

Workforce Analytics

ASP.NET_SessionId

Session No Session context for Workforce Analytics.

When a user opens a Workforce Analytics URL.

Browser session

Workforce Analytics

BIGipServerP_server-80

Session No Load balancer node for Workforce Analytics.

When a user opens a Workforce Analytics URL.

Browser session

Workforce Analytics

__TICKET__

Session No Stop replay attacks for Workforce Analytics.

When a user logs into Workforce Analytics.

Browser session


SAP_SESSIONID_<System_id>_<system_client>

Session Yes Yes None No Security session logon ticket.

See 1899896 for more information.


Browser session


MYSAPSSO2

Session Yes Yes None No SAP proprietary login ticket for authentication.


Browser session



http://help.sap.com/disclaimer?site=https://launchpad.support.sap.com/#/notes/1899896



SameSite


When Set Lifespan


cookie_payroll

Persistent

Yes Yes No Used for user login session stickiness.

When a user opens the Employee Central Payroll URL.

3 minutes


sap-usercontext

Session Yes None No Persists login language and login client during session.


Browser session

Litmos Training

ASP.NET_SessionId

Session Yes Yes None No Application server session management. Standard ASP.NET cookie.

Created as a browser session cookie whenever a new user logins to Litmos. The value isn’t updated unless the current session ends, in which case a completely new cookie is set.

Browser session




SameSite


When Set Lifespan

Litmos Training

ecommerceCookie

Persistent

No Yes None No For integration with SAP Commerce Cloud.

Tracks items in shopping cart as user purchases.

Set when a course item is added to cart.

2 days

Litmos Training

__RequestVerificationToken

Session Yes Yes None No Anti-forgery token.

See Preventing Cross-Site Request Forgery (CSRF) Attacks in ASP.NET MVC Application for more information.

Created as a browser session cookie whenever a new user logins to Litmos Training.

Browser session

Litmos Training

LoginAuth

Session Yes Yes None No Users authentication cookie used to prove that a user is logged in between requests.

Created as a browser session cookie whenever a new user logins to Litmos Training. This changes between logins.

Browser session



http://help.sap.com/disclaimer?site=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Faspnet%2Fweb-api%2Foverview%2Fsecurity%2Fpreventing-cross-site-request-forgery-csrf-attacks






SameSite


When Set Lifespan

Litmos Training

LitmosChallenge

Persistent

No Yes No Used as part of the custom Two-Factor Authentication (2FA) in Litmos Training.

When a user changes password, opens the welcome page (for learner and admin), or uses 2FA to log in.

Configurable

Litmos Training

BE_CLA3

Persistent

No Yes None No Third-party cookie set by BrightEdge.

Enables data aggregation, analysis and report creation to assess marketing effectiveness and provides solutions toward SEO/SEM or website performance.

When the site loads.

37,200 days

Litmos Training

__utma Persistent

No No No Third-party cookie set by Google.

Used to distinguish users and sessions. The cookie is created when the javascript library executes and no existing __utma cookies exists. The cookie is updated every time data is sent to Google Analytics.

See Google Analytics Cookie Usage on Websites

for more information.


2 years







SameSite


When Set Lifespan

Litmos Training

_ga Persistent


Used to distinguish users.




2 years

Litmos Training

_gaexp Persistent


Used to determine a user's inclusion in an experiment and the expiry of experiments a user has been included in.




90 days

Litmos Training

cfmrk_cic

Persistent

No No No Third-party cookie set by Cloudflare for traffic routing for customer sites.


90 days

Litmos Training

ts Persistent

Yes Yes None No Third-party cookie set by PayPal to provide fraud prevention.

When a course item is added to cart.

3 years

Litmos Training

cookie_check

Persistent

Yes Yes None No Third-party cookie set by PayPal.


13 months

Litmos Training

ui_experience

Persistent

Yes Yes None No Third-party cookie set by PayPal.


22 months











SameSite


When Set Lifespan

Litmos Training

ts_c Persistent

No Yes None No Third-party cookie set by PayPal to provide fraud prevention.


3 years

Litmos Training

GoogleLoginDomain

Persistent

No No No Third-party cookie set by Google for SSO.

When user logs in through Google SSO.

1 day

Litmos Training

GoogleLoginOrgId

Persistent

No No No Third-party cookie set by Google for SSO.

When user logs in through Google SSO.

1 day

Litmos Training

listTilesView

Persistent

No No No Litmos Training: course library.

When a user accesses the course library.

30 days

Litmos Training

listTilesViewDash

Persistent

No No No Litmos Training: dashboard course tile list.

When a user accesses a dashboard including course tiles.

30 days

Litmos Training

toggledmenu

Persistent

No No No Litmos Training: side bar toggle.

When the sidebar is toggled.

30 days




SameSite


When Set Lifespan

Litmos Training

litmos_fed_session

Persistent

No No No SAML2.0 (SSO). When a user signs in through SSO.

365 days

Litmos Training

Video assessment cookie (dynamic name)

Session No No No Litmos Training: video assessment.

When a user launches a video assessment.

Browser session

Litmos Training

token Persistent

Yes Yes None No Content Author JWT authentication cookie.

When loading CAT during Litmos Training and Content Author SAML authentication.

Browser session

Litmos Training

refreshtoken

Persistent

Yes Yes None No Content Author JWT refresh token for refreshing token cookie.


Browser session

Litmos Training

_csrf Persistent

Yes Yes None No Content Author CSRF token.

When loading CAT

Browser session





SameSite


When Set Lifespan

Litmos Training

CloudFront-Key-Pair-Id

Persistent

Yes Yes None No Content Author: AWS Cloudfront signed access cookie (for AWS storage customers).


1 day

Litmos Training

CloudFront-Policy

Persistent



1 day

Litmos Training

CloudFront-Signature

Persistent



1 day




SameSite


When Set Lifespan

Litmos Training

Cloud-CDN-Cookie

Persistent

Yes Yes None No Content Author: Google Cloud CDN signed access cookie (for GCP storage customers).


1 day

People Analytics

SAC-OEM-AUTHTOKEN

Session Yes Yes No For People Analytics integration.

When a user creates, edits, or runs a Story report in Report Center.

Browser session

People Analytics

SAC-OEM-CSRFTOKEN

Session Yes Yes No For People Analytics integration.

When a user creates, edits, or runs a Story report in Report Center.

Browser session

People Analytics

JSESSIONID (BIRT Server)

Session Yes Yes No BIRT server session management.

When a user runs a Table report in Report Center.

Browser session

Parent topic: Cookie Handling in SAP SuccessFactors [page 425]



Related Information

What Are Cookies? [page 426]


Important Disclaimers and Legal Information

HyperlinksSome links are classified by an icon and/or a mouseover text. These links provide additional information.About the icons:

● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your agreements with SAP) to this:

● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any

damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.

● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this information.

Videos Hosted on External PlatformsSome videos may point to third-party video hosting platforms. SAP cannot guarantee the future availability of videos stored on these platforms. Furthermore, any advertisements or other content hosted on these platforms (for example, suggested videos or by navigating to other videos hosted on the same site), are not within the control or responsibility of SAP.

Beta and Other Experimental FeaturesExperimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use the experimental features in a live operating environment or with data that has not been sufficiently backed up.The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.

Example CodeAny software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of example code unless damages have been caused by SAP's gross negligence or willful misconduct.

Bias-Free LanguageSAP supports a culture of diversity and inclusion. Whenever possible, we use unbiased language in our documentation to refer to people of all cultures, ethnicities, genders, and abilities.

452 PUBLICSetting Up and Using Data Protection and PrivacyImportant Disclaimers and Legal Information

Setting Up and Using Data Protection and PrivacyImportant Disclaimers and Legal Information PUBLIC 453

www.sap.com/contactsap

© 2022 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. The information contained herein may be changed without prior notice.

Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies.

Please see https://www.sap.com/about/legal/trademark.html for additional trademark information and notices.

THE BEST RUN

https://www.sap.com/about/legal/trademark.html