# SuccessFactors Employee Central H2 2026

- Link: https://www.lorenzo-datasolutions.com/successfactors-employee-central-h2-2026/
- Published: 2026-10-12T08:20:05+00:00
- Author: Anipe Abraham

The **SAP SuccessFactors Employee Central H2 2026 release** delivers a range of **
exciting innovations and enhancements** designed to help organizations **transform
HR operations**, **increase employee engagement**, and **drive better business outcomes**.

This release continues SuccessFactors Employee Central H2 2026 focus on automation,
data accuracy, and improved administrator and employee experiences. Don’t miss out
on the latest improvements introduced in **SuccessFactors Employee Central H2** **
2026**. Below are some of the **key updates and enhancements** you should consider
enabling or [adopting](https://www.lorenzo-datasolutions.com/best-successfactors-online-training/)
as part of your HR roadmap.

| **Release** | **Preview** | **Production** | 
| H2 2026 | October 12 | November 13 – 14 |

## **1.Updated MDF Object Permission Settings**

This update is important for SAP SuccessFactors Employee Central consultants, administrators,
and implementation teams responsible for configuring Role-Based Permissions (RBP).

Previously, the **Access to non-secured objects** permission allowed users to [access](https://www.lorenzo-datasolutions.com/online-training-for-sap-successfactors/)
certain unsecured MDF objects, subject to the applicable functionality and permissions.
With this update, the affected objects are delivered as secured by default, and 
their security settings cannot be changed.

Under the SuccessFactors Employee Central H2 2026, eight MDF objects associated 
with Position Management and company structure are delivered as secured by default.

The affected objects are:

 1. Position
 2. Position Type
 3. Position Right to Return
 4. Position Requisition Mapping
 5. Position Job Requisition Processing Request
 6. Position Requisition Status
 7. Company Structure Definition
 8. Company Structure UI Configuration

**Important:** The security setting for these objects cannot be changed. Consultants
should review the applicable permission categories and verify that users retain 
the access required for their business responsibilities.

## How Will Existing Customers Be Affected?

The impact depends on the existing security configuration of each object and [whether](https://www.lorenzo-datasolutions.com/lorenzo-data-solutions-reviews/)
the relevant permission role includes the Access to non-secured objects permission.

### **Scenario 1: The MDF Object Is Already Secured**

If the customer has already secured the affected object, there is no change to the
existing security configuration as a result of this update.

### **Scenario 2: The MDF Object Is Unsecured, but the Role Does Not Have Access to Non-Secured Objects**

According to the release notes, there is no change for existing customers in this
scenario.

### **Scenario 3: The MDF Object Is Unsecured, and the Role Has Access to Non-Secured Objects**

For existing customers whose permission roles have the Access to non-secured objects
permission, SAP grants permissions for the affected objects through the designated
permission category.

For the eight Position Management and company structure objects, the relevant category
is:

**User → Position Management Object Permissions**

Consultants should verify the resulting permissions and confirm that the role continues
to [support](https://www.lorenzo-datasolutions.com/sap-successfactors-certification-process/)
the required business processes.

## **Which RBP Permission Category Should Consultants Review?**

The release notes identify different permission categories for the affected objects.

| MDF object or group | Relevant permission category | 
| Position | User → Position Management Object Permissions | 
| Position Type | User → Position Management Object Permissions | 
| Position Right to Return | User → Position Management Object Permissions | 
| Position Requisition Mapping | User → Position Management Object Permissions | 
| Position Job Requisition Processing Request | User → Position Management Object Permissions | 
| Position Requisition Status | User → Position Management Object Permissions | 
| Company Structure Definition | User → Position Management Object Permissions | 
| Company Structure UI Configuration | User → Position Management Object Permissions |

The permission category should be reviewed when assessing whether existing roles
provide the required access to these objects.

Administrators should also test the actual user experience after the update rather
than assuming that a role has the correct access based only on its previous configuration.
SuccessFactors Employee Central H2 2026.

### **Technical Details**

| Field | Details | 
| Reference Number | ECT-257018 | 
| Product | Employee Central, Platform | 
| Modules | Company Organization, Integration and Extension | 
| Features | Organizational Management, Role-Based Permissions (RBP) | 
| Action | Info Only | 
| Enablement | Automatically On | 
| Lifecycle | General Availability | 
| Change Type | Changed | 
| Release Classification | Minor | 
| Business Process | Hire to Retire | 
| Software Version | H2 2026 | 
| Valid as Of | November 13, 2026 |

## **2.Restricted Manager Access Supports Multiple Permission Roles**

This improvement is particularly relevant to SAP SuccessFactors Employee Central
consultants [who](https://www.youtube.com/LorenzoDataSolutions) configure manager
access to employee information, including Job Information, using different permission
roles.

Previously, permission evaluation was performed at the entity level. With this enhancement,
the system evaluates permissions at the individual permission category level. As
a result, responsibility period restrictions can apply to selected permission categories
while unrestricted permissions from another role continue to grant access where 
applicable.

### What Is Responsibility Period-Based Employee Data Access?

Responsibility period-based access controls the employee data a manager can access
based on the period during which the manager was responsible for an employee.

For example, a manager may have access to an employee while that employee belongs
to the manager’s team. When the employee transfers to another team, the manager’s
responsibility period ends.

Depending on the configured permissions, the manager’s access to employee [records](https://www.youtube.com/@AnipeAbraham)
can be restricted according to that responsibility period.

This capability helps organizations manage employee data access more precisely, 
particularly when historical information needs additional protection.

### **What Is New in SuccessFactors Employee Central H2 2026?**

The enhancement supports managers who have multiple Role-Based Permission roles,
including a combination of restricted and unrestricted permissions for the same 
employee data entity.

The system now evaluates each permission category independently rather than applying
responsibility period restrictions uniformly at the entity level.

For example:

 * **View Current:** A manager can retain unrestricted access to current employee
   data through one permission role.
 * **View History:** The manager’s access to historical employee records can be 
   restricted according to the responsibility period through another role.

The restriction applies only to the permission categories in which it is configured.
Unrestricted permissions continue to grant access where applicable.

### **Practical Example: Manager Access to Employee Job Information**

Consider Michael, a regional manager, who has two RBP roles in SAP SuccessFactors.

| RBP role | Permission category | Access configuration | 
| Manager – History | View History | Responsibility period restriction | 
| Manager – Current | View Current | Unrestricted |

Sarah is an employee who transferred from Michael’s team to another team on March
1, 2024. This transfer ended Michael’s responsibility period for Sarah.

Let’s examine how Michael’s access works after the transfer.

### 1. View Current: Unrestricted Access

Michael has the View Current permission through the Manager – Current role without
a responsibility period restriction.

As a result, Michael can view Sarah’s current Job Information even after she transfers
to another team, assuming no other permission or access control prevents it.

### 2. View History: Access Within the Responsibility Period

Michael has View History permission through the Manager – History role, with a responsibility
period restriction.

He can view Sarah’s historical Job Information records from the period when he was
responsible for her.

For this example, that means historical records from before March 1, 2024, within
his responsibility period.

### 3. View History: Access Outside the Responsibility Period

Historical records created after March 1, 2024, fall outside Michael’s responsibility
period.

Under the described configuration, Michael cannot view those historical records 
through his restricted View History permission.

This distinction allows Michael to retain the intended current-data visibility while
limiting access to historical information according to his former managerial responsibility.

## Summary of Michael’s Access to Sarah’s Job Information

| Permission | Record period | Michael’s access | 
| View Current | Current employee data | Allowed through the unrestricted permission, subject to other access controls | 
| View History | Before March 1, 2024, within his responsibility period | Allowed through the restricted permission | 
| View History | After March 1, 2024, outside his responsibility period | Restricted by the responsibility period configuration |

**Key takeaway:** An unrestricted View Current permission does not automatically
remove the responsibility period restriction configured for View History.

### **What’s Changed in Permission Evaluation?**

### Previous behavior

Previously, permission evaluation occurred at the entity level. Access could be 
applied uniformly across the employee data entity, making it difficult to support
the intended combination of restricted and unrestricted permissions across multiple
manager roles.

### Updated behavior

With the enhancement, permission evaluation occurs at the permission category level.

This means the system can evaluate View Current and View History separately, applying
the responsibility period restriction only to the relevant category while preserving
applicable unrestricted permissions from another role.

The result is more flexible permission handling for managers assigned multiple RBP
roles.

## **What Should SAP SuccessFactors Consultants Validate?**

Consultants responsible for Employee Central security should review the following
items when assessing this enhancement:

 1. **Review manager RBP roles:** Identify managers who have multiple permission roles
    for the same employee data entity.
 2. **Check permission categories:** Determine which roles grant View Current and View
    History access.
 3. **Validate responsibility period restrictions:** Confirm that restrictions are 
    configured on the intended permission categories.
 4. **Test employee transfers:** Use a test scenario where an employee moves from one
    manager’s team to another.
 5. **Verify current-data access:** Confirm that unrestricted View Current access behaves
    as intended.
 6. **Verify historical-data access:** Confirm that View History access is limited 
    to the manager’s responsibility period where configured.
 7. **Review other access controls:** Ensure that the final access result is consistent
    with the customer’s complete security configuration.

Testing should be performed using representative test users and employees, with 
access results verified in the customer’s environment.

## **Why Is This Enhancement Important?**

This improvement gives organizations more precise control over manager access to
employee information.

It is particularly useful for organizations where managers have different responsibilities
across current and historical employee data, or where multiple permission roles 
are assigned to support different business requirements.

For SAP SuccessFactors consultants, understanding the difference between entity-
level and permission-category-level evaluation is important when designing, troubleshooting,
and validating Role-Based Permissions.

The enhancement also reinforces the importance of testing permission combinations
rather than reviewing each role in isolation.

## Technical Details

| Field | Details | 
| Reference Number | ECT-269782 | 
| Product | Employee Central | 
| Module | Employee Data | 
| Feature | Role-Based Permissions (RBP) | 
| Action | Info Only | 
| Enablement | Automatically On | 
| Lifecycle | General Availability | 
| Change Type | Changed | 
| Release Classification | Major | 
| Business Process Variant | Hire to Retire |

## 3.**Latest Hiring Experience**

SuccessFactors Employee Central H2 2026 introduces a redesigned **Latest Hiring 
Experience** for HR administrators who hire and rehire employees. Built around the
latest People Profile, this experience simplifies data entry, improves validation,
and provides a clearer view of progress throughout the hiring process.

The redesigned Add New Employee page organizes employee information into four sequential
steps. It also improves Duplicate Check results, makes warnings and errors easier
to identify, and supports the collection of country- or region-specific dependent
information during hiring and rehiring.

For SAP SuccessFactors Employee Central consultants, this enhancement requires an
understanding of the new page structure, hire template configuration, business rule
execution, and Role-Based Permissions (RBP).

### **What Is the SuccessFactors Employee Central H2 2026 Latest Hiring Experience?**

The Latest Hiring Experience is a redesigned interface for hiring and rehiring employees
through Add New Employee.

Unlike the legacy experience, which uses separate pages with vertically stacked 
forms, the latest experience presents four sequential steps across the top of the
page. Each step collects a specific set of information, and the next step becomes
available when the current step is completed successfully.

The redesigned experience aims to:

 * Simplify employee data entry.
 * Reduce unnecessary navigation between pages.
 * Improve Duplicate Check results and usability.
 * Make validation errors and warnings easier to understand.
 * Support country- or region-specific dependents during hiring and rehiring.
 * Provide clearer visibility into progress throughout the process.

### **Which Hiring Processes Are Supported?**

The Latest Hiring Experience applies to the following processes available through
Add New Employee:

 1. **Hiring:** Creating a new employee record.
 2. **Rehiring:** Rehiring employees with old or new employment through Duplicate Check.
 3. **Recruiting and Onboarding:** Processing candidates through Manage Pending Hires,
    excluding internal hires.

When the experience is enabled, the Drafts, Recruiting, and Onboarding tabs in Manage
Pending Hires open Add New Employee in the latest experience.

Consultants should confirm that the customer’s hiring processes fall within the 
supported scope before enabling the feature.

### **Understanding the Four Steps of the Latest Hiring Experience**

The latest experience organizes the hiring process into four steps: General Information,
Personal Data, Job Data, and Compensation.

### 1. General Information

General Information is the entry point for the process. Its purpose is to collect
the minimum information required to run Duplicate Check.

The step contains the following sections:

 * Basic Data
 * Identity, including First Name, Last Name, and Date of Birth
 * User Information
 * National ID Information

The Identity and National ID Information sections define the fields evaluated by
Duplicate Check.

This structure allows the system to perform the duplicate evaluation without requiring
the administrator to complete all identity and personal information first.

### 2. Personal Data

The Personal Data step combines information previously collected across the legacy
Identity and Personal Information pages.

Its sections include:

**Personal Data**

 * Personal Information, including Name Information and Additional Information
 * Global Information
 * Biographical Information
 * Person Global Info
 * National ID Information
 * Addresses

**Contact Information**

 * Phone Information
 * Email Information
 * Social Accounts Information
 * Primary Emergency Contact
 * Dependents

The redesigned structure consolidates personal and contact information into a more
organized experience. It also introduces Person Global Info and Social Accounts 
Information sections.

Support for country- or region-specific dependents enables relevant dependent information
to be collected as part of the hiring and rehiring processes.

### 3. Job Data

The Job Data step collects employment and organizational information needed to establish
the employee’s job record.

It contains:

 * Employment Details
 * Position Information, formerly Target Position
 * Organizational Information
 * Job Information
 * Time Information
 * Job Relationships
 * Work Permit Information

Consultants should review the customer’s hire template and confirm that the relevant
sections and fields are configured correctly.

### 4. Compensation

The Compensation step captures employee compensation and payment-related information.

Its sections include:

 * Compensation Information
 * Compensation, formerly the Recurring block
 * Pay Targets
 * One Time Payment
 * Details, formerly the Payment Information block

The revised structure reorganizes the legacy compensation blocks into the new step-
based layout.

### **Latest Hiring Experience: Legacy vs. New Interface**

| Area | Legacy experience | Latest experience | 
| Page structure | Separate pages with stacked forms | Four sequential steps | 
| Initial data entry | Identity page collects extensive information | General Information collects minimum Duplicate Check data | 
| Personal information | Distributed across separate pages | Consolidated into Personal Data | 
| Job information | Job Information page | Job Data step | 
| Compensation | Compensation Information page | Compensation step | 
| Navigation | Buttons positioned at the top or bottom of pages | Floating footer actions available throughout the process | 
| Validation | Page-based validation | Step-level validation plus final submission validation |

### **New Navigation and Action Buttons**

The latest experience introduces a floating footer that keeps important actions 
accessible throughout the process.

| Action | Purpose | 
| Continue | Validates the current step and advances to the next step when successful | 
| Previous | Returns to a preceding step to review or change information | 
| Save Draft | Saves progress so the process can be continued later | 
| Cancel | Stops the process without saving changes | 
| Submit | Finalizes the employee data and sends it for approval when workflows are enabled |

The Submit action becomes available after all steps have been unlocked. Once available,
it can be selected from any step.

This design reduces navigation compared with the legacy experience, where action
buttons may be positioned at the top or bottom of individual pages.

### **How Does Validation Work?**

Validation is an important part of the Latest Hiring Experience.

### Step-level validation

When the administrator selects Continue, the system validates the current step.

Errors must be resolved before the next step becomes available. This helps administrators
identify problems earlier rather than discovering them only at the end of the process.

Auto-generated fields, such as a formal name derived from a name format, are not
validated when advancing between steps. These fields are validated when Submit is
selected.

### Final submission validation

When the administrator selects Submit, the system runs the remaining validations
across all steps.

 * **Errors:** Block the hiring process until they are resolved.
 * **Warnings:** Are displayed but do not block submission.

The system identifies the steps containing errors. Selecting an error navigates 
the administrator to the relevant field for correction.

### **Business Rule Behavior in the Latest Hiring Experience**

Consultants must review business rule configurations because the redesigned page
structure affects when some rules execute.

### onInit rules

onInit rules execute when a step is loaded and when a section is expanded.

### onChange rules within the same entity

onChange rules operating within the same entity execute immediately when a field
[changes](https://www.lorenzo-datasolutions.com/sap-successfactors-onboarding-2-0/).

### Same-page cross-entity onChange rules

Same-page cross-entity onChange rules execute only when configured for the applicable
cross-entity rule scenario.

Basic onChange rules are not executed simply because the administrator selects Continue.

In the Job Data step, rules can execute immediately when the job is changed, even
though Job Relationships appears in a separate section of that step.

### Cross-page onChange rules

Cross-page onChange rules are not supported in the described hiring and rehiring
process.

For example, if a business rule must execute from Job Data to Compensation, the 
relevant sections must be configured on the same page or step using a custom template.

### onSave rules

onSave rules execute when Submit is selected and the hiring process is completed.

### Job Information event reason

Business rules that attempt to change the Job Information event reason field are
not executed in this process. The field resets to its original value.

**Consultant recommendation:** Review existing rules before enabling the Latest 
Hiring Experience. Test rule execution at the field-change, section-expansion, step-
navigation, and submission stages.

### MDF Object Configuration in Hire Templates

The Latest Hiring Experience introduces a specific requirement for MDF objects used
in hire templates.

MDF objects in a hire template require the **MDF Object Type** field on the relevant
hire template block.

In the legacy hiring experience, MDF Block Type is used to reference a Configurable
UI instead.

The MDF Object Type field stores the external code of the MDF object. The system
renders the object through its card configured in the latest People Profile.

Consultants should review custom hire templates and confirm that MDF objects are
configured according to the requirements of the latest experience.

### Important limitation: Employee Cost Assignment

The Latest Hiring Experience does not support the Employee Cost Assignment MDF object
in hire templates.

If a customer’s hire templates include this object, do not enable the Latest Hiring
Experience until the configuration and supported business requirements have been
addressed.

### How Are Recruiting and Onboarding Field Values Resolved?

When a candidate comes from Recruiting or Onboarding, the system uses a defined 
priority order to determine the field value.

The order is:

 1. **onChange business rule result:** Takes the highest priority when a rule executes
    and changes the field value.
 2. **onInit business rule result:** Used when no applicable onChange result is present.
 3. **Recruiting or Onboarding value:** Used when no rule result is present and the
    incoming value is valid. If the value is invalid, the system falls back to the 
    database value.
 4. **Database value:** Previous employment data can be used for rehire cases when 
    no rule result and no valid Recruiting or Onboarding value are available.

When a higher-priority source overrides a field, the original Recruiting or Onboarding
value may [appear](https://www.lorenzo-datasolutions.com/picklist-migration-to-mdf/)
below the field as a secondary reference.

Database values are not displayed as secondary references.

This priority order is particularly important when troubleshooting differences between
candidate data, business rule results, and existing employee records.

## Configuration Requirements for the Latest Hiring Experience

Before enabling the feature, administrators and consultants should verify the following
requirements:

 1. Configure the latest People Profile.
 2. Complete or discard open drafts and pending workflows before enabling or reverting
    the experience. These items may not load after switching experiences.
 3. Review hire templates for compatibility with the latest experience.
 4. Verify that the Employee Cost Assignment MDF object is not included in hire templates.
 5. Enable the **Latest Hiring Experience** setting in Admin Center → Manage Employee
    Central Settings.

### Role-Based Permission Prerequisites

Administrators must have the required permissions under:

**Administrator Permissions → Manage Hires**

This permission area contains permissions for hiring, rehiring, managing pending
hires, and configuring hire templates.

Before testing the feature, consultants should confirm that the relevant administrator
roles have the permissions required for their responsibilities.

### Consultant Readiness Checklist

Before enabling the Latest Hiring Experience in a customer environment, review the
following:

 * Confirm that the hiring and rehiring processes are supported.
 * Configure and validate the latest People Profile.
 * Review all relevant hire templates.
 * Check MDF Object Type configuration for MDF objects in hire templates.
 * Confirm that Employee Cost Assignment is not used in the hire templates.
 * Review business rules for onInit, onChange, and onSave execution.
 * Test cross-entity and cross-step rule scenarios.
 * Verify Recruiting and Onboarding field value resolution.
 * Test Duplicate Check and validation behavior.
 * Confirm Manage Hires permissions.
 * Complete or discard open drafts and pending workflows before switching experiences.
 * Test the complete hiring process, including Save Draft, Cancel, and Submit.

### How It Looks Now

The page opens at step 1 of 4, with the 4 steps displayed in a numbered progress
bar. All sections for the step are visible on a single scrollable page. Actions 
buttons are accessible from a floating fixed footer.

![The Add New Employee page in the latest hiring experience, with a four-step horizontal
progress bar at the top and the General Information step active. The floating page
footer contains Continue, Save as a Draft, and Cancel actions.](data:image/gif,GIF89a%
01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9%04%01%00%00%00%00%2C%00%00%00%00%01%
00%01%00%00%02%01D%00%3B "The Add New Employee page in the latest hiring experience,
with a four-step horizontal progress bar at the top and the General Information 
step active. The floating page footer contains Continue, Save as a Draft, and Cancel
actions.")

### How It Looked Before

The **Identity** page is a standalone form. The pages that follow appear as collapsed
sections stacked below the active form. The footer is below the last form.

![The Identity section in the legacy hiring experience, rendered as a standalone
full-page. Subsequent pages appear as collapsed accordion sections at the bottom.
The page footer contains Submit, Save Draft, and Cancel actions.](data:image/gif,
GIF89a%01%00%01%00%80%00%00%00%00%00%FF%FF%FF%21%F9%04%01%00%00%00%00%2C%00%00%00%
00%01%00%01%00%00%02%01D%00%3B "The Identity section in the legacy hiring experience,
rendered as a standalone full-page. Subsequent pages appear as collapsed accordion
sections at the bottom. The page footer contains Submit, Save Draft, and Cancel 
actions.")

### Conclusion

The SAP SuccessFactors Latest Hiring Experience redesigns the Add New Employee process
to provide a clearer, more structured way to hire and rehire employees.

Its four-step layout, improved Duplicate Check, step-level validation, updated business
rule behavior, and revised MDF object configuration requirements make it important
for Employee Central consultants to review existing configurations before enabling
the feature.

Successful implementation requires more than switching on a setting. Consultants
should validate hire templates, People Profile configuration, business rules, Recruiting
and Onboarding integrations, and Role-Based Permissions.

### Technical Details

| Field | Details | 
| Reference Number | ECT-248247 | 
| Document ID | HCM-419B-51D7 | 
| Product | Employee Central, Onboarding, Recruiting | 
| Module | Employee Data | 
| Feature | Hire, Rehire, and Termination | 
| Action | Info Only | 
| Enablement | Customer Configured | 
| Lifecycle | General Availability | 
| Change Type | New | 
| Release Classification | Major |

## 4,Hire Templates Support for MDF Objects

SuccessFactors Employee Central H2 2026 introduces enhanced support for Metadata
Framework (MDF) objects in hire templates as part of the Latest Hiring Experience.
This enhancement allows HR administrators to include supported MDF objects in hire
templates using the new **MDF Object Type** field in the Hire Block Configuration
object definition.

**Previously**, the legacy hiring experience used the MDF Block Type field to reference
a Configurable UI. With the Latest Hiring Experience, the system uses MDF Object
Type to identify the MDF object that provides data during hiring.

This change simplifies configuration and aligns the display of MDF data during hiring
with the corresponding object card in the latest People Profile.

### **What Is Hire Templates Support for MDF Objects?**

Hire templates define the information collected when creating employee records in
SAP SuccessFactors Employee Central.

With the Latest Hiring Experience, administrators can include supported MDF objects
in hire templates through the **MDF Object Type** field.

This field identifies which MDF object supplies the data displayed during the hiring
process.

Unlike the legacy approach, the Latest Hiring Experience does not require administrators
to create a separate Configurable UI in Manage Configuration UI for this purpose.
Instead, the system uses the display configuration associated with the MDF object’s
card in the latest People Profile.

This provides a more consistent experience when entering information during hiring
and viewing the same information later in the People Profile.

### **What Is New in SAP SuccessFactors H2 2026?**

The main enhancement is the introduction of the MDF Object Type field in Hire Block
Configuration.

Administrators can access this field through:

**Admin Center → Manage Data → Hire Template → Details → Block Data Configurations**

The field is available alongside the existing MDF Block Type field.

The system uses MDF Object Type to identify the object used in the Latest Hiring
Experience, while MDF Block Type remains relevant to the legacy hiring experience.

### **Which MDF Objects Are Supported?**

When configuring the MDF Object Type field, the system automatically lists the supported
object types described in the release notes.

These include:

### 1. Custom MDF Objects

Custom MDF objects are listed when they are user-based entities. This applies when
either:

 * The external code type is USER.
 * The Subject User Field is configured as a field of type USER.

Consultants should verify that their custom MDF objects satisfy these requirements
before using them in hire templates.

### **What Happens to Existing Hire Templates?**

For existing MDF objects, SAP automatically runs an update from MDF Block Type to
MDF Object Type.

Consultants should nevertheless review every affected block to confirm that MDF 
Object Type has been populated correctly.

Two situations require particular attention.

### Scenario 1: Warning About a Different Configurable UI

A warning may appear when the Configurable UI used by the legacy block differs from
the default Configurable UI associated with the base MDF object.

The Latest Hiring Experience uses the object’s default display configuration.

**Consultant action:** Review the rendered result and confirm that the fields displayed
during hiring meet the customer’s requirements.

### Scenario 2: Error for an Unsupported MDF Object

An error may appear when the legacy block references an MDF object that is not supported
by the Latest Hiring Experience.

**Consultant action:** Remove the unsupported block and save the hire template.

Do not assume that every MDF object previously used in the legacy experience will
work in the latest experience.

### Compatibility With the Legacy Experience

Both MDF Block Type and MDF Object Type values are saved.

This allows the hire template to continue supporting the relevant legacy and latest
hiring experiences, subject to the compatibility of the configured objects.

### **Role-Based Permission Prerequisites**

Before configuring MDF objects in hire templates, administrators must have the appropriate
permissions.

### 1. Manage Hires Permissions

The administrator requires:

**Administrator Permissions → Manage Hires → Hire Configuration Template**

The permission must cover all templates or the selected configuration templates 
used for hiring, as appropriate.

### 2. Standard MDF Permissions

Administrators need standard MDF permissions and edit permissions for all custom
MDF objects used in the hire template.

Without these permissions, the administrator may be unable to configure or maintain
the required object data.

### 3. Hire Template MDF Permissions

Administrators also require all permissions for the Hire Template MDF object under:

**User Permissions → Miscellaneous Permissions → Hire Template**

Consultants should verify all three permission areas before troubleshooting configuration
access issues.

### **Business Benefits of the Enhancement**

The MDF Object Type approach provides several practical benefits.

 * **Simplified configuration:** A separate Configurable UI is no longer required
   for this purpose in the Latest Hiring Experience.
 * **Consistent user experience:** The object uses the same display configuration
   as its card in the latest People Profile.
 * **Improved template management:** Administrators can identify the MDF object 
   associated with a hire template block more directly.
 * **Migration support:** Existing MDF Block Type configurations are updated automatically,
   although validation is still necessary.
 * **Clearer compatibility checks:** Warnings and errors help identify differences
   in display configuration and unsupported objects.

These improvements can help consultants simplify supported hire template configurations
while maintaining a consistent employee data experience.

### **Consultant Readiness Checklist**

Before implementing this enhancement, SAP SuccessFactors consultants should:

 * Review the latest People Profile configuration.
 * Identify existing hire templates that use MDF Block Type.
 * Verify that MDF Object Type is populated correctly after the automatic update.
 * Review warnings related to differences in Configurable UI settings.
 * Remove unsupported MDF blocks that generate errors.
 * Confirm that custom MDF objects meet the user-based entity requirements.
 * Validate Payment Information and Cost Assignment for person-type templates.
 * Validate Work Order for contingent-worker-person-type templates.
 * Verify Manage Hires and Hire Template permissions.
 * Confirm edit permissions for the custom MDF objects used.
 * Test the rendered object in the Latest Hiring Experience.
 * Verify that the template behaves as expected when switching between the latest
   and legacy experiences.

## Conclusion

The SuccessFactors Employee Central H2 2026 enhancement for hire templates introduces
MDF Object Type to support MDF objects in the Latest Hiring Experience.

This approach replaces the legacy dependency on MDF Block Type for identifying objects
in the latest experience and aligns the display of MDF data with the object’s configuration
in the latest People Profile.

Although existing configurations are updated automatically, consultants should review
migrated blocks, resolve warnings and errors, confirm permissions, and test the 
complete hiring process.

### **Technical Details**

| Field | Details | 
| Reference Number | ECT-248612 | 
| Product | Employee Central | 
| Modules | Employee Data | 
| Features | Hire, Rehire, and Termination; Metadata Framework | 
| Action | Recommended | 
| Enablement | Automatically On | 
| Lifecycle | General Availability | 
| Change Type | New | 
| Release Classification | Minor | 
| Business Process Variant | Hire to Retire | 
| Software Version | 2H 2026 |

## **5.Enhanced Succession Data Model Import Validation**

SuccessFactors Employee Central H2 2026 introduces enhanced version validation for
the Succession Data Model (SDM) import process. This improvement helps administrators
prevent outdated XML files from overwriting recent data model configuration changes.

Previously, the system did not verify whether an uploaded Succession Data Model 
XML file represented the latest active version. Because an SDM import performs a
full replacement of the existing data model, importing an older file could unintentionally
remove configuration changes made after that file was exported.

With this enhancement, exported SDM XML files include version information, and the
system checks that information during import.

## What Is Enhanced Succession Data Model Import Validation?

The enhancement introduces version-based validation for Succession Data Model XML
files. When an administrator imports an SDM XML file, the system checks whether 
the file contains valid version information and whether its version matches the 
latest active Succession Data Model version.

If the uploaded file is missing a version tag, contains an invalid version tag, 
or is based on an outdated data model, the import is blocked.

This helps administrators avoid accidentally replacing current configuration with
an older version.

## Key Features of the Enhancement

### 1. Automatic Version Information in Exported XML

Exported Succession Data Model XML files now include a version tag. This information
allows the system to identify the version of the data model represented by the file.

### 2. Version Validation During Import

When an SDM XML file is uploaded, the system validates its version information against
the latest active Succession Data Model version.

### 3. Prevention of Outdated Imports

The system blocks imports when the XML file:

 * Does not contain a version tag.
 * Contains an invalid version tag.
 * Represents an outdated version of the data model.
 * Does not match the latest active SDM version.

### 4. Protection of Recent Configuration Changes

Because an SDM import replaces the existing data model, importing an outdated file
can put recent configuration changes at risk. Version validation helps prevent this
situation and reduces the need to recover or reapply changes.

### 5. Scope of the Enhancement

This enhancement currently applies only to the Succession Data Model (SDM). Do not
assume that the same version-validation behavior applies to other data models.

## How It Works Now vs. Before

| Area | Previous behavior | Enhanced behavior | 
| Exported SDM XML | No version validation information was used during import | Exported XML includes version information | 
| Import validation | The system did not verify whether the uploaded XML was current | The system validates the version tag | 
| Outdated XML files | Could potentially replace newer configuration | Import is blocked if the version is outdated | 
| Missing or invalid version information | No version-based validation was performed | Import is blocked | 
| Configuration protection | Recent changes could be overwritten without warning | Version validation helps protect current configuration |

## Practical Impact for SAP SuccessFactors Consultants

This change is relevant to consultants and administrators who maintain Employee 
Central data model configuration.

**Before importing an SDM XML file, consider the following practices:**

 1. Export the current Succession Data Model before making significant changes.
 2. Keep track of exported XML files and avoid using old local copies without checking
    their version.
 3. Use the latest exported SDM XML when preparing an import.
 4. Review the import result if the system blocks the upload because of version validation.
 5. Re-export the latest data model and apply any required changes to the current version
    rather than attempting to import an outdated file.

These practices complement the new validation and help reduce configuration-related
rework.

## Benefits of the Enhancement

 * **Improved configuration protection:** Reduces the risk of overwriting recent
   SDM changes with outdated XML.
 * **Better import reliability:** Validates version information before allowing 
   an import.
 * **Reduced rework:** Helps prevent administrators from having to restore or reapply
   recent configuration changes.
 * **Greater configuration control:** Encourages the use of the latest active data
   model when importing XML files.

### Conclusion

The Enhanced Succession Data Model Import Validation feature in SuccessFactors Employee
Central H2 2026 introduces an important safeguard for data model administration.
By adding version information to exported SDM XML files and validating it during
import, the system helps prevent outdated or invalid files from replacing the latest
active configuration.

SAP SuccessFactors consultants should review their existing data model export and
import practices and ensure that they work with current SDM XML files.

### Technical Details

| Field | Details | 
| Reference Number | ECT-265617 | 
| Product | Employee Central | 
| Module | Employee Data | 
| Feature | Data Models | 
| Action | Info only | 
| Enablement | Automatically on | 
| Lifecycle | General Availability (GA) | 
| Type | Changed | 
| Impact | Minor | 
| Business Process Variant | Hire to Retire | 
| Release | 2H 2026 |

_**I** create these blogs to help SAP SuccessFactors consultants, students, and 
professionals expand their knowledge and stay current with the latest releases and
best practices. Through each article, I share practical insights, real-world experience,
and valuable learning resources to support your SAP SuccessFactors journey._

_Thank you for visiting my website. I hope these resources help you learn, grow,
and succeed in your SAP SuccessFactors career._

**— **[Anipe Abraham](https://www.linkedin.com/in/anipeabraham/)