Data Resilience and Null Remediation

The Reality of Source Data

Source systems are not clean. Orgs restructure mid-quarter, subsidiaries get deactivated while transactions still reference them, and hierarchy imports arrive with orphan nodes. A sync platform that chokes on these realities is not production-ready.

VersionForge ships with four hardened remediation patterns that handle the most common data quality failures without manual intervention.

Pattern 1: Workday Mid-Reorg Nulls

The problem: During an organizational restructuring in Workday HCM, the supervisorId field goes blank for employees whose managers have been reassigned. The old manager record is terminated, the new one is not yet effective, and the API returns null for the gap period.

How VersionForge handles it: The Workday connector detects null supervisor references and looks up the acting manager or next-level-up supervisor from the org hierarchy. If an acting manager exists, VersionForge maps the employee to that record. If no acting manager is available, the row is flagged in the Safety Gate with a NULL_SUPERVISOR warning so your team can resolve it manually.

Pattern 2: NetSuite Inactive Subsidiaries

The problem: A GL journal entry references subsidiary SUB-204, but that subsidiary was deactivated last quarter. The transaction is valid, but the dimension member no longer exists as an active entity.

How VersionForge handles it: The NetSuite connector maintains a subsidiary lineage map. When a reference points to an inactive subsidiary, VersionForge re-routes the entry to the parent entity in the hierarchy. The original subsidiary code is preserved in the row metadata so auditors can trace the re-routing.

Pattern 3: Adaptive Broken Hierarchies

The problem: A dimension import into Adaptive Planning includes members whose parent node does not exist in the current hierarchy. These orphan members cause import failures and break rollup calculations.

How VersionForge handles it: The Adaptive connector detects orphan dimension members during the pre-load validation step. Orphans are automatically parented to a configurable rollup node (typically an _Unassigned or _Review node) and flagged for review. This ensures the import succeeds and rollup totals remain intact while your team investigates the hierarchy gap.

resilience:
  brokenHierarchy:
    strategy: "auto-parent"
    rollupNode: "_Unassigned"
    flagForReview: true

Pattern 4: Stripe Prior-Period Refunds

The problem: A customer refund is processed against an invoice from a closed accounting period. The refund is valid, but loading it directly into the target would modify finalized numbers.

How VersionForge handles it: Prior-period refunds are never auto-loaded. They are routed to the Safety Gate with a PRIOR_PERIOD_ADJUSTMENT flag, the original invoice date, and the refund amount. Your team decides whether to apply the adjustment to the current period, re-open the prior period, or handle it outside the sync.

Auto-Remediation vs. Safety Gate Flagging

The guiding principle: if the correction is deterministic and reversible, auto-remediate. If it requires judgment, flag for review.

| Pattern | Strategy | Rationale | |---------|----------|-----------| | Null supervisor | Auto-map to acting manager | Deterministic lookup with clear fallback | | Inactive subsidiary | Re-route to parent entity | Hierarchy relationship is unambiguous | | Orphan dimension | Auto-parent to rollup node | Preserves import integrity; flagged for cleanup | | Prior-period refund | Safety Gate flag only | Requires policy decision; never auto-applied |

Configuring Remediation Rules

Each remediation pattern is enabled per connector in your sync profile. You can override the default strategy, change the rollup node for orphan handling, or disable auto-remediation entirely to force every edge case through the Safety Gate.