Configuring and Maintaining the Org Structure: Relationships, Effective Dating, and Position Management
Learn how to build and maintain an org structure using relationships and effective dating, decide on position management scope, and connect OM to Employee Central and downstream processes.
Explanation
Once the basic OM objects are understood, the practical work is configuring and maintaining the structure so it stays accurate over time as the business reorganizes, people move, and positions are created or closed. This lesson focuses on the mechanics of relationship maintenance, effective dating, and the decisions involved in scoping Position Management, primarily in a SuccessFactors Employee Central context with references to classic SAP HCM/S4 on-premise behavior where it differs. Relationships and effective dating: In classic SAP HCM (and S/4HANA on-premise OM), structure is built through relationship infotypes (commonly infotype 1001) connecting objects - for example an 'A/B 002' relationship type representing 'reports to' between two org units, or 'A/B 008' representing 'holder' between a position and a person. Every relationship carries a validity period. Reorganizations are handled by delimiting the old relationship record (setting an end date) and creating a new relationship record with a start date, rather than editing history. This preserves an auditable trail: you can query the org structure as it existed on any past date, which matters for historical reporting, retroactive payroll, and audit/compliance needs. In Employee Central, the equivalent is achieved through Foundation Objects (Department, Division, Business Unit, Location) each with their own effective-dated records, and through Job Information records on the employee's Employment record that reference the org structure, position (if position management is enabled), and reports-to manager. Effective dating is native to Employee Central's Job Information and Foundation Object entities, and changes are made as effective-dated events (e.g., 'Organizational Change' or 'Position Change') rather than open edits. Position Management scoping: A key configuration decision is whether to enable full Position Management in Employee Central. When enabled, positions become persistent objects with their own effective-dated records (incumbent count, position org unit, position-to-position reporting relationships, budget details), useful for organizations needing strict headcount control, succession planning against specific seats, or complex matrix reporting. When disabled or used minimally, Employee Central runs primarily job/department driven, where reporting lines are typically defined by 'reports to' fields on the Job Information record pointing directly to a manager's user ID, which is simpler to maintain but offers less structural rigor for vacancy tracking. Matrix and dotted-line relationships: Many organizations need to represent a secondary or dotted-line reporting relationship, for example a regional matrix manager in addition to the direct line manager. In Employee Central this is typically modeled via additional 'matrix manager' or custom relationship fields on Job Information, separate from the primary 'reports to' hierarchy, since the primary hierarchy generally must remain a clean, non-circular tree for org chart and workflow purposes. Integration and runtime impact: The org structure feeds numerous downstream processes: workflow routing (who approves what), Role-Based Permissions target population in Employee Central (permission groups often derive from department/org unit), org chart visualizations, and headcount/cost reporting. A structural change - such as moving a department under a new business unit - can silently break RBP target populations or approval chains if the effective date of the change does not align with expectations, so structural changes should be planned with a clear effective date and communicated to security/workflow owners. Troubleshooting: common symptoms of structural problems include employees missing from a manager's team view (often a stale or incorrectly effective-dated 'reports to' value), approval workflows stalling (approver position vacant or improperly delimited), and org chart gaps (org unit missing a valid 'reports to' relationship for the current date). Diagnosis typically starts by checking the object's relationships as of the specific date in question, since most issues are effective-dating mismatches rather than outright data loss.
Real project scenario
During a regional restructuring, an HR analyst needs to move an entire department from Business Unit A to Business Unit B effective the first of next month. The consultant creates the new Foundation Object relationship with the correct future effective date rather than editing the existing record, coordinates with the RBP administrator to confirm permission groups based on the old business unit will still resolve correctly during the transition window, and validates that manager 'reports to' chains and pending workflow approvals will not break across the effective-date boundary.
Common mistakes
• Editing existing relationship or Foundation Object records in place instead of creating a new effective-dated record, which destroys historical accuracy • Enabling full Position Management without first confirming the business actually needs headcount-seat-level control, adding ongoing maintenance burden • Modeling dotted-line/matrix reporting inside the primary hierarchy, creating near-circular structures that break org chart and workflow logic • Making structural changes effective immediately without checking pending workflows or RBP dependencies tied to the old structure • Assuming Employee Central behaves identically to on-premise OM relationship infotypes when in fact the underlying object model and configuration screens differ
Best practices
• Always create new effective-dated relationship or Foundation Object records for structural changes instead of overwriting existing ones • Validate whether Position Management is genuinely required before enabling it, based on headcount control and succession needs • Keep matrix/dotted-line reporting in dedicated fields separate from the primary reports-to hierarchy to preserve a clean org tree • Coordinate structural change effective dates with RBP and workflow owners to avoid silent permission or approval breaks • When troubleshooting missing team members or approvers, check relationships as of the specific date in question before assuming data loss
Interview angle
A frequent scenario question is how to handle a departmental reorganization without losing historical reporting accuracy. Strong candidates describe effective-dated relationship creation (delimit old, insert new) rather than in-place edits, and mention checking downstream impacts on RBP and workflow approvers before the change goes live, showing production-support awareness rather than just configuration knowledge.