{
  "test_id": "ORCL.SEC.ACCESS.TRANSFER",
  "scenario_name": "Access After Transfer",
  "application": "Oracle Fusion Cloud",
  "product": "Security",
  "module": "Security",
  "process": "Transfer-to-Access Security",
  "business_flow": "Transfer-to-Access",
  "scenario_type": "Positive / Negative / Security / Integration",
  "priority": "High",
  "automation_status": "SyntraFlow Ready",
  "library": "Syntra Standard",
  "canonical_url": "https://www.syntraflow.cloud/oracle-erp-testing-tool/test-library/security/access-after-transfer/",
  "objective": {
    "intro": "This test validates that a worker transfer — department, manager, location, Business Unit or legal-employer change via global transfer — correctly triggers Oracle Fusion to remove access tied to the worker's prior assignment and grant access tied to the worker's new assignment, using masked/synthetic test data and without assuming a universal security model.",
    "confirms": [
      "the old ${OLD_MANAGER}, ${OLD_DEPARTMENT} and ${OLD_BUSINESS_UNIT} holders correctly lose access to ${WORKER} once the transfer takes effect",
      "the new ${NEW_MANAGER}, ${NEW_DEPARTMENT} and ${NEW_BUSINESS_UNIT} holders correctly gain access to ${WORKER} once the transfer takes effect",
      "data-role scope, payroll population, compensation population and role-based recruiting access correctly recalculate to reflect the worker's post-transfer assignment",
      "approver hierarchies correctly update so that approvals route through the worker's new reporting line rather than the prior one",
      "access transitions correctly according to ${TRANSFER_EFFECTIVE_DATE}, including for future-dated transfers, rather than applying immediately or retroactively",
      "neither excess old access nor missing new access is retained after the transfer, and an audit trail of the access change is available for review",
      "transfer-driven access behavior reflects the customer's own configured security model rather than assuming a universal Oracle role or data-role structure"
    ],
    "scope_note": "A negative or security Access After Transfer scenario passes when Oracle correctly enforces the expected access-control rule; this test does not attempt to certify a specific Oracle application defect. This page catalogs 25 individual Access After Transfer scenarios as a single comprehensive reference rather than as separate indexable pages. All worker, user, department, manager, Business Unit and legal-employer values referenced throughout are ${PLACEHOLDER} tokens or explicitly masked test data, never real access grants."
  },
  "preconditions": [
    "Oracle Fusion Security Console and HCM administration access is available to a test user with role and data role administration privileges.",
    "A representative ${WORKER} exists with an initial department, manager, location, Business Unit and legal-employer assignment.",
    "Test users are available to represent the ${OLD_MANAGER}, ${NEW_MANAGER}, and department/BU/legal-employer role-holders under test, with and without access to ${WORKER}.",
    "A valid ${OLD_DEPARTMENT}, ${NEW_DEPARTMENT}, ${OLD_BUSINESS_UNIT}, ${NEW_BUSINESS_UNIT}, ${OLD_LEGAL_EMPLOYER} and ${NEW_LEGAL_EMPLOYER} are configured in the target Oracle Fusion environment.",
    "Data roles scoped by department, manager hierarchy, Business Unit and legal employer are documented for the roles under test.",
    "A ${TRANSFER_EFFECTIVE_DATE} can be set to a current, past or future date to test effective-dated transfer behavior.",
    "Payroll population, compensation population and recruiting access mappings are documented where they depend on department, Business Unit or legal-employer assignment."
  ],
  "test_data": [
    {
      "field": "Worker",
      "example": "${WORKER}"
    },
    {
      "field": "Old Department",
      "example": "${OLD_DEPARTMENT}"
    },
    {
      "field": "New Department",
      "example": "${NEW_DEPARTMENT}"
    },
    {
      "field": "Old Manager",
      "example": "${OLD_MANAGER}"
    },
    {
      "field": "New Manager",
      "example": "${NEW_MANAGER}"
    },
    {
      "field": "Old Business Unit",
      "example": "${OLD_BUSINESS_UNIT}"
    },
    {
      "field": "New Business Unit",
      "example": "${NEW_BUSINESS_UNIT}"
    },
    {
      "field": "Old Legal Employer",
      "example": "${OLD_LEGAL_EMPLOYER}"
    },
    {
      "field": "New Legal Employer",
      "example": "${NEW_LEGAL_EMPLOYER}"
    },
    {
      "field": "Old Location",
      "example": "${OLD_LOCATION}"
    },
    {
      "field": "New Location",
      "example": "${NEW_LOCATION}"
    },
    {
      "field": "Transfer Effective Date",
      "example": "${TRANSFER_EFFECTIVE_DATE}"
    },
    {
      "field": "Data Role",
      "example": "${DATA_ROLE}"
    }
  ],
  "business_steps": [
    {
      "step_number": 1,
      "step_name": "Sign In as Security Administrator",
      "action": "Sign in to Oracle Fusion Cloud with a user account that has HCM and Security Console administration access.",
      "test_data": "",
      "expected_result": "The Oracle Fusion Cloud home page loads successfully for the authenticated security administrator.",
      "validation_type": "action"
    },
    {
      "step_number": 2,
      "step_name": "Capture Pre-Transfer Access Baseline",
      "action": "Record the access currently held by ${OLD_MANAGER} and other role-holders scoped to ${WORKER}'s ${OLD_DEPARTMENT}, ${OLD_BUSINESS_UNIT} and ${OLD_LEGAL_EMPLOYER}, before the transfer is applied.",
      "test_data": "${WORKER} / ${OLD_DEPARTMENT} / ${OLD_MANAGER}",
      "expected_result": "The pre-transfer access baseline is captured successfully for comparison against post-transfer access.",
      "validation_type": "action"
    },
    {
      "step_number": 3,
      "step_name": "Apply Worker Transfer",
      "action": "Transfer ${WORKER} to ${NEW_DEPARTMENT}, ${NEW_MANAGER}, ${NEW_LOCATION}, ${NEW_BUSINESS_UNIT} or ${NEW_LEGAL_EMPLOYER} as applicable, effective ${TRANSFER_EFFECTIVE_DATE}.",
      "test_data": "${WORKER} / ${NEW_DEPARTMENT} / ${NEW_MANAGER} / ${TRANSFER_EFFECTIVE_DATE}",
      "expected_result": "The transfer transaction is applied successfully to the worker record with the intended effective date.",
      "validation_type": "action"
    },
    {
      "step_number": 4,
      "step_name": "Verify Old Access Removed",
      "action": "As ${OLD_MANAGER} and other prior scope holders, attempt to access ${WORKER}'s record once the transfer is effective.",
      "test_data": "${OLD_MANAGER} / ${WORKER}",
      "expected_result": "Access to ${WORKER} is correctly removed for ${OLD_MANAGER} and other role-holders scoped to the worker's prior department, manager hierarchy, Business Unit or legal employer.",
      "validation_type": "business_assertion",
      "note": "Correct removal of prior access is the core negative-security assertion tested across the old-access-removal scenarios in this catalog."
    },
    {
      "step_number": 5,
      "step_name": "Verify New Access Granted",
      "action": "As ${NEW_MANAGER} and other new scope holders, attempt to access ${WORKER}'s record once the transfer is effective.",
      "test_data": "${NEW_MANAGER} / ${WORKER}",
      "expected_result": "Access to ${WORKER} is correctly granted to ${NEW_MANAGER} and other role-holders scoped to the worker's new department, manager hierarchy, Business Unit or legal employer.",
      "validation_type": "business_assertion",
      "note": "Correct grant of new access is the main positive-security assertion tested across the new-access-grant scenarios in this catalog."
    },
    {
      "step_number": 6,
      "step_name": "Verify Data Role Scope and Population Recalculation",
      "action": "Confirm that ${DATA_ROLE} scope, payroll population, compensation population and role-based recruiting access for ${WORKER} recalculate to reflect the post-transfer assignment.",
      "test_data": "${DATA_ROLE} / ${WORKER}",
      "expected_result": "Data-role scope and dependent populations correctly recalculate to reflect the worker's new department, Business Unit or legal employer.",
      "validation_type": "business_assertion"
    },
    {
      "step_number": 7,
      "step_name": "Verify Approver Hierarchy Updated",
      "action": "Confirm that approval routing for transactions involving ${WORKER} follows ${NEW_MANAGER}'s approver hierarchy rather than ${OLD_MANAGER}'s.",
      "test_data": "${NEW_MANAGER} / ${WORKER}",
      "expected_result": "Approval routing correctly reflects the worker's updated manager hierarchy after the transfer.",
      "validation_type": "business_assertion"
    },
    {
      "step_number": 8,
      "step_name": "Review Audit History of Access Change",
      "action": "Review the audit history recording the access change associated with ${WORKER}'s transfer, including old and new access holders and the effective date.",
      "test_data": "${WORKER} / ${TRANSFER_EFFECTIVE_DATE}",
      "expected_result": "An audit record of the access change is available and correctly reflects who lost and who gained access, and when.",
      "validation_type": "business_assertion"
    }
  ],
  "expected_results": [
    "Old department, manager, Business Unit and legal-employer access to ${WORKER} is correctly removed once a transfer becomes effective.",
    "New department, manager, Business Unit and legal-employer access to ${WORKER} is correctly granted once a transfer becomes effective.",
    "Data-role scope, payroll population, compensation population and recruiting access correctly recalculate after a transfer.",
    "Approver hierarchies correctly update to route through the worker's new reporting line.",
    "Access transitions correctly according to ${TRANSFER_EFFECTIVE_DATE}, including future-dated transfers.",
    "No excess old access or missing new access remains after the transfer, and an audit trail is available."
  ],
  "validation_checkpoints": [
    "Old department/manager/BU/legal-employer access correctly removed after transfer.",
    "New department/manager/BU/legal-employer access correctly granted after transfer.",
    "Data-role scope and dependent populations correctly recalculate.",
    "Approver hierarchy correctly reflects the new reporting line.",
    "Access transitions correctly on the transfer effective date, including future-dated transfers.",
    "No excess old access or missing new access remains; audit history of the change is available."
  ]
}