Skip to Content

SuccessFactors: The X Factor of Data Models

After working with XML (Extensible Markup Language) data models, I thought that a blog covering the SuccessFactors data models would be helpful to the community. This is not intended to be a crash course on XML (see the W3 Schools XML Tutorial to get an understanding of XML), rather I want to enlighten you about XML data models and eradicate any fears in understanding them. All of the XML Gurus out there may find this an over simplified version but the goal is exactly that; to start from the basics for XML novices.

So let’s start by seeing why XML? The following picture summarizes the key benefits of using XML.


Now let us compare with how it complements the design of Employee Central and for that matter any of the solutions in the BizX suite that leverage XML data models. The value proposition of SuccessFactors BizX suite is founded on the following principles:

  • Ability to progressively advance product features
  • The organic design warrants a platform where making changes is not time consuming and with minimal retrospective compatibility challenges
  • Align the existing features with enhancements being requested by customers

XML is the preferred language to deliver the above-mentioned values to customers. All of this makes for an exciting world for a SuccessFactors consultant!

So let’s look at some of the frequently used data models in Employee Central. The Employee Central chapter in the SAP Press book SuccessFactors with SAP ERP HCM will cover this topic in more detail.

Before we step further, here are a few basics:

  1. What is the best XML editor?
    1. There are a number of choices, I compared Oxygen and XMLspy and settled for Oxygen, works perfect for my dear Mac Users.
    2. XML parser in Oxygen is more effective and you don’t have to wait to see errors until you are uploading the data model in Provisioning. It is easier to troubleshoot errors when you are validating your XML.
    3. Oxygen support is responsive, I have troubleshooted with their help!
  2. Do I need to know HTML, XSLT, coding etc. etc.?
    1. No you don’t, these data models use DTDs (Document Type Definitions).
    2. You generally should not have to tinker with these but I have had to add a number of attributes after the 1302 release.
  3. What is a DTD?
    1. A DTD is a document type definition that defines the document structure and elements of your XML. For example, if a new hris-element is introduced in a new release and the DTD does not contain that element or any related attributes you will receive errors that you cannot move past.
  4. What do I have to do after I have defined the customer’s requirements in the data model?
    1. In Provisioning upload the data models to your customer’s instance. Any errors that may not have been caught by the XML parser will be caught here so don’t be alarmed if you see errors here.
    2. The most frequent mistake is trying to upload a data model through the wrong link in Provisioning. Unfortunately currently you don’t see an error but the processing will happen endlessly before you wake up and realize your mistake.


Now that you know all that you need to know about data models and DTDs let us cruise through the 4 main data models used in Employee Central. There are 3 others used for workflow, rules, and Propagation.

Note: Propagation is the feature in Employee Central that allows for foundation data to be automatically populated on the HR data objects. For e.g. if you stored the time zone on the location foundation object, you can build a propagation such that the time zone is automatically changed on employee data based on the value of location selected.

  1. Corporate Data model

    1. Used to define the organizational structure
    2. The foundation objects are configured here
    3. There are standard hris-elements that you work with in this data model. Each element in turn has standard and custom fields with attributes that determine their behavior on the UI.
    4. Associations are built in this data model
    5. Below is an example of a corporate data model showing the Company code hris-element. The attributes defined determine the UI behavior visibility determines whether the field is edit, view or both. “Required” determines if the field is mandatory or optional. The following is the text view in the Oxygen XML editor.


  2. Country Specific (CSF) Corporate Data model

    1. You define the country specific features for elements already defined in the corporate Data model
    2. This data model comes with some standard delivered localization elements like National ID etc.
    3. You have to define a hris-element in the Corporate data model in order to specify the country specific behavior for that element
    4. Below is an example of the country Specific Corporate Data model showing a few countries and delivered hris-elements. You can add any hris-element defined in the Corporate data model to add country specific requirements. The following is the grid view in the Oxygen XML editor.


  3. Succession Data model

    1. You define the HR data (Person and Employment) in this data model. This data model is called “data model” in Provisioning
    2. With the rapid advancement of the Meta data framework customers can configure most of the elements on the OneAdmin UI
    3. Below is an example of the personalInfo hris-element in XML

Succession DM.png

       d. The same element can be configured in the Metadata Framework via OneAdmin UI by going to Manage Business Configuration


  4. Country Specific (CSF) Succession Data model

    1. The country specific succession data model is used to define country specific requirements for elements defined in the succession data model
    2. For example, if you want to define US specific fields to store Global Info you will do that in the Country Specific (CSF) succession data model, similar to the CSF Corporate data model

You will be working most frequently on the standard hris-elements hence selecting them for discussion. There are a number of things you can do with the background elements in the Succession Data model, such as create custom views for the client and it is synced with the Employee profile and other integrated products of the BizX suite.

I hope this blog helps to unravel some of the mystery and open questions in your mind with regard to data models and gives clarity of thought if you are one of the many SAP consultants looking to transition to SuccessFactors. Your openness to the new way of doing things in the SuccessFactors world will determine your success. Use your SAP expertise to design the architecture that is right for your clients. The transition to SuccessFactors does not require letting go of skills, but acquiring new skills and using both in synergy to deliver value to customers and make them efficient and profitable with an engaged workforce.

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


    Thanks for taking the time to share.  I've used XML in a variety of applications before and I have found that there is a common mis-conception that XML is one skill.  While I think there are some basic XML skills, the main skill is understanding the purpose of the XML (as defined in the DTD) within the context of the application in which it is utilised. That's to say the XML used in Ariba cXML or Nakisa conifg or SuccessFactors share some but very few similarities.  You need to learn the context in which each is used.


    Errors will occur when the XML is either not "well-formed" (missing syntax, e.g. not closing a tag) or not "valid" (not confirming to the DTD). 


    So, for not so technical SAP consultants, they shouldn't be afraid of XML ... as you say, with some openness to it, basic understanding and time to learn the detail of its specific use (DTD), then they can soon put it to good use.  I know it is also extensively used in SuccessFactors for defining forms and role permissions to fields.


    Keep on blogging




    • Hi Stephen,


      Thanks for your excellent insights. As I was reading your comment my smile widened. Yes you hit the nail on the head, understanding the context is of prime importance. Also the context varies with what the XML is doing based on the product you are implementing, EC or talent suite. From my experience once you get a hang of troubleshooting the errors you would have created a comfortable spot for yourself in XML. My hope with this blog is to help those "in-between" consultants steer towards openness.




    • Thanks Stephen,


      I am functional consultant with very basic technical knowledge learning Success Factors ,with this post my confidence levels increased and approach towards  learning XML softened .


      Thank you for the comments




  • Hi Jyoti,


    Great blog and this will really help to inform the community of what skills they need as a foundation to implement SuccessFactors. For many this will be a new skillset and won't relate to how they are used to configuring SAP. There is a skill to using XML, but like Stephen said the context is very important to understand the content of the document and what it is used for. However, overall XML is not difficult learn or understand


    I have been working on the custom Foundation Objects introduced in 1302 and that is one of the most widely used features by customers to design their org structure. One addition that is worth mentioning on the Succession data model is that customers can link the custom foundation objects to appear alongside standard Foundation Objects in the job information section. For example:


    <hris-field max-length="256" id="custom-string2" visibility="both" type="GO_subdivision">




    Best regards,



    • Hey Luke,


      And the blog keeps getting better with your intelligent and well placed additions as always. Yes "skill" is the most accurate description of what it requires to be adept at XML and am sure nobody knows that better than you as I have had the privilege of witnessing your XML prowess.


      You make an excellent contribution on the custom foundation objects. In the spirit of reader's interest, the only thing I will add is that the custom foundation objects are created through the metadata framework (MDF), called Generic Objects represented by GO in your sample code and then one goes to make the connections in the Succession data model.


      Warm Regards,


      • Hi Jyoti,


        Thanks for your comments - I appreciate them. It's definitely worth highlighting the use of the MDF to create GOs and I plan to put out a blog on the MDF later in the year.


        Best regards,



  • Great blog Jyoti. I like how you talk about the main Data Models and how they interface with One Admin for EC configuration.

    It's also very intelligent to mention that you do not need hardcore XML skills (like XSLT, parsing etc ...). Well done. Note that, if you do not need to fully understand the DTD language, the DTD files usually contain a lot of embedded documentation in the comments; so taking an hour to read through the sf-form.dtd can be a very good initiative.

    As a suggestion of XML Editor, I would add XMLPad, which has the same kind of Table View as XMLSpy, but at no cost.

    What is the editor you use in your screenshots?                                        

    • Thanks for your comments Julien. Good point on DTD review, it is definitely a valuable 1st step. Thanks for adding XMLPad, just to add that it is only Windows compatible. I have used the text and grid/table view in Oxygen XML Editor 14.1.


      Warm Regards,


  • WARNING: It might seem like a very simple comment here but BE WARNED! There is no check and balance on the SF side for whether or not you are importing the right data model into the right instance! It is so very easy to import into the wrong customer by accident if you are moving too quickly. So make up a very strict process for yourself and ALWAYS follow the process! Here is mine:

    1. Use the alpha link at the top of the provisioning page to limit the number of customer instances you can see
    2. click the appropriate customer instance name
    3. download the data model TWICE!
    4. mark one as ORIGINAL with a date and archive that one
    5. add a date to the 2nd downloaded data model
    6. make your changes in the data model
    7. before uploading, CHECK THE CUSTOMER INSTANCE NAME at the top of the page
    8. CHECK THE NAME AGAIN and import
    9. test and make changes again
    10. repeat 7 & 9 every time before importing more changes
    11. do this EVERY TIME you ever make data model changes no matter how good you think you are 🙂