Governance

One of the first aspects of any development or extensibility framework is governance. Protecting a system from the mess or damage caused by incorrect or excessive configuration is of utmost importance, whether it’s for a software as a service (SaaS) system or otherwise. But because creating objects (called Generic Objects), screens and rules in the MDF is significantly easier and less complex than creating objects, infotypes and screens in SAP, an even greater amount of governance is required.

Because of this reduced complexity, often customers may create Generic Objects themselves rather than procure a system integrator to perform this work. It is therefore important that customers — and equally important that systems integrators — think carefully about the following:

• Naming conventions
• Business case and usage
• Design and architecture
• Documentation

Usage and design

Although Generic Objects are not specific to SuccessFactors, it is worth being reminded how important usage and design are to determining the business case for them and how important it is to have clear requirements defined. For example:

• Does the object need to be effective dated?
• Does it need rules?
• What data types are needed for each field?
• How will it be associated with other objects?
• What will the layout of the user interface be?

Defining requirements with a consultant who is familiar with the MDF will enable the design to be architected efficiently. For example, in some instances, multiple effective-dated Generic Objects may be required to realize a particular requirement. In addition, changing a Generic Object to and from being effective-dated can create complications with the object and its fields.

Documentation

Naturally, documentation of all system configurations is a necessity. For Generic Objects, it is important to ensure that an object’s design and dependencies are well-documented, particularly when it’s being transported and tested in the production system. The following items should be well-documented:

• Purpose of the Generic Object
• Changes to standard fields, such as data type or source of valid values (e.g., a Picklist or Foundation Object)
• Custom fields added, along with details of the new field (e.g., data type, valid values source, rules, etc.)
• MDF Picklist objects that have been created
• Associations between the Generic Object and other objects
• Rules that have been created and their assignment (e.g., on initialization [onInit] or on saving of a portlet or object)
• Permission settings
• UI configuration created and details (e.g., object name, fields to be displayed, layout, etc.)

Education

Whether before a Generic Object is created or as an ongoing process, continuous education is a necessity. The MDF is being enhanced with every quarterly release, and although this will not have a detrimental effect on existing objects, new features and functionality may help to enhance an existing Generic Object or process, making the object more efficient or further automating the process.

Customers should be educated in the MDF during any Employee Central implementation by their systems integrator, but SAP also provide some excellent documentation on the MDF and Rules Engine — as well as on Advances, Alternative Cost Distribution, Deductions, Global Benefits, Income Tax Declarations (for India), Position Management and Time Off (all of which are MDF-based) — on the SAP Service Marketplace.

Rules

The Rules Engine is a powerful part of the MDF and can provide customers with numerous ways in which to apply their own business logic to the system. Having an understanding of the various mathematical and date operators available for rules can be very useful when setting up alerts, notifications, numerical calculations, and Time Off rules. The different model-based objects can be leveraged effectively to change field attributes, such as the visibility of a field or whether a field is required.

It is also important to understand the trigger points for rules, as this can affect how the rule is triggered and how the rules operate. For example, when a rule is used to generate an external code for a Generic Object automatically when the external code field attribute Required is set to “Yes,” using an onChange event at the field level or onSave event at the object level will not allow processing to continue when the object data is saved. Often, a rule needs to be created for the Generic Object to trigger at the onInit event to populate the external code with a value (e.g., “Automatic”), then have the rule that generates the external code to use an If condition based on the predefined value of the external code field.