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

6 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?

  • Hi Patrik, Fabian,
    I have a question on the possibility of using ‘username’ as SSO, I cant find where at design time i can specify to tell in EC provisioning where to use ‘username’ instead of the default ‘userID’ or ’email-ID’. Any inputs are really appreciated.

    To describe further I have the following situation:
    1. SF is the IDP system and EC is turned ON.
    2. We are configuring Time and Attendance Link to SSO with Workforce system.
    3. The requirement is to use the ‘userName’ instead of the default ‘userId’ value for SSO assertion.

    Is this possible to be done in SF Provisioning where the ‘Name-id’ can be replaced to use ‘userName’? If yes, wherein provisioning is this performed?

    The KBAs I am reading is pointing me to implement :
    SAP CP IAS (Identity Authentication Service) along with SF to function as a ‘proxy’ to be able to do this.
    Is this requirement possible without using a IAS, as we have Global Assignment and IAS is NOT recommended in that case?

    Thanks,
    Srikanth

    • Hi,
      the SSO setup has to be configured within Provisioning. We use almost always the “username” as SSO identifier. With Global Assignment or Conurrent Employment it is definitely more tricky as you would need as many e.g. ActiveDirectory accounts for an user as many “JOB” assignments the user has in SuccessFactors.
      I would recommend to use only one account for login. If you want to use e.g. Global Assignment account for login I would recommend to switch the “Username” for Home and Host Assignment for the duration of the Global Assignment. Within SuccessFactors via Business Rules it is yet again tricky to automate this process therefore I would recommend to do it manually using the Basic Import.

Leave a Reply

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