Skip to Content


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

  1. Stephen Burr



    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




    1. Former Member Post author

      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.




    2. Former Member

      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




  2. Luke Marson

    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,



    1. Former Member Post author

      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,


      1. Luke Marson

        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,



  3. Former Member

    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?                                        

    1. Former Member Post author

      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,


  4. Former Member

    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 ๐Ÿ™‚

Leave a Reply