This blog gives you an overview and explains the frequently asked questions on the replication of Employee master data from an external system to SAP Cloud for Customer. The external system may be SAP ERP, SAP CRM, S/4 Hana or SAP SuccessFactors Employee Central (EC). The replication is unidirectional from the external system into SAP Cloud for Customer.
Employee replication is mediated from an external system to cloud through SAP CPI/PI system.
New service for Employee Replication from an External system (eg: ERP, S4Hana or CRM) to SAP Cloud for Customer.
Replicate Employee from SAP Business Suite
A new replication service is now available for Employees coming in from SAP ERP, S4Hana, CRM system. This new service will directly create/update Employee in SAP Cloud for Customer rather than creating a Replication requests and processing them via background job.
New service for Employee Replication from SuccessFactors Employee Central to SAP Cloud for Customer via CPI as middleware.
Replicate Employee from SAP SuccessFactors Employee Central
How Employee Replication from SAP Business Suite is better than Employee Replication using Intermediate Staging Area from SAP Business Suite.
Direct replication makes it independent of a C4C replication background job so users need not have to wait for the job to replicate their user. This even reduces maintenance tasks and C4C administrators need not have to monitor employee replication jobs.
Does that mean existing process of Employee Replication is deprecated?
No, customers can either use this new service for integration or existing replication request service but not both at same time as this might cause data inconsistencies.
How to configure this new service?
From Business configuration perspective, nothing changes, you still need to scope for Employee replication.
Once this scoping is done, you will find new Communication Scenario.
Also, create Communication Arrangement for the same.
Note: New PI mapping CRM_COD_SimplifiedEmployee_Replication_Bulk, ERP_COD_SimplifiedEmployeeReplication, S4_C4C_SimplifiedEmployeeReplication and EC_C4C_SimplifiedEmployeeReplication is delivered for this new service for CRM, ERP, S4Hana and SuccessFactors Employee Central Integration respectively.
To avoid any errors, follow these best practices:
- Replicate organization center data from SAP ERP/S4Hana/CRM and only then replicate employees. Otherwise, employee replication will fail due to missing organizations.
- Use employee replication interface to replicate employees, instead of business partner replication interface.
- To minimize replication errors, employees from Employee Central should be sent to SAP Hybris Cloud for Customer through an initial load. This creates an organization center hierarchy in SAP Hybris Cloud for Customer, minimizing replication errors.
Frequently Asked Questions
What is the default locking behavior of an employee/user created in C4C?
If an Employee is created via replication service Employee Replication from SAP Business Suite, it will create a locked user by default. The old staging area service Employee Replication using Intermediate Staging Area from SAP Business Suite still creates an unlocked user in C4C. All the future enhancements will be done for the new service only.
Is it possible to replicate business partners with employee role, if the BP has already been replicated with some other role?
If a Business Partner (BP) is replicated as contact/customer to SAP Hybris Cloud for Customer, it is not possible again to replicate the same BP as employee.
Error: A FATAL EXCEPTION is raised for instance sharing scenario.
What is the significance of Employee Type in replication? Give an example use case where employee replication is affected due to Employee Type Validity?
Employee Type data contains information on the duration of employee’s validity in the system. Say an employee is terminated in CRM/ERP, and Employee Type Validity end date will have termination date of an employee. If employee is sent to Cloud for Customer, whose validity date extends beyond the termination date, then the employee is set to inactive and his user is locked in Cloud for Customer.
Most common use case where employee replication fails is because organization assignment validity is extended beyond employee type validity.
Error Text: “Assigned employee <EMP_NAME> is not valid from <DATE> to <DATE>”.
Can we use business partner service interface to replicate employees from CRM to Cloud for Customer?
BP service interface should not be used to replicate employees. Instead, use Employee replication service to replicate employees from ERP/CRM.
How to manage employee replication background job?
Background job is scheduled only when employee replication is scoped. By default, it is scheduled to run once a day, but a key user can re-schedule the job as required. It is recommended not to configure it to run on “Single Run” or “Start Immediately” option. By doing so, the background job schedule instance moves to “Completed” status and re-run will not be possible. In such a case, an incident is required to create Background job schedule from backend.
What are the steps to migrate employees using migration template?
Follow these steps to replicate employees using a migration template:
- Navigate to Data Integration à Complete Employee Master Data Replication work center view.
- To launch Migration workbench, click Actions à Upload Complete Data.
- Download migration template from the launched view.
- Follow these guidelines while filling the template:
- On the Grouping tab, make an entry in key column “File Creation Date Time” in the format “YYYY-MM-DD hh:mm:ss”.
- On the other tabs, maintain the same value for “File Creation Date Time”.
- In the “Person ID Type” column, enter the value “1” for ERP remote employee ID, or “2” for CRM business partner remote ID.
- Upload the filled template using migration workbench.
- After the data is successfully uploaded, navigate to Data Integration à Complete Employee Master Data Replication work center view.
- Verify the data is loaded into staging.
Can we replicate private address of an employee to C4C?
Employee view in Cloud for Customer shows work place address and not private address. Hence, private address is not replicated.
How is ID mapping used in employee replication?
On replication, Cloud for Customer maintains a mapping between employee IDs in the external system and the Cloud for Customer system.
When an employee is replicated, the replication service checks the existence of external ID in this ID mapping. If external ID is not found,
it creates a new employee in Cloud for Customer, else if it finds the mapping, it updates existing employee data.
Is it possible to send an employee without organization assignments? What are the common failure use cases around org-assignments to employee?
Yes, it is possible to replicate an employee without org-assignment.
Most common issues around org-assignments to employee are that the replication fails if:
- An employee assigned to an organizational unit is not replicated to Cloud for Customer.
Error Text: “Remote org unit <REMOTE_ORG_ID> with definition Functional Unit from <REMOTE_SYSTEM> not yet replicated”.
- An org-assignment validity extends beyond employee validity.
Error Text: “Assigned employee <EMP_NAME> is not valid from <DATE> to <DATE>”.
What is complete transmission date in the context of employee replication? And what are unchanged indicator and how do they influence employee replication?
Complete Transmission Start Date (CTSD) is the date from which complete data of an employee is transmitted.
For example, if CTSD is 01.01.2013, then all data of an employee from this date, say Personal Details, Org-assignment, and Workplace Address are transmitted to Cloud for Customer.
Unchanged indicator is provided to restrict modification of data in Cloud for Customer. It is always set to false during initial replication of an employee. Following unchanged indicators can be set on the employee replication request:
- PersonalDetailsUnchangedIndicator: If true, update to Personal details data of employees is restricted.
- WorkplaceAddressUnchangedIndicator: If true, update to Workplace details data of employees is restricted.
- OrganisationalAssignmentUnchangedIndicator: If true, update to Organizational assignment data of employees is restricted.
- EmployeeTypeUnchangedIndicator: If true, update to Employee Type data of employees is restricted.
- IdentityUnchangedIndicator: If true, update to Identity data of employees is restricted.
Which attributes are mandatory for employee replication?
Following attributes are mandatory to successfully replicate employees to Cloud for Customer.
- Business System ID
Error Text: “Remote system instance ID missing”
- Remote Employee ID/Business Partner Remote ID
Error Text: “Remote employee ID or Remote business partner ID missing”.
- Last Name of an Employee
Error Text: “Last Name mandatory. Enter last name”.
- Employee Type data
Error Text: “Employee type missing for remote employee <REMOTE_ID> from <REMOTE_SYSTEM>”.
What are the effects of changing business system after the initial load of employees to Cloud for Customer?
When employees are replicated from an external system, ID mappings (Remote ID – Local ID) are maintained in Cloud for Customer, with respect to a business system from where an employee is replicated. If the business system changes after the initial load, all employees are again created in Cloud for Customer.
In case if such a situation arises where a business system has to be changed after initial load, then first update the business system in ID mapping for all the employees. This could be done either by Data Workbench or ID mapping download/upload utility.
Once the existing ID mappings are updated with new business system, employee will not get duplicated in the Cloud for Customer system.
How are the employees from staging processed? Is it in sequential or parallel processing mode?
Employees from the staging are processed via background job in parallel processing mode. Employees from external system are sent in packets to Cloud for Customer employee staging. The processing of employee replication request also happens in packets, and in a packet if one replication fails the entire packet will fail to replicate in parallel processing mode. Packet with failed replication request will be processed in sequential mode.
Can an IDOC have multiple instances of the same employee?
An IDOC will not have multiple instances of the same employee.
How to configure Cloud for Customer to integrate with Employee Central.
Please refer the following document on SAP Service Marketplace: INTEGRATION: EC Service Center + Cloud for Customer
- INTEGRATION with Employee Central – Mappings at Field Level
Which attributes of Employee Central are mapped to attributes in Cloud for Customer?
Please refer the following document on SAP Service Marketplace: INTEGRATION with Employee Central – Mappings at Field Level
Is it possible to assign same user ID to different employees in Cloud for Customer?
For every employee replicated, business user is created with a unique user ID. Same user ID cannot be shared or multiple employees cannot have same user ID. It is possible to update the user ID in Cloud for Customer but again it should not be assigned to some other user.
Error Text: “An identity with the same ID <USER_ID> (<Employee Name>) already exists”.
Can we use attribute “ScheduleProcessingDirectlyIndicator” to process employee replication request immediately?
Please do not use this attribute as it is not supported. Instead the workaround is to schedule the employee replication background job to run at shorter intervals of time like every hour or two.
How to ensure that employee replication is working fine?
Key user or administrator needs to regularly monitor the employee replication job and employee staging for the failed jobs or failed replication requests. For every failed request, look at the error and take the necessary action either by correcting the data in the staging or by marking it as irrelevant, if the data is outdated.
Why is Employee staging view failing to load the data?
This issue usually occurs if there is any inconsistency in FSI. By FSI reload it should get resolved.
If your issue is still not resolved, then please raise an incident for SAP Support. Also, please send the following information in the incident:
- Problem description
- Steps to reproduce
- Cloud for Customer Message ID
- IDoc number from ERP/CRM.
What is the difference between Initial load and delta load in SAP CRM Integration?
|Initial load||delta load|
First time load of a record from SAP CRM to SAP Hybris Cloud for Customer
|Every business day (best practice)|
ID mapping for Remote Business Partner ID gets created in SAP Hybris Cloud for Customer.
If initial load is re-executed on existing Business Partner ID, from SAP Hybris Cloud for Customer point of view, it is a delta load of data (update) for that Employee
|ID Mapping for Remote Business Partner already exists|
|KEY_DATE||Cut-off date for older data to reduce amount of historical data in SAP Hybris Cloud for Customer. Transmission date is Key date – 3 months||Same behavior|
|Input||Any employee entered as parameter||Only those employees where unprocessed change pointers exist in BDCP2 table|
|data set||Full record is being transmitted||Full record is being transmitted|
|execution||We expect customer to provide Business Partner IDs and we fetch data for those BPs and transmit data to SAP Hybris Cloud for Customer||We rely on BDCP2 entries for employee message type. We fetch only those employees for whom the change pointers exist and then transmit data to SAP Hybris Cloud for Customer|
Is multiple organization assignment supported as part of ERP integration?
No, currently we support multiple organization assignment for integration between CRM – C4C only.
Background job for processing employee replication request failing continuously.
Usually this type of issue/dumps happen when the system has more load than it can handle. At first please check how many replication requests exist in the system which are in “Not started” state. This can be directly checked from the UI (Administrator Work center).
Additionally, check if there exist duplicate replications in bulk for all employees. If yes, please check your replication strategy from the external system (ERP/CRM/EC).
Replication requests for some of the employees are not getting processed.
This type of issue happens when we try to process a replication request which is in “Past” with respect to the “Last successful” replication request.
This can be checked and verified (from the UI) with the timestamp of the replication request which you are trying to process with that of a replication request which has Current indicator as true (last successful replication). If the new replication request has a timestamp before that of last successful replication, then the new replication request must be marked as irrelevant as it is Outdated.
Background job is getting cancelled.
This can happen in multiple scenarios.
- When multiple background jobs are scheduled for employee replication. Here we need to cancel duplicate jobs and let only one job to run.
- When there is a manual triggering of background job from UI (Replicate All) which overlaps with the scheduled run.
- When the replication request is coming from middleware with “ScheduleProcessDirectlyIndicator” as true which schedules and trigger the job as soon as the Cloud for Customer receives a request. This indicator should always be false.
Business partner exist without any role.
This happens when we try to process an employee for which the business partner exists without any role. It happens when an employee is terminated without even getting replicated to C4C once.
To process such employees please apply the note 2511977 and replicate those terminated employees using a new report ‘crmpcd_terminated_empl_extract’ provided as part of the mentioned note.
Point to Point replication in Employee Central is deprecated.
Starting from 1611, we have introduced HCI mediated service which will periodically query Employee Central system and send asynchronous inbound messages to C4C.
For more information regarding HCI medicated solution please follow this blog.
What all fields gets replicated from SuccessFactors Employee Central to C4C?
We don’t replicate any Job Information or Organization Assignment from Employee Central to C4C as it’s already deprecated so even if it’s available in the payload received at C4C it will not be considered for replication.
We replicate Address, Phone, Mobile and Email Information from Employee Central to C4C only if it’s of type ‘Business’/’business’, ‘B’, ‘CELL’ and ‘B’ respectively.
Mapping Workplace Address node in C4C directly to respective fields in EC will not replicate Address information to C4C as we calculate Workplace Address node based on what data is coming in Address Information, Phone Information and Email Information nodes from EC.
Extension fields are not getting replicated from SuccessFactors Employee Central to C4C?
This hold true if you are extending Employee Replication from SAP SuccessFactors Employee Central web service.
Unlike other extension handling, we need to add that field against two services:
- Employee Central Employee Replication – Common Data
- Employee Replication – Common Data
Thanks Raghu It helps a lot.
Hello Raghavendra Jadi ,
Thanks a lot for the details on Employee replication. Can you also elaborate how to avoid the below issue?
When employee leaves the organization, employee role is removed in CRM, resulting into a replication towards C4C which fails with error - "User not authorized to delete employee ID". Expectation is to change the Employee to no longer be used. Can you please elaborate on how to avoid this?
When an employee is terminated, he is replicated with employee type validity delimited.
In C4C such employee becomes inactive and the user is locked.
Can you please open a ticket with detailsteps and scree-shot of error. We would like to look into this issue.
Dear Raghavendra ,
we have raised an incident with SAP with Id : 3100954841
can you please please help
I have replied to the incident. Please avoid using BusinessPartnerReplicationIn service to replicate or modify employees in C4C. You have dedicated services for Employee Replication with better error handling ease of use. Please contact me via incident for any queries.
Hello Raghavendra Jadi/Satya Manideep,
Technically, Employees are also Business Partners in CRM, so whenever there is changes done on it, it triggers Business Partner IDOC. This is true even when new employees are created. I am trying to understand how to configure it to trigger via Employee specific IDOC, so that whenever there is any changes/new creation of Employee, it should be triggered via Employee specific IDOC and avoid Business Partner IDOC.
Maybe I missed this documentation, if it is already mentioned somewhere, can you please help me with this information?
Hi Chandan, The Employee IDOC is triggered from CRM if there are Employees originated from SAP HCM as the target structure mapped for C4C Employees in such case is as well HCM based structure. It is not possible to map CRM Employees (originally created in CRM) to map as Employees in C4C as the structure would predominantly. Incase if you require Employees from CRM to be mapped to C4C Employee BO, you would have to implement a BADI to trigger the COD Employee IDOC and pass the necessary parameters for a successful replication BR Dedeepya
Please go through the CRM quick start guide available at service market place.
Thanks for your valuable suggestion that would surely help everyone on this forum !
I scoped the replication of employees and I also mapped the exisiting employees in C4C with the existing employees in ERP by Integration of ID mapping.
But I want to avoid that the system creates new ERP employees which are not in C4C
Can I manage this ?
If I understand correctly:
- Employees are locally created in C4C.
- Employee replication from ERP is scoped in C4C.
- via ID mapping, you have mapped C4C employees with external(ERP) employee ID.
- Employees(which are already in C4C mapped to external ID) when replicated from ERP should not get created again. Is that your question ?
If yes, they will not get created rather updated provided that source system is same as maintained in ID mapping for these employees.
My question is, when NEW employees are created in ERP are they also going to be created automatically in C4C? Or are only mapped employees updated ?
If you have set-up the integrtaion between between C4C and ERP and employee replication is scoped, then employees created/updated in ERP will get replicated to C4C.
What if you have an employee already replicated in C4C from source A (it already has a ID mapping entry in C4C) then same employee (same external ID) but from differenct source (let's say source B), will it create a new employee in C4C or it will just update the existing one and create an ID mapping entry with different source system?
If an employee exist in the system which got replicated from source A it would have an ID Mapping and Identity corresponding to that, now if you try to replicate the same employee (same ID) from source B then ideally it will throw an error saying "An identity with the same ID xxxxx already exist" and you will not be able to process it.
If you maintain a different Identity for the employee from source B then it will get successfully replicated however it will not create a new employee, it will create a new ID mapping which would correspond to a different Business Partner.
thanks for this blog.
I have two questions:
1) Isn't possible to set up C4C to store employees metadata in SAP Cloud Identity Service?
2) Do you know if existing C4C APIs for creation, modification, delete.. employees metadata with synchronous call for not a massive synchronization?
BR and Thanks
We have integrated our SAP C4C solution with SAP ERP using SAP HCI as our middleware. When we try replicating Employees from SAP ERP to C4C, the Employees flow into the Data Migration WC. The issue we are facing is that the Org assignment doesn't flow with the Employee data. We have already prior to replicating Employees, already replicated the complete Org Structure from SAP ERP to SAP C4C.
Any suggestions pointers on this will be very helpful.
Thanks and regards,
We have integrated our Employee's and Org Structure. That works but it does not allow us to use the secondary or non primary org assignments in C4C. When we syncs the employee's it pulls them from the secondary Org unit and only puts them in their primary. We were hoping and thinking that the system would leave the secondary assignments alone and not update them. We were not so lucky. This works well for us as we have set up structure for the "dotted line" reporting that is wide spread in our company.
Any suggestions? Does ECC support secondary assignments?
so you say the secondary org assignment vanishes on every newly transferred employee update (i.E. mail change, name change etc)? If yes, have you found any solution yet?
We also have Employee integration working but need the secondary org assignments to get our authorisation working as required.
So it would be really bad if the secondary assignments vanish.
As of now ERP-C4C integration for employee replication does not support Secondary/Multiple org assignment, this however is supported for CRM-C4C integration.
As a workaround, you can maintain one org assignment in C4C (Secondary) and one from ERP (Primary: which will be replicated) then set Organizational Assignment indicator as true in staging area which will make sure that no updates will happen for organization assignments.
Thus it will not override any assignment.
Hope this helps!
is it possible to stop the system from creating business users on employe syncronisation?
We have a whole bunch of employees we need to integrate for proper working of some partner roles in Accounts and Contacts.
Unfortuanely the system always creates a business user for those employees too and so fills our business user list with a lot of not needed junk.
If i understand correctly, you do not want to create Business User every time an employee is created.
In principle if an employee is created, corresponding Business User also gets created. This is required and doesn't affect the system in any manner.
As a workaround you can make those business users as Locked or Uncounted which can be done by setting User Account Inactive Indicator as true which in general remains false and create a counted user.
Hope this helps !
yeah that's the workaround we are using already.
I was hoping for something that's not filling the business user list with unneeded rubbish, but it's ok for now.
I just don't completely understand why its possible for service agents to create then without business user and for employees it's not possible. It would make more sense the other way around I think 😀
I newer saw the need for a service agent without a user... for employees in the opposite this may be desired due to ECC integration.
I know this is 5 years later, but how did you resolve this issue?
Hi Raghavendra Jadi ,
Thank you for such a detailed blogpost. I have a query regarding Department and Job replication, is there a possibility we can replicate this from Success Factors to C4C? This is very important for the scenario we're working on.