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 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 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:
- Position
- Position Type
- Position Right to Return
- Position Requisition Mapping
- Position Job Requisition Processing Request
- Position Requisition Status
- Company Structure Definition
- 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 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 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 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 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:
- Review manager RBP roles: Identify managers who have multiple permission roles for the same employee data entity.
- Check permission categories: Determine which roles grant View Current and View History access.
- Validate responsibility period restrictions: Confirm that restrictions are configured on the intended permission categories.
- Test employee transfers: Use a test scenario where an employee moves from one manager’s team to another.
- Verify current-data access: Confirm that unrestricted View Current access behaves as intended.
- Verify historical-data access: Confirm that View History access is limited to the manager’s responsibility period where configured.
- 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:
- Hiring: Creating a new employee record.
- Rehiring: Rehiring employees with old or new employment through Duplicate Check.
- 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.
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:
- onChange business rule result: Takes the highest priority when a rule executes and changes the field value.
- onInit business rule result: Used when no applicable onChange result is present.
- 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.
- 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 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:
- Configure the latest People Profile.
- Complete or discard open drafts and pending workflows before enabling or reverting the experience. These items may not load after switching experiences.
- Review hire templates for compatibility with the latest experience.
- Verify that the Employee Cost Assignment MDF object is not included in hire templates.
- 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.
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.
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:
- Export the current Succession Data Model before making significant changes.
- Keep track of exported XML files and avoid using old local copies without checking their version.
- Use the latest exported SDM XML when preparing an import.
- Review the import result if the system blocks the upload because of version validation.
- 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.
