{
  "test_id": "ORCL.HCM.SECURITY.USER_ACCESS",
  "scenario_name": "User Access",
  "application": "Oracle Fusion Cloud",
  "product": "HCM",
  "module": "HCM Data & Security",
  "process": "User Access",
  "business_flow": "Recruit-to-Security",
  "scenario_type": "Positive / Negative / Security",
  "priority": "High",
  "automation_status": "SyntraFlow Ready",
  "library": "Syntra Standard",
  "canonical_url": "https://www.syntraflow.cloud/oracle-erp-testing-tool/test-library/hcm/hcm-data-and-security/user-access/",
  "objective": {
    "intro": "This test validates authorized and unauthorized user access to worker, compensation, payroll, benefits and candidate data across HR specialist, manager, self-service and other user types, without assuming a universal access model.",
    "confirms": [
      "each user type is granted access strictly consistent with their assigned ${USER_ROLE} and ${DATA_ROLE}, scoped to their assigned ${WORKER_POPULATION} or hierarchy",
      "a user can correctly access their own record, and a manager can correctly access their direct reports, without gaining access beyond their authorized scope",
      "access to sensitive data domains — compensation, payroll, benefits, national identifier, recruiting, performance and learning — is correctly restricted to authorized user/role combinations",
      "access is correctly granted immediately after role or data role assignment, and correctly removed immediately after role removal or user deactivation",
      "read versus update permission boundaries, data export restrictions and session/user context are correctly enforced",
      "deliberately unauthorized access attempts — including unauthorized HDL and Extract access — are correctly denied, audited and classified rather than silently allowed"
    ],
    "scope_note": "A negative or security User Access scenario passes when Oracle correctly enforces the expected access-control rule; this test does not attempt to certify a specific Oracle application defect, and does not assume a universal access or security model — access is entirely dependent on customer-specific role, data role and configuration decisions. Where an access outcome appears unexpected or its cause is unclear, it is treated as requiring further investigation and supporting evidence rather than a confirmed conclusion. This page catalogs 30 individual User Access scenarios — a core SyntraFlow security-testing differentiator — as a single comprehensive reference rather than as separate indexable pages."
  },
  "preconditions": [
    "Oracle Fusion HCM User Access is available to the test user population.",
    "Representative ${USER} accounts covering HR specialist, manager, self-service and, where configured, contingent worker types are available.",
    "${USER_ROLE} and ${DATA_ROLE} assignments, including combinations intended to be authorized and unauthorized, are available for access-scoping testing.",
    "At least one ${WORKER} population, including workers inside and outside each test user's authorized ${WORKER_POPULATION}, is available.",
    "A ${MANAGER} with at least one direct report and at least one worker outside their hierarchy is available for hierarchy-scoping testing.",
    "Masked/synthetic worker, compensation, payroll, benefits and candidate data is available through DataVault so no real access records are used in testing.",
    "A user without the required access authorization, and access to the ${AUDIT_LOG}, are available for negative and audit-validation testing."
  ],
  "test_data": [
    {
      "field": "User",
      "example": "${USER}"
    },
    {
      "field": "Worker",
      "example": "${WORKER}"
    },
    {
      "field": "Manager",
      "example": "${MANAGER}"
    },
    {
      "field": "User Role",
      "example": "${USER_ROLE}"
    },
    {
      "field": "Data Role",
      "example": "${DATA_ROLE}"
    },
    {
      "field": "Worker Population",
      "example": "${WORKER_POPULATION}"
    },
    {
      "field": "Data Domain",
      "example": "${DATA_DOMAIN}"
    },
    {
      "field": "Access Type",
      "example": "${ACCESS_TYPE}"
    },
    {
      "field": "Session Context",
      "example": "${SESSION_CONTEXT}"
    },
    {
      "field": "Audit Log",
      "example": "${AUDIT_LOG}"
    }
  ],
  "business_steps": [
    {
      "step_number": 1,
      "step_name": "Sign In as the Test User Persona",
      "action": "Sign in to Oracle Fusion Cloud as the test ${USER}, holding the ${USER_ROLE} and ${DATA_ROLE} configured for this scenario.",
      "test_data": "${USER} / ${USER_ROLE} / ${DATA_ROLE}",
      "expected_result": "The user signs in successfully and lands in the work area appropriate to their role.",
      "validation_type": "action"
    },
    {
      "step_number": 2,
      "step_name": "Attempt to Access the Target Worker's Record or Data Domain",
      "action": "Attempt to navigate to the target ${WORKER}'s record or the specified ${DATA_DOMAIN}.",
      "test_data": "${WORKER} / ${DATA_DOMAIN}",
      "expected_result": "The navigation attempt completes and returns either the requested data or an access-denied response.",
      "validation_type": "action"
    },
    {
      "step_number": 3,
      "step_name": "Verify Access Is Correctly Granted or Denied Per Role and Population",
      "action": "Compare the actual access outcome against the access expected for the user's ${USER_ROLE}, ${DATA_ROLE} and ${WORKER_POPULATION}.",
      "test_data": "",
      "expected_result": "Access is correctly granted only when the user is authorized for the target worker and data domain, and correctly denied otherwise.",
      "validation_type": "business_assertion"
    },
    {
      "step_number": 4,
      "step_name": "Verify Read vs Update Permission Boundaries",
      "action": "Where the user holds read-only ${ACCESS_TYPE}, attempt to modify the data; where update access is granted, attempt to save a change.",
      "test_data": "${ACCESS_TYPE}",
      "expected_result": "Read-only access allows viewing but blocks modification; update access allows the change to be saved.",
      "validation_type": "business_assertion"
    },
    {
      "step_number": 5,
      "step_name": "Attempt Access to a Worker Outside the Authorized Population",
      "action": "Attempt to access a ${WORKER} explicitly outside the user's authorized ${WORKER_POPULATION} or hierarchy.",
      "test_data": "${WORKER_POPULATION}",
      "expected_result": "The out-of-population access attempt is submitted for evaluation.",
      "validation_type": "action"
    },
    {
      "step_number": 6,
      "step_name": "Verify the Out-of-Population Access Attempt Is Correctly Blocked",
      "action": "Confirm that the access attempt from the previous step is denied and that no unauthorized data is displayed or returned.",
      "test_data": "",
      "expected_result": "The unauthorized access attempt is correctly blocked, with no data disclosed beyond the user's authorization.",
      "validation_type": "business_assertion",
      "note": "Correctly blocking an unauthorized access attempt is a passing outcome for negative scenarios, not a failure."
    },
    {
      "step_number": 7,
      "step_name": "Verify the Audit Log Records the Access Attempt",
      "action": "Query the ${AUDIT_LOG} for the access attempt made in this scenario, whether granted or denied.",
      "test_data": "${AUDIT_LOG}",
      "expected_result": "The audit log contains a complete and accurate entry for the access attempt, including user, target and outcome.",
      "validation_type": "business_assertion"
    },
    {
      "step_number": 8,
      "step_name": "Verify Session Context Is Correctly Validated",
      "action": "Confirm that the access decisions observed in this scenario correctly reflect the ${SESSION_CONTEXT} — including the role and data role active for the signed-in session.",
      "test_data": "${SESSION_CONTEXT}",
      "expected_result": "Access control is applied consistently with the active session context throughout the scenario.",
      "validation_type": "business_assertion",
      "note": "This is the main business assertion for the scenario across the full catalog of 30 User Access variations."
    }
  ],
  "expected_results": [
    "Each user type — HR specialist, manager, employee self-service and, where configured, contingent worker — was granted access strictly consistent with their assigned role and data role.",
    "Users could correctly access their own record, and managers could correctly access their direct reports, without exceeding their authorized scope.",
    "Access to compensation, payroll, benefits, national identifier, recruiting, performance and learning data was correctly restricted to authorized user/role combinations.",
    "Access was correctly granted after role or data role assignment and correctly removed after role removal or user deactivation.",
    "Read versus update permission boundaries, data export restrictions and session/user context were correctly enforced.",
    "Deliberately unauthorized access attempts, including unauthorized HDL and Extract access, were correctly denied, audited and classified rather than silently allowed."
  ],
  "validation_checkpoints": [
    "Access correctly granted only to the intended user's own record or assigned population.",
    "Manager access correctly scoped to their hierarchy.",
    "HR specialist access correctly scoped to their assigned population.",
    "Access correctly revoked immediately after role removal or user deactivation.",
    "Sensitive data domains — compensation, payroll, national identifier — correctly access-controlled.",
    "Unauthorized access attempts correctly blocked and audited."
  ]
}