ID

With this article we give you a brief overview about the different IDs used in SuccessFactors Employee Central and Employee Profile. Talking about Employee Profile User ID and Username are relevant. In addition to the User ID and Username the Person ID also comes into play for Employee Central. Overall the ID logic within SuccessFactors is quite simple. You just need to understand the different setups for the different IDs and the behavior of these IDs for common business processes. 

Person ID (person-id-external)

The Person ID is stored as a standard field on the biographical information portlet. The Person ID is furthermore unique and an employee has only one Person ID in their company life-cycle. This ID connects all person related information portlets (Personal Information, National ID, Address Information, Contact Information, Dependence Information, Emergency Contacts etc.) to the employee.

In Employee Central, disregarded manual imports, you can assign the Person IDs manually (Add New Employee Wizard) or you can use the automatic assignment by the system. In general the system will set the User ID of an employee identically to the Person ID at a new hire action. You can define sequences for an automatic assignment of the Person ID from the system within "Company, System and Logo Settings" (only digits) or more complex by Business Rule engine to separate more according to granular criteria (e.g. country, company etc.).

Person ID can be changed via the UI in Biographical Information but it is not recommended to change it. Furthermore person-id-external cannot be used for SSO.

User ID (userId)

The User ID is stored as a standard field on the Employee Profile (Basic User file). The User ID is similar to the Person ID unique and is used to associate the employment of an employee. For Employee Central the User ID is automatically mapped to the Person ID (User ID = Person ID) during a new hire in the system. User ID associates all employment related information portlets (Job Information, Compensation Information, (Non-)Recurring Pay Information, Job Relationship Information etc.) to the employee.

User ID cannot be changed and without a purge not be reused as it is unique. User ID can be used for SSO.

Username (username)

The Username is unique as well and is stored as a standard field on the Employee Profile (Basic User file). Basically the Username is used for the system login and is generally mapped from the Person ID (User ID) in Employee Central for new hires. The Username can be different from the Person ID and User ID.

Username can be changed. This can be done as well on the UI and synced via HRIS-Sync to the Basic User file. Username can be used for SSO (e.g. ActiveDirectory ID as Username for SSO).

Fabian Moser on Linkedin.
Patrik Neubacher on Linkedin.

Share this...
Share on FacebookShare on XingShare on Google+Tweet about this on TwitterShare on LinkedIn

4 Thoughts on “Employee Central ID Management”

    • Hi Joel. I definitely agree. But we made the experience that it is even better to keep the SF IDs only for SF and don’t align them with different payroll vendors and different logics. We even use the payroll id field in comp info for potential payroll integration or if needed a custom field in job info. Thanks for your comment.
      Best regards
      Patrik

  • Hi Joel,

    many thanks. Why is not recommended to Change Person ID? I can imagine a Scenario where an external Identity Management System generates this unique Lifetime ID once it first gets an employee from SF via interface, and then sends it back to SF. This usually happens outside of SF since an IAM System usually holds a “bigger Population”, meaning also external employees, contractors, others which are not maintained sometimes in SF. So an IAM would be the Logical and only place to generate a “true” Lifetime ID.

    I understand there might be restrictions when it Comes to changing the Person ID when using Global Assignments and/or Concurrent Employment – could you Elaborate?

Leave a Reply

Your email address will not be published. Required fields are marked *