Sf Position Integrity Review

SF Position Integrity Review

Scan position management data for structural inconsistencies that cause payroll, reporting, and org-chart failures.

When to Use

• Before payroll processing to catch missing incumbents
• After a reorganisation to validate hierarchy chains
• During pre-migration data quality assessment
• When org chart visualisations show broken reporting lines
• As part of quarterly data integrity health checks

Prerequisites

• Position and employee data from SF (OData export, CSV, or API response)
• SF Position Integrity Checker tool (if available)
• Or raw Position OData entities with parentPosition, incumbent, and status fields

Evidence and Human Control

• Capture source evidence with tenant, population, effective date and extraction timestamp.
• Separate validation evidence from assumptions about payroll, workflow and integration impact.
• Treat employee identifiers and incumbent details as sensitive data; minimise and mask them in client outputs.
• Require human approval from HR data and HRIS/SF owners before any remediation or writeback.
• Re-run the integrity checks after remediation and reconcile the before/after population.

Workflow (Manual Analysis)

Step 1: Extract position data

Pull from SF OData or use existing export:

curl -u user:pass "https://apiXX.sapsf.eu/odata/v2/Position?\$select=code,parentPosition,incumbent,status,effectiveStartDate,effectiveEndDate,lastModifiedDateTime&\$top=5000"

Step 2: Validate structural integrity

Check for:

• Orphaned positions: parentPosition references a code that doesn't exist
• Broken chains: position chain longer than expected (default: 15 levels)
• Cyclical references: A → B → C → A
• No incumbent: incumbent field null for > 90 days
• Mismatched counts: active positions vs active employees mismatch

Step 3: Categorise and score

Step 4: Produce fix recommendations

For each finding, output:

• Position code and name
• Current state (what's wrong)
• Root cause (why it happened)
• Fix action (exactly what to change)
• Rollback instructions

Edge Cases

• Matrix organisations: ignore parentPosition ambiguity; validate both reporting lines independently
• Dual-employed incumbents (global assignments): flag as expected if concurrentEmployment is active
• C-suite positions: positions reporting to board (external) have no parent in EC -- flag as expected
• MDF position types: if client uses custom position objects, adapt entity name
• Positions frozen mid-reorg: exclude positions with effectiveStatus=frozen from orphan checks
• Empty tenant / greenfield: produce a "no data" baseline report with setup recommendations

Common Pitfalls

1. Counting every orphan as a defect: Some orphans are intentional (board reporting, external secondments). Always include a "likely-intentional" filter.
2. Not checking effective dates: A position with no incumbent may be future-dated. Check effectiveStartDate.
3. Missing the payroll impact: Always link each finding to a concrete downstream effect (payroll error, reporting gap, compliance risk).
4. Over-communicating the noise: 500+ findings are overwhelming. Cluster similar issues and present top-N by business impact.

Verification Checklist

• All active positions processed
• Orphans categorised (intentional vs defect)
• Hierarchy cycles identified and isolated
• Payroll-impact findings flagged separately
• Fix recommendations include specific API or UI paths
• Client-safe summary produced