Concurrent employment in SuccessFactors and active directory integration

[michal_z]

Hi,

I would like to ask how did you solve the concurrent employment in SuccessFactors in regards of Active Directory Integration.

When we implemented the integration between SF and AD we decided to use the userNav/username from SF as sAMAccountName in AD. And when we tested the integration we found out many user accounts created in AD with user_login_name-1, user_login_name-2, and so on. Those were other roles of the same users in the company.

As a quick fix we decided to filter out the users with -1, -2, -3 ... names. But this doesn't resolve the problem of one user having many roles in the organization which means different job titles, locations and so on.

How do you deal with that, if you do at all?

[manubhutani]

Hi Michał Ziemba,

I am not sure I understood your question correctly. We are using username in the DN to query employee in AD.

Regards

[michal_z]

Hi manu.bhutani2

Thank you for the article. It sounds quite similar to concurrent employment. We do not create users with -1 (-2, -3, -*) postfix so the accounts are not doubled in AD (as you mentioned in the article, because of SSO functionality). We create only one employee account in AD based on the primary role. Than when the user gets more roles in SF we do not see them in AD.

It is a pity that CPI cannot read from AD. This could be useful when creating a user in AD and setting up his manager. As we tested, this is not enough to send a manager samAccountName. It looks like it requires a full DN instead. How did you handle this issue?

Regards

Mike

[michal_z]

Hi manu.bhutani2

Thank you for the article. It sounds quite similar to concurrent employment. We do not create users with -1 (-2, -3, -*) postfix so the accounts are not doubled in AD (as you mentioned in the article, because of SSO functionality). We create only one employee account in AD based on the primary role. Than when the user gets more roles in SF we do not see them in AD.

It is a pity that CPI cannot read from AD. This could be useful when creating a user in AD and setting up his manager. As we tested, this is not enough to send a manager samAccountName. It looks like it requires a full DN instead. How did you handle this issue?

Regards

Mike

[manubhutani]

Hi Michał Ziemba,

Does the AD already has employee username for concurrent employments and you are updating other employee details in AD?

We did integrate SFSF EC and AD and had GLobal assignment scenario but not concurrent employement. You can refer this blog if that helps - https://blogs.sap.com/2019/03/04/update-employee-details-from-sap-successfactors-sfsf-employee-centr...

Regards,

Manu