E ERP Atlas
404
SOLUTION AND CONFIGURATION WORKBENCHDesign the employee-data control model and prove it

H2R 404 ยท SOLUTION AND CONFIGURATION WORKBENCH

How do you design and configure H2R safely?

Use this practitioner configuration companion to decide what needs to be configured, in what dependency order, which layer is configuration versus governed data, how each step is proven, and how EC, payroll, target systems, and Finance remain reconciled.

IMPLEMENTATION CONTEXT

H2R Implementation Context

Stay at the keyboard: configure the smallest complete Employee Central change chain, test it, and reconcile downstream systems before adding optional modules or country variants.

  1. Business Requirement
  2. Fit-to-Standard
  3. Confirm Gaps
  4. Configure
  5. Test
  6. Reconcile

THE EMPLOYEE-CHANGE SPINE

Make the causal chain visible

A promotion, transfer, pay change, or termination is trustworthy only when the system can explain why that event reason, rule, workflow, approver, and approved record resulted.

  1. 01
    Employee ChangeInput
  2. 02
    Business RulesLogic
  3. 03
    Event Reason DerivationClassification
  4. 04
    ValidationGate
  5. 05
    Workflow DerivationApproval path
  6. 06
    ApprovalDecision
  7. 07
    Effective-Dated RecordTruth

Core sequence: Employee Change -> Effective Date -> Event / Reason -> Business Rule -> Workflow -> Approved Record.

H2R MENTAL MODEL

One Employee Change, One Effective-Dated Truth

WHO?

Person and assignment identity.

WHEN?

Effective date.

WHAT?

Event and event reason.

HOW?

Business rule.

WHO APPROVES?

Workflow.

WHAT IS TRUE?

Approved effective-dated record.

WHERE NEXT?

Required downstream system.

SuccessFactors / Employee Central locators

Use object ownership first and UI locator second. Maintain foundation structures through Manage Organization, Pay and Job Structures or Manage Data where the object is owned there. Use Configure Object Definitions and Manage Business Configuration to inspect object and Employee Central data-model behavior.

Use Manage Business Rules, Manage Workflows, and Manage Permission Roles and Groups for rules, approval definitions, and RBP. Use Position Management tools only where Position Management is part of the approved design.

Configuration vs governed data

ConfigurationFoundation Object definitions, MDF object definitions, Business Rules, Workflow configuration, Event/Event Reason configuration, RBP, Position Management settings where used, and integration definitions where transportable or deployable.
Master / governed dataFoundation Object records, Job Classifications, Positions, Departments, Divisions, Locations, Pay Structures, Legal Entities, and Event Reason records where applicable.
Employee / transaction dataPerson, Employment, Job Information, Compensation Information, effective-dated changes, workflow instances, approvals, and replication events.
01

EMPLOYEE IDENTITY KEYS

Which identity is being configured?

Person identity is not employment identity. Concurrent employment, global assignments, and downstream replication fail when the wrong identifier becomes the key.

  1. 01
    PERSONPerson ID External / UUID
  2. 02
    WORK RELATIONSHIPUser ID / Assignment ID
  3. 03
    EMPLOYMENTEmployer relationship
  4. 04
    JOB INFORMATIONEffective-dated assignment
  5. 05
    COMPENSATION INFORMATIONEffective-dated pay

Maintain in dependency order

  1. Confirm how Person ID External, UUID, User ID, Assignment ID, employment identifiers, and payroll or target-system identifiers are used.
  2. Decide how multiple assignments, concurrent employment, rehire, and global assignments will be represented and replicated.
  3. Map downstream integrations to the identifier that represents the intended relationship, not merely the visible profile.
EXPECTED PROOFOne person traces to the correct work relationship, employment, Job Information, Compensation Information, platform user, and downstream identity.
FAILURE CHECK

If a target record is duplicated or missed, compare Person ID, User ID, Assignment ID, employment identifier, effective date, and mapping rule before changing replication.

02

OBJECT DECOMPOSITION

Do not flatten Employee Central into one master record

Preserve Person -> Employment -> Job Information -> Compensation Information. Each layer owns different data, date behavior, permissions, and downstream consequences.

Person

Who is the human independent of any employer relationship?

Employment

Which employer relationship, status, hire, service, or termination context applies?

Job Information

Which department, manager, position, location, job, cost center, and payroll context is true on the effective date?

Compensation Information

Which pay structure, pay components, eligibility, and recurring compensation are true on the effective date?

Foundation and position dependency

  1. Define Legal Entity, Business Unit, Division, Department, Location, Job Classification, Pay Grade, Cost Center, and other foundation objects with ownership, validity, and dependency order.
  2. Where Position Management is used, maintain Job Classification -> Position -> Employee Job Information and test occupied, vacant, manager, and cost-assignment behavior.
  3. Where Position Management is not used, document how Job Information derives organization, manager, and reporting relationships.
03

EFFECTIVE DATING

When does the new employee truth become active?

Effective dating is not identical for every entity or field. Confirm the entity, correction behavior, retro impact, and downstream rule before treating a date as universal.

  1. 01
    Current RecordBefore state
  2. 02
    Future-Dated ChangeApproved event
  3. 03
    Effective DateActivation date
  4. 04
    New Record StateAfter state

Classify before saving

  1. Separate a new effective-dated business change from a correction. Correction != New Effective-Dated Change.
  2. Confirm whether the change is same-day, future-dated, retroactive, or corrective, and identify payroll, time, workflow, and integration consequences.
  3. Classify the business event and reason before testing workflow or replication. Ask why this is a Promotion, Transfer, Pay Change, or other event, and why this approver is required.
04

BUSINESS RULE VS WORKFLOW

Keep logic and approval distinct

Business Rules and Workflow interact, but they are not the same mechanism and they should not be tested with the same evidence.

Business Rule

Condition -> Derivation / Validation / Defaulting. It answers what the system should calculate, require, default, block, or derive because of the change.

Workflow

Trigger -> Approver Determination -> Approval. It answers who must approve the change and records the decision trail.

Maintain in dependency order

  1. Define event and event reason behavior, then rule conditions, derivations, validations, defaults, and error messages.
  2. Configure workflow triggers, approver determination, escalation or delegation behavior, and fallback ownership.
  3. Test pending, approved, declined, delegated, missing approver, and failed approver paths against the same effective-dated employee change.
POSITIVE PROOFEmployee Transfer -> Future Effective Date -> New Department / Manager / Position -> Event Reason Derived -> Validation -> Workflow -> Approval -> New Job Info Record -> Downstream Replication.
NEGATIVE PROOF

Show that an unauthorized user is blocked by RBP, or that an invalid change is blocked by Business Rule validation and creates no approved record.

05

ROLE-BASED PERMISSIONS

Who can see, edit, approve, and for which population?

RBP is part of the configuration proof, not a postscript. The target population and effective date can change the outcome.

Role

Who is acting: employee, manager, HR, payroll, recruiter, integration user, or administrator.

Permission

What action is permitted: view, edit, initiate, correct, approve, or administer.

Target Population

Which people, relationships, fields, or populations are in scope.

Proof mnemonic

  1. Use Role + Permission + Target Population = Access for each protected action.
  2. Prove one permitted user, one restricted user, the intended target population, and the approval action.
  3. Include sensitive fields, compensation, personal identifiers, bank details, termination data, and effective-dated access where applicable.
06

DOWNSTREAM RECONCILIATION

Where does approved employee data go next?

Approved Employee Central data is not automatically reconciled everywhere. Each downstream route needs an approved pattern, target owner, identifier, effective-date behavior, error process, and evidence.

  1. 01
    Approved Employee RecordSource
  2. 02
    Approved Integration PatternRoute
  3. 03
    Target SystemConsumer
  4. 04
    Error HandlingControl
  5. 05
    Target ProofEvidence

Define the integration contract

  1. Use Integration Center only where the selected scenario supports it. Identify source entity, target system, identifier, effective-date behavior, field mapping, retry behavior, error owner, and reconciliation evidence.
  2. Separate Employee Central Employee Data -> HRIS Sync -> SuccessFactors Platform User Data from Employee Central -> Payroll Replication / Integration -> Payroll System.
  3. Where SAP SuccessFactors Onboarding or an equivalent onboarding process is in scope, prove only the agreed onboarding hand-off instead of expanding this page into a full onboarding guide.
H2R / PAYROLL / R2R BOUNDARY

H2R CORE Employee / Employment / Job / Compensation Truth -> TIME & PAY INPUT Time / Absence / Pay Components -> PAYROLL Gross-to-Net / Payment -> R2R Finance Posting / Reconciliation.

RECONCILIATION MODEL

Approved EC Record -> Integration / Replication -> Target System Record -> Compare Key Fields -> Reconciled Result.

TARGET CHECKS

Verify correct employee or assignment, effective date, values, target record and status, no duplicate or missed replication, and cleared error queue.

PRODUCTION DESIGN LENS

Evaluate every configuration change beyond its saved setting

A change is safe only when its data, security, workflow, integration, and reconciliation effects are known and proven on the installed population.

EXISTING DATA

When an optional field becomes mandatory, identify incomplete historical workers, the next transaction that exposes the gap, and any different impact on employees, contingent workers, concurrent employments, and global assignments.

POSITION DEPENDENCIES

Where Position Management is used, Position affects incumbent, manager hierarchy, Job Information, workflow, and downstream use. Test an occupied and vacant Position before release.

RBP BOUNDARY

Role + Permission + Target Population determines whether a user can see data, change it, approve it, or act for a population and date. Prove each outcome separately.

WORKFLOW RESILIENCE

Test trigger, approver determination, delegation, fallback, missing manager, and approval result before treating a workflow as complete.

INTEGRATION CONTRACT

Define source entity, mapping, authentication, endpoint or target, schedule or event, target proof, monitor, retry, error owner, and reconciliation evidence.

PROVE THE LIFECYCLE

Can one worker move safely through the whole chain?

Settings are not evidence. Use a controlled fictional worker and retain only appropriately protected test evidence.

  1. 01
    Hire

    Prove Person, Employment, Job Information, Compensation Information where applicable, Event / Event Reason, rule outcome, completed workflow, approved record, permissions, and downstream result.

  2. 02
    Onboard

    Where SAP SuccessFactors Onboarding or an equivalent onboarding process is in scope, prove the agreed onboarding data collection, responsible groups, identity or access actions, and payroll readiness hand-off.

  3. 03
    Pay

    Prove compensation and time inputs, payroll selection, payroll result, payment or payslip evidence where in scope, and Finance posting or reconciliation ownership.

  4. 04
    Transfer

    Record person or assignment ID, effective date, event/reason, changed fields, rule outcome, workflow, approver, approved Job Information record, downstream replication, and target evidence.

  5. 05
    Exit

    Prove termination event and reason, final-pay initiation, access, benefit, equipment, and downstream updates with the same Employee Change -> Effective Date -> Event Reason -> Rule -> Workflow -> Approved Record -> Downstream Result trail.

FINAL PRINCIPLE

One Employee Change, One Effective-Dated Truth

Configuration is complete only when an employee change is correctly identified, effective-dated, classified, validated, approved, stored as the authoritative record and reconciled to the required downstream system. Settings are not evidence.

PRODUCT REFERENCES

Verify against the target landscape

SAP documentation for the installed release and country scope is authoritative for detailed configuration.

READY FOR THE PROJECT?Continue to H2R 505

Apply the workbench through workshops, testing, cutover, and stabilization.

Enter the live project