Skip to Content
Product Information

The SuccessFactors Employee Central Organization Structure

SuccessFactors Employee Central uses a simple but effective way to manage the enterprise, which differs somewhat to how SAP ERP HCM manages the enterprise. In this blog, we will discuss the organization structure as well as part of the job structure. Please note that the standard-delivered configuration of Employee Central will be discussed, although we will touch on the extensibility options to enhance this.

The organization structure in SuccessFactors has a different approach than SAP. In addition to having a more granular and configurable structure, it also incorporates the Company/Legal Entity into this structure. In SAP, the Company Code is part of the Enterprise Structure and is assigned directly to employees in infotype 0001. There are concepts of Employee Group, Pay Structure, Pay Scale Structure, and Cost Center hierarchy in Employee Central, but no concept of a Personnel Structure. We’ll explore pay structures in a later blog. The Employee Central system is extremely flexible in allowing the standard configuration to be modified as such to allow a customer to create an organization structure exactly as they require. This could be hiding or changing existing objects or adding new objects. Personally I believe that the organization structure in Employee Central makes more sense to business users and I will expand on this further as we continue.

A little terminology

Before we start, it’s worth going through a little Employee Central terminology:

Employee Central term Description SAP ERP HCM equivalent
Foundation Objects The primary objects and data that is used in employee records (e.g. Company, Job Classification, Pay Grade, etc.) Object Type / Master Data / Transparent table
Associations Relationships between objects Relationship
Generic Objects Custom objects crated with the Metadata Framework Object Type
Organization Structure The organization structure used to manage the enterprise Organization Structure
Propagation Auto-population of field values on an employee’s Employment Information from Foundation Objects Default values set by Features in PE03

Organization Structure

In the standard-delivered configuration the organization structure is composed of the following Foundation Objects:

  • Legal Entity
  • Business Unit
  • Division
  • Department
  • Location
  • Cost Center

Additionally, these objects can either be removed if not required or re-purposed in the structure (e.g. change a Department to a sub-Division). New objects can also be added within the structure using the Metadata Framework. The diagram below illustrates the “top” 4 objects in the structure, with the standard-delivered Associations between objects:


A Legal Entity cannot have a parent of the same type. A Division can belong to multiple Business Units and a Department can belong to multiple Divisions. In addition, both a Division and Department can have a parent of the same type, thus creating a hierarchy of these object types.

We can compare the objects in this structure to SAP object types or fields:

Foundation Object SAP ERP HCM equivalent
Legal Entity Company Code
Business Unit Business Area / Organizational Unit (Object type O)
Division Organizational Unit (Object type O)
Department Organizational Unit (Object type O)
Location Personnel Area / Personnel Subarea
Cost Center Cost Center (Object type K)

The Organization Structure Objects

During the implementation of Employee Central, each Foundation Object can be configured to store certain details about the object. This can be used for reference or can be used to populate values into fields on an employee’s Employment Information record (called propagation in Employee Central terminology). Of course, many of these objects can be re-purposed as required and new objects can be added.

Legal Entity

The Legal Entity object – sometimes referred to as Company – contains the definitions for all legal entities that are part of the customer’s enterprise. Every employee must have a Legal Entity assigned when being hired or setup in the system (just as they would in real life!). By default, a Legal Entity defines the country and default Pay Group, Location, currency, and standard hours for employees within that company. Country-specific information can be stored on a Legal Entity object. In SAP ERP HCM, the Legal Entity is the Company Code that is selected on the infotype 0001 screen during the hiring action.

The screenshot below shows the object record for the ACE USA Legal Entity.


The field below the Country field is country-specific fields for the country United States. These fields differ by country. Other data from this page can be propagated to the employee’s Job Information or Compensation Information, such as the Default Pay Group or Default Location field values.

Business Unit

A Business Unit represents a segment of a Legal Entity that focuses on a specific business function, such as manufacturing, sales, or marketing. There is no direct equivalent object in SAP, although a Business Unit could be represented by the Business Area in PA or by an Organizational Unit object in OM.


A Division is simply a division of a Business Unit. However, it can be used directly as a Division of a Legal Entity if required, such is the flexibility of Employee Central. There is no direct equivalent object in SAP, although a Division could be represented by an Organizational Unit object.


Divisions are broken down into one or more Departments. This is more typically represents an Organizational Unit object in SAP and is often the lowest denominator of the organization structure.


The Location, as the name suggests, represents a physical location. It is used to identify the employee’s location. By default, the Location defines the time zone and standard weekly hours of the employee. Locations can be grouped by Location Groups for further organization and reporting. In SAP, the location is often the Personnel Subarea.

Cost Center

A  Cost Center represents the units that account for business costs, just as in SAP ERP and other HRIS’. Although it is part of the organization structure, it is more of a designation for the costs of an employee than part of the organization in which they reside. However, some organizations do use Cost Center as part of the organization structure. Cost Centers can have parent Cost Centers so that a hierarchy can be created.

Generic Objects

Generic Objects can be created in the Metadata Framework and associated to Foundation Objects so that additional layers can be introduced to the organization structure. Generic Objects are created with the Metadata Framework. Extensive details on creating Generic Objects can be found in the Metadata Framework Implementation Handbook on SAP Service Marketplace (S-user required) and in this SAPexperts article Creating Metadata Framework Objects in SuccessFactors Employee Central (subscription required).

Associations between Foundation Objects (including Generic Objects)

Associations are relationships between objects that define the hierarchical relationship and filters for these objects. In essence, they define the parent-child relationship and whether a child relationship must exist for a parent object. In addition, they are used to filter object lists. An Association must have a multiplicity defined, which is either One-to-One or One-to-Many:

  • One-to-One: Defines that the object can only be associated to one other object
  • One-to-Many: Defines that the object can be associated to multiple objects

In the diagram above we can see several associations. Departments are associated to Divisions, while Divisions are associated to Business Units, and Business Units are associated to Legal Entities. Business Units, Divisions, and Departments can have parents of the same type.


A manufacturing Company has 3 Business Units called “Plastics”, “Woods”, and “Metals”. The “Plastics” Business Unit has 3 Divisions associated to it, called “R&D”, “Manufacturing”, and “Distribution”, while the “Metals” Business Unit has 2 Divisions associated to it, called “Metalworks” and “Alloys”, and the “Woods” Business Unit has 2 Division associated to it called “Carpentry” and “Timber”. This is demonstrated below.


An administrator is hiring a new employee. On the Job Information screen of the New Hire process an administrator selects the Legal Entity and then the “Plastics” Business Unit. In the Divisions drop-down the administrator will only see the values “R&D”, “Manufacturing”, and “Distribution”. Likewise, if they select the “Metals” Business Unit then in the Divisions drop-down they will only see “Metalworks” and “Alloys” and if they select the “Woods” Business Unit then in the Divisions drop-down they will only see “Carpentry” and “Timber”.

How does this look in EC?

Details of an employee’s organizational assignment is defined when the employee is hired. This information can of course be changed as required. The Job Information portlet found on the Employment Information page of an employee shows details of the position assignment, organizational assignment, and job information. The screenshot below shows the position assignment and organizational assignment for an employee can be seen below.


Here we can see the different elements of the organization structure that we have discussed. In the screenshot below we can see a demonstration of the associations example that we discussed above.



A Job Classification object (also a Foundation Object) contains details of an employee’s job role. Like in SAP, many employees can be assigned the same Job Classification (although in SAP this is through the Position object). It defines a large number of attributes about the job that an employee will hold, such as weekly hours, employee class, pay grade, and whether the employee is full or part time. In the standard-delivered configuration Job Classifications are associated to Business Unit objects. Country-specific information can be stored on a Job Classification object.

When a Job Classification is assigned to an employee a number of values from the Job Classification Foundation Object can be propagated. This is often common fields like Job Title, Pay Grade, Standard Weekly Hours, etc. The screenshot below shows the Job Information of an employee in the Job Information portlet. This information appears below the Organization Information seen in the above screenshot.


What about Positions?

Employee Central – as well as SuccessFactors – leverages the Job Classification as the standard “job role” of an employee. However, it does also support full Position Management if required. In SAP HCM, the Position object is mandatory for every employee, while use of the Job varies from organization to organization. In Employee Central Positions are not linked to the Organization Structure, which provides customers a choice of whether or not to use Position Management. Positions can have parent positions and thus a Position-based org chart is available in SuccessFactors. Positions are Generic Objects and are managed through the Metadata Framework.

How does this all compare to SAP ERP HCM?

I believe that the flexibility of the Employee Central organization structure enables organizations to more accurately setup a structure that truly reflects how they are organized. Although this is possible in SAP ERP HCM, it cannot be done with the level of granularity and accuracy that is possible in Employee Central. It is a simple yet effective way to accurately represent the organization within Employee Central as it is structured outside of the system. Many of the organizations that I have worked with have no problem with leveraging the Employee Central’s Foundation Objects to represent their organization structure in Employee Central as it fits how they operate and how they think organizationally.


The organization structure in Employee Central is extremely flexible and enables organizations to design their organization structure in a way that reflects the real-life structure of their business. SuccessFactors provides endless possibilities in how this can be configured and managed in the system and provides customers with a method to create an enterprise structure that suits their business. Customers should ensure that they investigate the integration options available if they are going to maintain an organization structure in SAP HCM. The standard integration provided by SAP will integrate the standard organization structure from SuccessFactors, but customizing this structure will mean additional mapping and integration work.

You must be Logged on to comment or reply to a post.
  • Hi Luke,


    That's awesome article!


    I ain't sure my question still related or not but I'm curious about object "Position". It's so different between on premise. When creating position in SF, there are some fields related with "Grade" (whatever grade it is, job grade, position grade, etc).

    my question :

    could you help me to understand more about that grade or level compared to HCM on premise?Which one is employee group, employee subgroup, pay grade in infotype 8,etc.


    thank you before




    • Hi dk,

      Thanks for your comments!

      The Grade field can be used the same as in SAP HCM, i.e. the Pay Grade field in IT0008. However, it can also be used differently (e.g. grade level) and a custom field can be used for the SAP Pay Grade field. However, I'd recommend sticking standard.

      Best regards,


  • Hello Luke! Thanks for the article
    I would like to know if different workflows approvals can be triggered at the foundation object level
    For example, having a workflow when a department is created, a different workflow when the name of the departament is updated, and a different one when the parent department to which it belongs is changed
    Or only one workflow can be defined for all actions on the departament foundation object
    Also, can you define different workflows for each foundation object? Meaning departaments, job codes, etc
    • Hi Andrea,

      You can assign workflows to any of the effective-dated Foundation Objects (i.e. those that store effective-dated records). Workflows will always trigger when a Foundation Object is created, changed, or deleted. You cannot choose any one of these; they will always trigger on all scenarios. You also cannot define a workflow just for a specific-field; it will trigger for any change.

      There is some additional flexibility with the MDF-based Foundation Objects due to the MDF framework.

      Best regards,


  • Hi Luke,

    There are few comments about SAP HCM and its flexibility compare to SF:

    1. PE03 is not the only way of propagation. I would consider the "Inheritance" for OM. And it means much more than just PA features. It allows to inherit a lot of information from OM: cost centers, pay structures, personal area and subarea, employee group and subgroup.
    2. SAP OM provides the opportunity for multidimensional structures. For example, 1. Standard hierarchy (normal reporting structure) objects O-O-S-P, 2. Custom dimension (as in SF) Legal Entity -Busniess Unit - Division - O - O - S - P, where Legal Entity - BU - Division are custom objects. And similar to above I can set up any other dimensions in SAP as I need, while in SF it is not possible. And by the way what if customer has another hierarchy definition: Division - Business Group - Business Unit - O - O - S - P? In SAP it is not a problem at all.
    3. Company code and cost center are not OM objects in SAP (though cost center has K key). They are originating from SAP FI/CO and can be inherited (propagated) by employees from OM or assigned directly in PA. This is key difference with SF, because there is no native integration between SF and SAP FI/CO.
    4. OM position is not mandatory for every employee if PA-OM integration is switched off. On top of that OM integration can be switched on and off for a specific company / country based on their needs/readiness. It is quite flexible.
    5. Location is not personal area / subarea in SAP. Many companies do that, but it has much bigger impact on time management and payroll. Obviously it is not a case for SF, because there is no payroll and limited time management. As long as we are talking about OM, location is a characteristic of OM object saved in dedicated infotype, but not an object itself. Although there is object Location in SAP, but it is used in another module. Location can also be added to employee in PA only. There is a lot of flexibility in SAP.



    • Hi Vladimir,

      Thanks for your comments. I'll respond point-by-point.

      1. Thanks. The inheritance works similarly in Employee Central too.
      2. Legal Entity, Business Unit, and Division are standard objects in SuccessFactors. It is possible to add custom objects into the hierarchy with whatever relationships to other objects (standard or custom) as are needed. This can also be mapped to standard or custom objects in SAP.
      3. There is no "native" integration, but there is standard integration bring cost centers from finance into SuccessFactors so they can be assigned to employees and - if needed - then this can be replicated back to SAP.
      4. This can be achieved in Employee Central, but it's not quite as flexible as in SAP HCM.
      5. The Location object in Employee Central maps to the Personnel Area and Personnel Subarea in SAP HCM by standard. It's also possible to create custom objects, but the standard integration handles it with Location to PA/PSA. SF does have payroll, albeit with the SAP Payroll engine as the core engine of the solution.

      Best regards,


  • hi,

    I have one question regarding the association between foundation objects. In one of our client the lowest level is division. ie they have legal entity,business unit,department and division. I need some suggestion regarding the design. whet would be the best practise to achieve this ?


    1. Changing the label of division to department and that of department to division. OR
    2. creating custom association between division and department. ie i will move department up create association of department with business unit and association of division with department.

    Your response would be greatly appreciated.


    Thanks and regards


    • Hi Manish,

      First, I would advise the client that a Department is a sub-division of a Division and thus as part of their transformation they should consider re-aligning with the correct terminology.

      Should they wish to retain the current terminology, I would potentially consider creating a custom object or changing the labels as opposed to swapping objects. This is because other parts of the system and the integration between SAP and EC uses Division and Department as they are intended to be used and this would cause some issues with the way your customer uses them.

      Best regards,


  • Thanks luke,

    One question if we go with the approach of changning labels wont it have impact on the UDF and integration because then we also need to change the labels everywhere we have division and department like for eg in UDF,LMS,Manage pending hires ....... also during the directory search ect


    Thanks and regards


  • thanks luke for the prompt reply

    if we don't change the label but just go with the custom association ie the structure will now look like legal entity--> business unit --> department-->division-->cost center. what impact does it will have according to you?. because now the object is same only the association is changed the data will flow properly to UDF

    Just wanted to know the realtime impact for this association.


    thanks and regards



    • In the UDF and talent applications you'll find that the EC division objects are in the Department field, because it's a standard system mapping.

  • Hi

    My company is new on EC/SuccessFactor (since 16 DEC 2019) and now I have to make a position "manager" of two departments but I really do not know how to manage that?

    Any one who can help?

    • Typically a department head is assigned directly to a Department object. Without knowing your configuration, it's difficult to know if this is possible. By standard it's not how the system is used, but you might have a different configuration.

  • Hello Luke

    I want to know what happens if a company decides to assign some employees only to a bussiness unit and create and association from this object to the cost center. Can an employee in their job info have only information of the bussiness unit to wich belongs and have no records in the field of division and department?

    If so, when replicating information to SAP ERP how the employees who are only assigned to a bussiness unit are differentiated from the employees who are assigned to a department and have the three fields in their job info (BU, division and department), wich of the three objects will be replicated as the organizational unit it occuppies?

    • Yes, this scenario is possible. Your configuration would need to support it (i.e. with the relevant associations or without associations). You would need to configure the integration to identify what to do with these employees. For example, that if they only had a Business Unit then they would be assigned to the corresponding Organizational Unit object in SAP.

      The standard integration uses Department as the Organizational Unit.

  • Hi Luke,

    Great article and very informative.

    I am new to SuccessFactors and was wondering if it is possible to integrate the SuccessFactors Employee Central Organization Structure to SAP or if you need manually maintain the Organizational Structure directly

    • Hi Ian,

      Thanks so much. There is a standard integration to replicate the org structure from Employee Central to SAP.

      Best regards,


  • Hi Luke, great article and thanks for the information.


    I have a doubt is recommendable associate one business unit to many legal entities?


    Felipe J

    • Thanks Felipe. It really depends on your company structure. The structure in EC should generally represent your actual company structure, so if a business united is shared among multiple legal entities in real-life then it would be fair to have the same representation in EC.

  • Hi Luke

    I am new to SF. I would seek you advice on org structure. Our org structure order is BU - company - division - dept. My question if we create a position for the BU head, can the position tie to BU object or we need to create a department object for such position.

    Thank in advance your guidance




    • Hi Wilson,

      The BU has a Head of Unit for a person, but if you want to have a position associated with the BU for the Head of BU then this is possible.

      Best regards,


  • Hi Luke,

    I have a question regarding the company structure.

    Once the company structure is built, is it possible to add some organizational levels afterwards?

    For example: today we have Legal Entity – BU – Division-Department-Custom Object 1 and to change it later for Legal Entity – Custom Object 2 – BU  – Division – Department – Custom Object 1? How this will affect the system?

    I can imagine that it’s more simple to add a new level at the bottom of the chain but to insert it between levels I suppose that this is not an easy work.

    Thanks in advance

  • Hi Luke,


    Thanks for the great blog. Need your expert opinion on below scenario:

    Our client has local (Legal Entity specific) Jobs and Pay Grades rather than global. Since, in SF by standard all the Jobs and Pay Grades are global.

    To cater above requirement, we are thinking of adding custom association in Job Classification with Legal Entity and also in Pay Grade with Legal Entity and then apply field criteria on Job Classification (to filter Pay Grade as per Legal Entity of Job Classification), Position (to filter Job Classification as per Legal Entity of Position), Job Information (to filter Job Classification as per Legal Entity of employee).

    Question is, should we add Legal Entity as an association or as a Generic Object field on Job Classification and Pay Grade objects? Also, what is difference between the two approaches?




    • Thanks Amit.

      Using associations would be the best option to restrict Jobs and Pay Grades locally. Depending on how you define "local", you could use the Legal Entity object or Country object to associate Jobs and Pay Grades by country. If you need more granularity, then you could use another object or a combination of Legal Entity, Country, and/or another object.

      Best regards,



  • Hi Luke,

    Read your blog and wondering if EC can do org scenarios in the tool (as opposed to Excel sheets, and PowerPoint -- all manual).  Can you drag and drop divisions from one business unit to another and play around in the orgchart with EC?

  • Hi Luke,

    Thanks for the Blog. Need opinion in the following scenario.

    We have a Org Structure which is Legal Entity(Renamed label as Org Unit) - > Business Unit(Renamed label as Function) -> Division(Renamed label as Vertical) -> Department(Renamed label as Business Unit). We are using this org structure for the past 2 years since EC was live.

    Now, Organization wants to change the complete structure with the new names to label and the data maintained within the foundation objects. Remove the old structure and bring in new structure. Employee data which is maintained till date to be retained as history and new structure need to reflect in employee data with the future dated entry.

    Just need to know the feasibility and impact on doing above changes in Org Structure.

    Thanks in Advance.

    Thanks & Regards,

    Jaikumar R.

    • Hi Jaikumar,

      This is possible, but it is of course potentially a rather complicated task. You'll need to build the new org structure and then perform updates using Mass Changes or a Job Info export/import to change all the employee records (i.e. export the Job Info file, add new records for the changes, and import it).

      Best regards,