Maintaining MDF Position Data

An important aspect of the Position-based models is that you must keep the Position data updated, so that the Succession Org Chart displays current information, and you can effectively create succession plans for your company.

Administrators have two options for creating and maintaining the position model:

• Generating it from employee data, which is done via the Sync Position Model with Employee Data feature.
• Importing it from an external source, which is done via the Import Positions feature.

Combining imports with sync operations can result in duplicating position data and/or overwriting good data with bad data. Note that you must populate the position model with one of these two methods before using the Succession Org Chart; otherwise, you get an error. Also, note that if you don't update the position model regularly, you may see inactive incumbents, wrong reporting relationships, and not be able to find new employees in the Succession Org Chart.

If you do not maintain positions in your HRIS but you want to use position-based succession planning, you can use Position Sync to manage positions in Succession based on your HRIS employee data. You can use the Position Sync tool to create and update a position model reflecting your employee hierarchy.

To access the tool, go to Admin Center→Succession→Position management: Sync Position Model with Employee Data.

MDF position sync is an option that allows you to plan succession based on positions rather than on role-person, even if you don't maintain position information in your HRIS. The sync takes the information from the people import of your HRIS and replicates the reporting hierarchies as position hierarchies that you can use for succession planning.

The position sync has three basic triggers that are processed sequentially during every sync:

1. An employee leaves the company (is deactivated).
2. An employee joins the company (is activated).
3. An employee's manager changes.

All of these conditions may occur during a single organizational event, such as a reorganization. For details about how the Position Sync handles each of the three scenarios above, refer to the MDF Position Sync help documentation on help.sap.com.

None of the position updates made by the sync are new effective dated records but are instead updates to the existing records. In other words, a new record isn't inserted by the sync for updates, but rather the current record is updated.

To use the sync, users must have Sync Position Model permission, which is available under the Admin permission ,Manage Succession, in RBP. The permissioned user can then see Position management: Sync Position Model with Employee Data under Admin Center→Succession.

To ensure optimal sync results, consider the following recommendations:

• Employees should report either to an active manager or to a "placeholder" manager while importing employee files.
• If you have configured additional fields that aren't automatically updated by the sync, ensure that those fields aren't marked as required.
• If you store position titles in language locale en_US, don't disable en_US locale by use of defaultValue for translation in the MDF model.
  Note

  The system compares the position incumbent’s title (employee-based) and the position title (position-based) to determine whether the titles match based on the defined conditions.
• If you store position titles in languages other than en_US, select which languages to sync before running the sync to avoid results like empty position titles.
  Note

  If you select only one language, the other languages aren't affected.

• For customers who are succession planning for only a small number of positions, the MDF Position administration UI is recommended to manually manage positions instead of the sync.

Once the sync is performed, your Succession Org Chart should be populated with positions.

After importing employee data from the HRIS, the MDF Position model reflects the same hierarchy, by position.

If you manage your positions in an external HRIS system, you can feed your position data to Succession Planning through scheduled imports. To import MDF position data from Admin Center, we use the Import and Export Data tool. This is the same tool that is used for any other MDF objects.

This tool can be used for the initial load of position data and delta imports.

It is important to make the distinction between this tool and the Position Management: Import Positions admin tool, which is only relevant for legacy positions.

For details on the full set of features for the MDF import tool, refer to the Importing MDF Data documentation from help.sap.com.

Importing data to an MDF instance is a two-step process. Both operations use the same form that is launched:

1. Download the correct template for the object and enter the data that you want to import. The template contains the structure of the object because it’s set up in MDF object definitions.
   1. Select Download Template for the Action to perform in the Import and Export Data tool.
   2. Select Position for the Generic Object.
   3. Select No for Include Dependencies. This option is only required when the position object refers to other objects and those objects have to be imported as well.
   4. The template displays fields that have been set to either Edit or Read-only in the position object definition. Fields set to Invisible in the position object are not available in the template.
2. Upload the data for that object.
   1. Select Import Data for the Action to perform.
   2. Select Position for the Generic Object.
   3. Choose the file that you’re importing.
   4. Select Incremental Load for the Purge Type. This is the suggested method of import. When importing a position file with this option, only the positions that are included in the file are updated. Indeed, with the incremental load option, positions that are not in the file will not be updated or deleted.

If you're using MDF Positions, but do not have EC Position Management, it's common that the Position object will only contain basic information, such as position title, incumbent, and criticality. However, some organizations must configure their RBP based on information that is only available in the User entity (USERINFO_SYS), such as department, division, location, and others. This feature allows you to map this type of information from the User entity to custom fields in the Position object, so that you can configure the target population of your Permission Roles meeting your business requirements.

This is especially helpful for managing vacant positions because you can only grant permissions to add/view successors to vacant positions by granting Position object permissions. Having certain position attributes filled from fields in the incumbent user's employee profile helps you control access permissions for positions that become vacant. If an MDF position becomes vacant, that is if the 'incumbent' field is empty, the last incumbent user's data is retained at the MDF position. As a result, this vacant position remains accessible to logged-in users whose permissions allow them to see and edit positions maintained via the incumbent user's attributes.

For example, information like the department is only available on a position without an incumbent if you have previously updated the position with incumbent information. Then, after you remove the incumbent, that information remains at the position level.

The information updated at the position level via this mapping will then be represented in all module areas, like Succession Org Chart, Nomination and Succession Portlets, ad hoc reporting, and others.

You can update position attributes by using Admin Center→Succession→Succession Settings→Update Position Attributes (you can navigate directly to Succession Settings).

The user data updates the MDF position fields when any of the following conditions occur:

• Only during MDF Position Sync
• Whenever a position gets saved (including position import)

When updating position attributes:

• The fields available for matching represent the most commonly used fields from the user data file.
• The fields available for the MDF Position are all the standard (which are not reserved for system use) and custom fields of data type "String" from the Position object.
• If the type of a field is changed after the mapping has been made, the mapping will be discarded. If a mapped field is deleted, the mapping should be discarded as well.
• You can choose up to 10 fields in this mapping.
• The system will only update position attributes for a position with changes. If the position remains untouched after position attributes are configured, data from UDF will not be copied over. For new configurations, an admin needs to pre-populate from UDF to ensure that all fields are synced.

Consider the following example of how the mapping works:

• A user's Department has been mapped to MDF Position field "cust_business_unit" and the user's Division is mapped to MDF Position field "cust_organization".
• When a new position is created with user ‘employee1' as incumbent, then Employee 1's Department and Division are copied over to the two MDF Position custom fields when the record is saved and/or during MDF Position Sync.
• When the position is "updated" (both for effective and noneffective dated updates), the incumbent fields are copied over to the MDF Position fields again.
• If the incumbent field is empty, nothing is copied over to the MDF Position custom fields; old values will be retained in the MDF Position fields.

Generally, the recommendation when organizations have Employee Central (EC) to manage positions is to only use MDF position-based nominations. In this situation, the same position object is shared between EC and Succession. However, there are a few options to consider if only a group of employees exist in EC and everyone exists in the Talent area.

What is our recommendation for the succession nomination method when a customer uses Employee Central only for some employees? This question seems to come up frequently and there is currently no easy solution in the tool but there are two options that can be considered.