Configuring Succession Org Chart, Nomination Permissions, and Rating Sources

Explanation

Once the foundational design (position-based versus incumbent-based) is agreed, the intermediate-level work centers on configuring the succession org chart, controlling who can see and edit succession data, and wiring up the rating sources that feed talent matrices. This lesson focuses on the practical configuration layer that a consultant typically owns during implementation. The Succession Org Chart is generally configured through the Succession Data Model (an XML-based configuration, distinct from the Corporate Data Model and the Employee Central Business Configuration), which defines the succession-specific fields available for nominations, talent pools, and the matrix, such as risk of loss, impact of loss, and readiness. Consultants typically work with this data model through Provisioning or admin tools depending on the instance setup, and changes usually require careful testing in a non-production instance before promotion, since the succession data model interacts with Role-Based Permissions (RBP) and the Metadata Framework for extended objects like talent pools. Role-Based Permissions are central to succession configuration because succession data is highly sensitive: employees generally should not see whether they are nominated as a successor for another role, and managers should only see succession information for their own organization, not company-wide. RBP permission groups and roles must be carefully scoped using target population definitions (often based on manager hierarchy or business unit) combined with specific succession permissions such as viewing the org chart, viewing/editing talent pools, and viewing/editing nominations. A common configuration pattern is to grant HR business partners broad read/write access within their client group, grant line managers limited access to their direct and indirect reports, and restrict executive-level succession data to a small senior HR and leadership audience. Ratings that populate the nine-box matrix and succession profile typically come from the Performance Management module's overall rating field, mapped through route map completion status and rating scale alignment; if the performance form's rating scale does not match what succession expects, ratings may not display correctly on the matrix, which is a frequent post-go-live defect. Calibration sessions, when used, allow HR and leadership to adjust and finalize ratings in a structured meeting before they are locked and pushed into the matrix, and calibration configuration must be checked to ensure the correct forms and populations are in scope for a given cycle. Another key configuration area is the talent search and nomination workflow: when a manager nominates a successor from a talent pool or search, the system checks permission scope to ensure the nominator has visibility to both the target role and the candidate profile. Consultants must test these scenarios with realistic test users representing different permission roles, not just an admin account, because admin accounts often bypass the very restrictions that need validation. Finally, because succession organizational data can change frequently (promotions, transfers, terminations), the org chart and nominations need periodic data integrity checks; orphaned nominations (where the target position or person no longer exists in the expected state) are a common production support issue that requires either manual cleanup or a scheduled data validation report.

Code example

<!-- Simplified conceptual snippet of a Succession Data Model element (illustrative structure, not a literal copy-paste config) --><succession-data-model>  <hris-field id="riskOfLoss">    <label>Risk of Loss</label>    <picklist-id>riskOfLossPicklist</picklist-id>    <permission>      <view roles="HRBP,LineManager"/>      <edit roles="HRBP"/>    </permission>  </hris-field>  <hris-field id="impactOfLoss">    <label>Impact of Loss</label>    <picklist-id>impactOfLossPicklist</picklist-id>    <permission>      <view roles="HRBP,LineManager"/>      <edit roles="HRBP"/>    </permission>  </hris-field></succession-data-model>

Real project scenario

During a Succession rollout for a retail company, the project team discovers post-UAT that regional store managers can see succession nominations for corporate executive positions because a target population rule in RBP was scoped too broadly by manager hierarchy without excluding executive-level position codes. The consultant reconfigures the permission role's target population to exclude the executive job classification and adds a dedicated executive succession permission role limited to a handful of senior HR users, then retests with role-specific test accounts before promoting to production.

Common mistakes

• Testing succession permissions only with an administrator account, missing restrictions that apply to real manager and HRBP roles. • Misaligning the Performance Management rating scale with what the succession matrix expects, causing blank or incorrect nine-box placements. • Scoping RBP target populations too broadly, exposing sensitive succession data (like risk of loss) to unauthorized managers. • Not planning for data integrity checks on nominations after organizational changes, leading to orphaned or stale succession records.

Best practices

• Always test succession permission changes with test users representing each real role, not just admin accounts. • Keep the succession rating scale explicitly aligned with the Performance Management overall rating scale to avoid matrix display issues. • Scope RBP target populations narrowly, especially for sensitive fields like risk of loss and impact of loss. • Schedule periodic data integrity validation for nominations and talent pools after major organizational changes such as reorganizations or terminations. • Promote succession data model changes through a tested non-production cycle before applying to production.

Interview angle

A common interview question is how you would prevent a manager from seeing succession data outside their own organization; a strong answer describes combining role-based permission groups with precisely scoped target populations and validating with role-specific test users rather than admin accounts.