Extending SuccessFactors with the Metadata Framework
As part of the SAP PRESS title SuccessFactors with SAP ERP HCM I was lucky enough to have an hour-long private session with Mike Rossi about the SuccessFactors Metadata Framework (MDF). Mike was kind enough to give me an overview of some of the details of the MDF, as well as some of the upcoming functionality. In this blog I’m going to provide a high-level overview of the MDF, how it works, and what it means to customers and consultants.
About the MDF
The MDF is a UI-based configuration and extension framework that provides creation, modification, maintenance, and deletion of custom objects (called Metadata Objects) within the SuccessFactors HCM suite. It replaces XML-based configuration and the need to import Master Data via CSV/Excel files. It is also leveraged by the SAP HANA Cloud Platform.
At its core the MDF provides one generic set of the components that are re-used by all objects. This is because each object’s data is Metadata – nothing is hard-coded within the SuccessFactors system. These components include:
- User Interface (UI)
- Data Access Object (DAO)
- Database table
- Implementation of Role-Based Permissions (RBP) Security
- Logic Services
- Set of Java services
- Reporting integration
This means that there is no additional processing or memory consumption to use additional custom objects in the system. It also means that there is a common framework for the objects; the Metadata Objects only need their behavior to be configured through the UI and they have consistent behavior and design. And, most importantly, there is upgradability because standard objects and components are not changed. For example, when creating a Metadata Object attributes such as field names, the field data type, and the validation rules for each field are configured. The components such as the API, user interface, and database tables do not require configuration – they automatically work with the user’s custom definitions. All of this means that SuccessFactors can deliver features faster as they do not need to write code and customers can extend their system without the need to write a single line of code.
Customers cannot overwrite standard SuccessFactors objects, but through the MDF they can configure standard objects with their own customers-specific attributes. For example a customer could create attributes of a Job Code object that are specific to their business, but this would not change the SuccessFactors Job Code object – the customer’s changes would be saved separately and would just override those supplied as standard. From a customer perspective they are unable to identify this, but from a technical perspective it helps maintain upgradability of the system.
Although SuccessFactors applications do not use genuine objects in many of the Talent Management applications, this will change once the MDF is rolled out across the SuccessFactors HCM suite. Currently it is available in Employee Central and Succession, Time Off, and the new Job Description Manager application. There are further plans to extend it across the entire SuccessFactors HCM suite. For example, it is planned for SuccessFactors Recruiting to use the MDF from 1311 with more functionality added in the next 2 releases. Since this requires re-architecting of the Database layer and Application layer then this is by no means an easy activity.
The structure of each Metadata Object is fixed, although there is a degree of flexibility. Customers have the ability to add up to 200 custom fields for each Metadata Object, in addition to the standard attributes that are required. These required attributes can be seen in the screenshot below.
There are also some attributes that contain system assigned data, including Internal ID, Creator, Creation Date, Last Modifier, and Modified Date.
Metadata Objects can leverage effective dating if required and labels and data can be maintained in multiple languages if any are enabled in the system. They can also have associations (relationships) assigned, just as it is possible with standard objects. And Metadata Objects can have rules triggered at 9 specific points within its transaction flow. These points are called Hooks and allow rules to be executed at point such as during object initialization, when a field is changed, before data is saved, or after data is saved etc. Here is an example of the Position object with rules assigned during the initialization or creation of a position. You can assign more than rule at Hook.
In addition to the standard Metadata Objects there are also other types of Metadata Object, such as Rules, UI components, and Picklists. I will not cover these in this blog, although Rules and Picklists are covered in the blog Rules and Picklists in the SuccessFactors Metadata Framework.
Using the MDF
The MDF is accessible in OneAdmin for system administrators – these are under Company Settings and Employee Files.
Below shows the Employee Files options in OneAdmin. Note that the transactions for Manage Time Off Structures and Manage Time Off Calendars are not available unless the Time Off feature has been switched on.
In the old Admin Tools look for the section called Generic Objects.
OneAdmin provides multiple options for managing different types of Metadata Objects. It also allows you to import or export Metadata Objects. These options are:
- Configure Generic Object Definition: Create, modify, or delete Metadata Objects (e.g. Building object) and Picklists
- Manage Generic Objects: Create and maintain instances of Metadata Objects (e.g. Building number)
- Manage Rule Objects: Create rules and validations
- Manage Position Objects: Perform Position Management that is used within Succession & Development
- Manage Time Off Structures: Create, modify, and delete different Time Off structures (e.g. Work Schedule)
- Manage Time Off Calendars: Create, modify, and delete holiday calendars
- Manage Config UI: User interface designer
- Generic Objects Import/Export: import or export Metadata Object data
The screenshot below shows a new instance of the Country object being created in Manage Generic Objects.
MDF v SAP HCM
The principles and technical aspects of MDF differ from SAP HCM. Within SAP HCM when you create an object type, very little object-specific information is maintained. Rather, the infotypes and allowed relationships for the object type are maintained. New fields for new objects require new infotypes or using standard infotype fields in a different way from which they were designed. For more detail on the process of creating new object types see this blog.
In SuccessFactors – as we have seen – the process for creating an object is based in a single screen and is significantly simplified. Although more data can be maintained, it is structured and easy-to-use each time that you create an object.
What the MDF means for customers and consultants
The MDF means simplification and flexibility for creating new objects. It provides a flexible and consistent framework for customers and consultants to extend the object model of SuccessFactors and add their own unique objects, rules, validations, business logic, and UIs to SuccessFactors. It also means that while the SuccessFactors system is adaptable, it retains its upgradability and protects both the application and the customer from issues caused by enhancing the standard system.
However, it should be noted that management of the system is still required and the MDF is not intended to be available to large audiences. Rather, it should be managed in the same way that the authorizations are managed to restrict access to transactions in SAP in which objects can be created or maintained. It should also be managed as such so that Master Data is created by a central team, as would be the case with SAP. Saying that, the MDF now makes it possible for a business user to be able to enhance the standard SuccessFactors system without relying on a technical consultant or other technical individual to do this.
For consultants, it removes the need to maintain XML and thus reduces the likelihood of introducing errors into the system. In my experience of XML, it can be easy to introduce small errors that render the XML unparseable and are difficult to identify. It also makes extending the system much quicker and provides an object-orientated approach to data design and maintenance.
The MDF is a powerful object configuration framework in SuccessFactors. It empowers system administrators to easily extend the SuccessFactors object model and create objects of their own. It also allows organizations to introduce their own rules, validations, and business logic to both standard and customer-created objects. The UI designer means that customers can control the visualization of their objects and take advantage of the benefits of the SuccessFactors UI.
Although not fully rolled out across the SuccessFactors HCM suite, the MDF will introduce a huge level of flexibility once it extended to cover all of the solutions in the suite. And although the MDF is very flexible and removes the reliance on technical consultants, it is not a replacement for a well-managed system of maintaining object types and Master Data. All-in-all the MDF is a huge step forward for SuccessFactors to provide optimal configuration and extension options across the SuccessFactors HCM suite.
The MDF is covered in detail in the SAP PRESS title SuccessFactors with SAP ERP HCM.
In the August (1308) release some of the options for the Metadata Framework in OneAdmin were changed. The changes are:
- Configure Generic Object Definition = Configure Object Definitions
- Manage Generic Objects = Manage Data
- Manage Rule Objects = Configure Business Rules
- Manage Position Objects = Manage Positions
- Generic Objects Import/Export = Import and Export Data.
Thanks for the useful post Luke!
Needed some additional features checked in provisioning and authorizations to turn MDF on in my demo-system though;)
The MDF is not enabled by default, although it is usually enabled in demo environments. At a customer you need to switch on "Enable Generic Objects" in Provisioning. In addition, based on which feature you are implementing (e.g. Position Mgmt, Time Off etc), you also need to check additional options accordingly. With respect to authorizations, RBP selections are required only if you configure your Generic Object definition to be secured.
Very Good blog Luke and not hard to see the power and flexibility that MDF brings to the table especially when it is incorporated into the entire SuccessFactors suite of products.
Thanks Jarret and I agree. Once the MDF is rolled out fully it will provide a lot of extensibility for customers and will make SuccessFactors a real option where previously it might not have been.
Excellent blog Luke. I like how you have struck the right balance between the foundation of MDF and given us a quick peek into some of the highlights of MDF objects. I do like your succinct comparison of MDF with SAP HCM. I can vouch that both customers and consultants are loving what they have seen of MDF so far and have appetite for more.
Thanks Jyoti - that means a lot from an expert like yourself. The feedback I have received from customers is very positive, although for some they still need this rolled out further across the BizX suite to reap the full benefits of SuccessFactors.
Would it be a fair comparison to say that the hooks could be used in a similar way to an SAP event? Linking and creating a sequence.
Yes. A hook is like a user exit or adding some code in a BAdI or an Enhancement Point of a function module. They are in set places where it makes logical sense for an event to occur.
Many thanks for the sharing. I read about the various enhancement options like MDF (as you've written), via XML and foundation objects. In typical SFSF implementation that has gone 'live', can customers (assuming they have the know-how) do these enhancements (big or small) themselves or do they have to depend on SFSF or its partners to do at a cost ? For on-premise, it is clear.
Is this the same model (i.e. customer can do vs. all controlled by vendor) with other SaaS like Workday etc. ?
Thanks and regards,
Hi Kir Chern,
The MDF allows customers to manage extending the data model themselves so that they do not need to rely on professional services, much like they can do with SAP (although it is much more complicated in SAP). Previously to the MDF customers relied on professional services of SuccessFactors Professional Services or partners to implement changes in XML - if changes could be made at all. Now this reliance has gone with the MDF.
It is important to note that the process does need managing so as to not create duplicate or unnecessary objects. Master Data (as we know it in SAP HCM) needs to be carefully managed.
this time it feels a bit as if I am getting late to the party!
Great blog. One question, and one comment...
Would you be able to provide an example of the hooks function? the screen above show that they are used for the position object, but I am fuzzy at what they actually do, as relationships are mentioned separately. 🙂 that is a part that I haven't yet seen in action.
Comment. Yes, MDF provides a tremendous flexibility to customers - with the possibility of easy development to be done without a big expertise requirement. HOWEVER in my experience a large part of the work in extensions project is the definition of the requirements and how they will interact with the standard features and avoiding un-necessary loops. In the end, it is not only the cost of developments, but we are also talking about the costs of running a system long term (including ensuring data integrity). The technical layer now becomes easier - but without the utmost restraint and great business foresight, we'll witness very complex results.
It's always better late than never!
Hooks are a point where a Rule can be triggered for the object or field (it can be for either). For an object, you have the 4 distinct points shown in the screenshot above where one or more Rule can be triggered at that stage. For example, you can add a Rule at the validationRules hook to check that the Job Code you entered is valid and then in the saveRules hook you could call a Rule to update the Pay Grade if the Job Code is of a certain type. Associations are relationships between objects that relate to how they interact with each other or when there are parent-child dependencies.
You've absolutely hit the nail on the head with your comment. I alluded to this in the section "What the MDF means for customers and consultants" because the governance and compliance around MDF should be no less than in SAP HCM - in fact, maybe it should be more given the freedom and ease with which Metadata Objects can be created and modified. With great power comes great responsibility, to quote my favorite comic book (Spiderman) 😉
Agree with you - it possibly should be more, because with the MDF being of such an easy access, there is a layer of counseling that is not there. Now, it is true that many consultants didn't have (and many still don't) have the business experience to play a role of trusted advisor...
Couldn't agree more! 🙂
😉 unlike us, right?
Thanks for sharing this with us.
If I need to custom new fields in SF to a form, would that be the location to do that from the admin tools?
I have a PM form which I'd like to add new fields to it, would that be done by using the SF admin tools for new fields? in other words, can I create and edit the new fields in the PF admin tools or I need to SAP HCM system for that?
Since we do not have the SAP HCM system and just the SF system, would that be sufficient to create new fields at SF system?
The Metadata Framework is not yet available for Performance & Goals, so it cannot be used to add or modify objects in Performance & Goals.
To add new fields it really depends on your exact scope. You could add a new section to your template, but I don't know if that suits your needs or not. You can also look at SuccessFactory.
Thanks for this Excellent Blog.
Quick question: As you mentioned -MDF Objects can have rules triggered at 9 specific points within its transaction flow ( Hooks ). For an object, we have 4 distinct points ( Save, Validate, Initiate and Delete ). Can you please share what are all the other 5 points? Are they field level?
The hooks are technical, since they vary by type (e.g. object type, object-level, and field-level). Basically, from an end-user perspective you need to look at:
Some objects also have other hooks, such as on-the-fly calculations. See the rules engine handbook for more details.
Many thanks Luke.
Great article! I should say i went to your article soon after reading the implementation guide for MDF as there may be some requirements to create MDF's at my project.Your article is a great summary of what is there in the MDF implementation guide. One question , how do we replicate what i would normally do through an HCM P&F in SAP HCM within SF.Say for example i want an online form to be filled in by the employee which would need to update certain fields in SF.
Thanks Harris! My blog actually precedes the MDF implementation handbook (in its current state) so that's good feedback to get.
You could use the MDF to create a form object and then use rules to propagate information on the target portlet (e.g. JobInfo). You can also attach workflow to the object so that the data won't be updated until it is approved. I would also consider looking at using an EC extension on HCP rather than MDF if you think it could be a complex process.
thanks a lot for that great article ( as always ). One Question: Do you expect MDF and HCP extensions comming for performance and goals ( and succession) ? Today I spent some time on SCN and SAP related sites and I do not find any informations on that topic. All slides, PDF's and videos related to that topic deal only with EC.
Thanks for your feedback! As it stands right now, MDF and the extensions package on HCP are only available for Employee Central. There are plans to roll this out to Recruiting this year, but so far I have not heard of any timelines or additional plans to roll this out to Performance & Goals. I will update you if I hear more.
thank you for your answer.
Readers of this blog might enjoy this article if they have an SAPexperts subscription:
Creating Metadata Framework Objects in SuccessFactors Employee Central
Could you give update on the current status of MDF & latest Blog link.
Many Thanks !
MDF continues to have its capabilities extended. There are no blog updates at this time.
Thanks Luke for providing excellent article on MDF.
Can you please advise if I want modify behavior of foundation object then should that be done from MDF or using export corporate data XML and making changes before importing through provisioning account.
Moreso in my demo system I cant find option "Manage Organization, Pay and Job Structure" link under employee file. Also exported corporate data model from provisioning I find XML file only contains string "corporate-datamodel.xml is not imported prior to export." Not sure why corporate data model is blank in my system.
Foundation Objects are not managed through MDF as they are not MDF objects (although that will change in the future). It sounds like you have a non-EC demo system or a demo system that hasn't had EC loaded. You will need to check that you have the correct Provisioning settings, upload the standard data model, and permission your user for the "Manage Organization, Pay and Job Structure" link.
Thanks Luke for prompt reply. This system was originally configured for RCM. I also think that corporate data model has not been loaded. However if I want to configure EC then where do I find standard data models. Can I use option of uploading Pre-packaged templates as mentioned below?
You need to download them from Partner Portal.
Thanks Luke for help !!
Does MDF support Performance Management at the moment?
Not at the moment.
Is MDF going to replace all XML's part config. How much difference can we notice if SF switch completely to MDF's.
I believe that one day all XML-based configuration will move to MDF, but that will take some time. EC is moving to MDF first and the difference for customers means that everything can be configured in the UI with no XMLs.
This is a really useful blog 🙂
I have one question on import/export functionality. Is there any way of creating an MDF object definition in one tenant and moving it to another tenant using export and import as file? If I have a set of MDF data objects created in one tenant and I want to create same objects in another tenant, is there any way of moving them as file system.
I have seen the option export metadata to file options but not sure whether that is the correct way of doing it or not.
Thanks and Regards,
Yes, you can export MDF objects from one system and import them to another (this includes rules and configuration UIs). However, bear in mind that when they are from different systems with different languages and configurations that the object definitions will not always import without some form of modifications.
Within the same customer system, you can copy MDF objects from one instance to another using the Instance Synchronization Tool. This is the recommended solution for a customer.
All the best,
I have got the Instance Synchronization Tool enabled in provisioning account. Could you please tell me how to access the tool from my tenant. I am not able to see the option. Do I need to check some options in admin roles?
Thanks and Regards,
I got the options to enable it 🙂 but now I am facing another issue.
In the screen below, I need to get my target instance, Could you please tell me where to set up this configuration.
Thanks and Regards,
Is this a demo instance or customer instance? If it is a demo instance you won't get any options.
All the best,
So I won't get that option as i am on demo instance. But can you please tell me whether there is some separate configuration steps to be done other than just adding the customer instance in provisioning?
The tool only works to sync from one customer instance to another. You can't sync from a demo instance to a customer instance.
If you want to transfer configuration from a demo instance to a customer instance then you need to use the import/export options and then modify your object CSV files to ensure they can be imported (e.g. remove/add any languages that are not in the customer instance).
All the best,
I'm an enterprise integrations developer outside of the SAP stack recently tasked with retrieving data from the SF objects via OData calls for usage in another company wide application. I've had success with this-- in all but incremental searches, where I am looking for data between a specific date range. A query such as: https://api[dub].successfactors.com/odata/v2/EmpJob?$&$top=5&fromDate=2015-05-01&toDate=2015-06-10 does not return updated records within the date range. After reading your post, I see that this may have to do with how SF is configured. I am not well versed in SAP to know how to look to see if this is the root cause. I can contact our SF administrator, however, more broadly speaking, is there an OData call to the metadata framework which can answer that question? The calls to $metadata do not appear to include object definition info.
There is an special Entity called Entity 😉 which you can call to get object definitions
/odata/v2/Entity('PerPerson') for example
Is there a limit to how many MDF objects that can be created? If so, Is there a way to extend beyond the limit?
I enjoy your informative posts.
My understanding is there's a 25 MDF object limit for the full suite of modules unless you have Hana Cloud integration platform (HCI). Then the number can go up to unlimited depending on the contract. This is controlled in Provisioning. Hope this helps 🙂
The limit depends on the SAP HANA Cloud Platform license (not HCI). It can be more than the provided number if an additional license is purchased.
Opps, thanks Luke!
But also, you can use MDF objects without HCP at all up to 25. Once above 25, HC Platform is required. We had this issue with a customer that has EC but does not have Hana Cloud. There were allowed to use up to 25 MDF objects.
I have a question about import/export MDF positions.
Here's my understanding, please correct me if any mis.
1. Import employee profile through one .csv file
(Update user information > import employee data)
2. Import MDF position throuth one .csv file
(tool search > import and export data)
Is there any further steps need to be process? How can we find the relationship between employee id and position id?
These steps are correct. You define the Position Id in the Job Information import (called Job History in the Import Employee Data screen).
Thanks for the insight.
What is the property effective dating in MDF used for any clue?
It's used to define if you want data of your object to be effective-dated or not.
Thank you for your clear explanation, Luke!
Thanks for this articles but I need ask some questions about MDF. I can use MDF without Employee Central module?
Yes you can.
I am working in LMS and have requirement Meta Data tag for an Item or Curriculum, please guide or suggest how to do that.
LMS doesn't leverage MDF today.
I have a question regarding connecting a new MDF object for the employee profile:
I have created a new MDF object and assigned it successfully for the employee profile. However, I wish that each employee may have simultanousely several records of this object (just like the possibility to add an employee several nationality records under the "National ID Information" portlet).
Is it possible? and if so - how?
I know it's possible by using the background elements, but this option is not suitable for me becuase I also need to set different permissions for this object's fields (which is not possible doing by background elements).
You should use a child object to have multiple records.
still need detailed explanation on employee central
you compare the MDF with SAP-OM. Can you please comment on how you would implement OM evaluation paths within the MDF? This question is crucial for an application that I have in mind, involving long and customer specific evaluation paths.
I wouldn't quite say that the MDF compares with SAP-OM. MDF compares with creating custom infotypes in SAP PA/OM and/or creating custom object types in OM.
There isn't really a concept of evaluation paths in EC. You do, however, have associations between objects, but evaluation paths are not used.