{
  "test_id": "ORCL.HCM.E2E.WORKER2DOWNSTREAM",
  "scenario_name": "Worker-Data-to-Downstream",
  "application": "Oracle Fusion Cloud",
  "product": "HCM",
  "module": "End-to-End HCM",
  "process": "Worker-Data-to-Downstream",
  "business_flow": "Hire-to-Retire",
  "scenario_type": "End-to-End / Cross-Module",
  "priority": "High",
  "automation_status": "SyntraFlow Ready",
  "library": "Syntra Standard Journey",
  "canonical_url": "https://www.syntraflow.cloud/oracle-erp-testing-tool/test-library/hcm/end-to-end/worker-data-to-downstream/",
  "objective": {
    "intro": "The objective of this test is to validate the complete Oracle Fusion Worker-Data-to-Downstream journey — a worker data change made in Core HR, transmitted through HDL/API/HCM Extract, delivered through integration to a downstream target system, and confirmed through data validation and data masking validation — with emphasis on source-to-target field mapping accuracy and consistent masking of sensitive fields across every downstream target, not on re-testing each stage's own atomic, field-level validation. This page is an orchestration and journey test: it does not duplicate the scenario coverage already tested individually on the linked Person Management, Update Person Information, Manage Address, Manage Contact Information, Manage National Identifiers, Change Assignment, Global Transfer, Terminate Worker, HCM Data Loader, HCM Extracts, User Access and Role Security pages. Instead, it links to those live pages and adds scenarios that specifically test the hand-offs, field mapping accuracy and masking integrity between them. This journey is strategically important as SyntraFlow's central demonstration of Syntra DataVault's data-masking and data-lineage capabilities.",
    "confirms": [
      "worker data changes made in Core HR correctly propagate through HDL/API/HCM Extract, integration and delivery to the downstream target system",
      "sensitive fields — including national identifier, address, personal email, phone, compensation, bank, dependent and beneficiary data — correctly remain masked at every downstream target using synthetic DataVault values, never real PII",
      "extract record counts correctly match the eligible source worker population, and unauthorized fields are correctly excluded from the extract per field-level security",
      "source-to-target field mapping is correctly validated, and referential integrity is correctly maintained between the source worker record and the downstream target reference",
      "effective-dated changes correctly carry the correct effective date downstream, and downstream integration failures are correctly classified and recoverable via retry",
      "Oracle correctly enforces validation when data errors, configuration errors, security restrictions or integration failures are introduced at any stage of the journey (DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, INTEGRATION_ERROR)"
    ],
    "scope_note": "This scenario orchestrates and links to the individually tested Core HR and HCM Data & Security family pages listed on this page; it does not re-test each stage's own field-level validation, which remains covered on those pages. It covers the standard Worker-Data-to-Downstream journey in Oracle Fusion Cloud HCM TEST/UAT environments using masked and synthetic DataVault test data only, and does not cover payroll-specific downstream flows, which are covered by separate Payroll scenarios outside this journey."
  },
  "preconditions": [
    "A worker ${WORKER} exists in Core HR with an active assignment in the source Oracle Fusion environment ${SOURCE_SYSTEM}.",
    "HCM Data Loader, REST/API access and the relevant HCM Extract definition ${EXTRACT_DEFINITION} are configured and available to transmit worker data to ${TARGET_SYSTEM}.",
    "A masking policy ${MASKING_POLICY} is configured through Syntra DataVault for sensitive fields such as ${NATIONAL_IDENTIFIER} and ${COMPENSATION}.",
    "Integration connectivity between the source Oracle Fusion HCM environment and ${TARGET_SYSTEM} is available in the target TEST/UAT environment.",
    "This scenario assumes each linked family page's own preconditions — Core HR, HCM Data Loader, HCM Extracts, User Access and Role Security — are separately satisfied; it does not re-verify field-level setup already covered on those pages."
  ],
  "test_data": [
    {
      "field": "Worker",
      "example": "${WORKER}"
    },
    {
      "field": "Source System",
      "example": "${SOURCE_SYSTEM}"
    },
    {
      "field": "Target System",
      "example": "${TARGET_SYSTEM}"
    },
    {
      "field": "Extract Definition",
      "example": "${EXTRACT_DEFINITION}"
    },
    {
      "field": "Masking Policy",
      "example": "${MASKING_POLICY}"
    },
    {
      "field": "Effective Date",
      "example": "${EFFECTIVE_DATE}"
    },
    {
      "field": "National Identifier",
      "example": "${NATIONAL_IDENTIFIER}"
    },
    {
      "field": "Compensation",
      "example": "${COMPENSATION}"
    }
  ],
  "business_steps": [
    {
      "step_number": 1,
      "step_name": "Make a Worker Data Change in Core HR",
      "action": "Make a data change for worker ${WORKER} in Core HR — for example a name, address, job, position, department, location, manager or compensation change effective ${EFFECTIVE_DATE} — using the linked Update Person Information, Manage Address, Manage Contact Information, Manage National Identifiers or Change Assignment scenarios.",
      "test_data": "${WORKER} / ${EFFECTIVE_DATE}",
      "expected_result": "The worker data change is correctly saved in Core HR with the correct effective date.",
      "validation_type": "action",
      "note": "This step orchestrates the relevant Core HR family page rather than repeating its individual field-level test coverage."
    },
    {
      "step_number": 2,
      "step_name": "Generate the Extract / HDL / API Payload",
      "action": "Generate the outbound payload for worker ${WORKER} using HCM Data Loader, REST/API or HCM Extract definition ${EXTRACT_DEFINITION}, using the linked HCM Data Loader and HCM Extracts scenarios.",
      "test_data": "${EXTRACT_DEFINITION}",
      "expected_result": "The extract or payload is correctly generated, including the changed worker data and its effective date.",
      "validation_type": "action"
    },
    {
      "step_number": 3,
      "step_name": "Verify the Integration Transmits the Change",
      "action": "Confirm the integration layer transmits the extract or payload for worker ${WORKER} from ${SOURCE_SYSTEM} toward ${TARGET_SYSTEM}.",
      "test_data": "${SOURCE_SYSTEM} / ${TARGET_SYSTEM}",
      "expected_result": "The integration correctly transmits the payload without data loss or truncation.",
      "validation_type": "action"
    },
    {
      "step_number": 4,
      "step_name": "Verify the Downstream System Reflects the Change",
      "action": "Confirm ${TARGET_SYSTEM} correctly reflects the worker ${WORKER} data change, including the correct effective date ${EFFECTIVE_DATE}.",
      "test_data": "${TARGET_SYSTEM}",
      "expected_result": "The downstream target correctly reflects the source change with matching field values and effective date.",
      "validation_type": "action"
    },
    {
      "step_number": 5,
      "step_name": "Verify Sensitive Fields Are Masked at the Target",
      "action": "Confirm sensitive fields — such as ${NATIONAL_IDENTIFIER} and ${COMPENSATION} — are correctly masked at ${TARGET_SYSTEM} according to masking policy ${MASKING_POLICY}.",
      "test_data": "${MASKING_POLICY}",
      "expected_result": "Sensitive fields correctly remain masked at the downstream target and no real PII is exposed.",
      "validation_type": "action"
    },
    {
      "step_number": 6,
      "step_name": "Verify Unauthorized Fields Are Excluded",
      "action": "Confirm fields outside the recipient's field-level security are correctly excluded from the extract or payload delivered to ${TARGET_SYSTEM}, using the linked User Access and Role Security scenarios.",
      "test_data": "",
      "expected_result": "Unauthorized fields are correctly excluded from the extract for recipients who are not entitled to them.",
      "validation_type": "action"
    },
    {
      "step_number": 7,
      "step_name": "Verify Record Counts Reconcile Between Source and Target",
      "action": "Reconcile the eligible worker population in ${SOURCE_SYSTEM} against the record count received at ${TARGET_SYSTEM}.",
      "test_data": "",
      "expected_result": "The source and target record counts correctly reconcile for the eligible worker population.",
      "validation_type": "action"
    },
    {
      "step_number": 8,
      "step_name": "Verify the Full Data-Lineage Audit Trail",
      "action": "Trace the completed journey from the worker ${WORKER} data change in Core HR through the extract, integration and delivery to ${TARGET_SYSTEM} to confirm the data-lineage audit trail links every stage together.",
      "test_data": "",
      "expected_result": "The data-lineage audit trail correctly links the source worker change, extract, integration and downstream target record end-to-end, with masking correctly applied throughout.",
      "validation_type": "business_assertion",
      "note": "This is the primary business assertion for the scenario — a fully linked, correctly mapped and consistently masked data-lineage trail across every stage is the expected pass condition, not merely a successful file delivery."
    }
  ],
  "expected_results": [
    "The worker data change is correctly linked end-to-end from Core HR through the extract, integration and downstream target.",
    "Source-to-target field mapping is correctly validated for every propagated field.",
    "Sensitive fields correctly remain masked at every downstream target using synthetic DataVault values, never real PII.",
    "Extract record counts correctly match the eligible source worker population, and unauthorized fields are correctly excluded.",
    "Effective-dated changes correctly carry the correct effective date to the downstream target.",
    "Downstream integration failures are correctly classified, and unauthorized actions at any stage of the journey are correctly blocked."
  ],
  "validation_checkpoints": [
    "Worker data changes correctly propagate to the correct downstream target.",
    "Sensitive fields correctly remain masked at every target using synthetic DataVault values, never real PII.",
    "Extract record count correctly matches the eligible source population.",
    "Unauthorized fields correctly excluded per field-level security.",
    "Source-to-target field mapping correctly validated.",
    "Referential integrity correctly maintained.",
    "Effective-dated changes correctly carry the correct date downstream.",
    "Integration failures correctly classified and recoverable via retry."
  ]
}