Oracle ERP Testing Tool > Test Library > Security

Syntra Standard Oracle Test Library

Oracle Fusion Sensitive Data Access Test Cases

Validate that salary, national identifier, bank account and other sensitive fields are correctly restricted to authorized users and correctly masked when captured in test evidence, screenshots, extracts and downstream systems — a comprehensive catalog of 25 individual Sensitive Data Access test scenarios spanning HCM sensitive fields, Financials/SCM sensitive fields, and masking/evidence continuity, the eighth family in the Security cluster.

Test ID	ORCL.SEC.SENSITIVE_DATA
Application	Oracle Fusion Cloud
Product	Security
Module	Security
Process	Sensitive Data Access
Business Flow	Access-to-Masked-Evidence
Scenario Type	Positive / Negative / Security / Integration
Test Usage	Functional Testing / Regression Testing / UAT Sign-Off
Priority	High
Automation	SyntraFlow Ready
Library	Syntra Standard

Note on test design: SyntraFlow executes the detailed Oracle Fusion sensitive-field access, extract and evidence-masking verification interactions automatically while presenting the scenario as business-readable test steps for documentation, review and reporting. This scenario is presented as 8 business-readable test steps; SyntraFlow's automation executes approximately 31 underlying Oracle Fusion UI actions to complete it.

Test Objective

This test validates that sensitive fields — salary, payroll results, national identifiers, bank account details, addresses, dependent and beneficiary data, candidate PII and performance documents in HCM, and supplier/customer/payment banking data in Financials/SCM — are correctly restricted to authorized users, and that any sensitive value captured in test evidence, screenshots, extracts or downstream systems is correctly masked, using masked/synthetic test data throughout.

The scenario should confirm that:

authorized users with the required ${ROLE} and ${FUNCTIONAL_PERMISSION} can correctly view the intended ${SENSITIVE_FIELD} within their granted ${WORKER_POPULATION} or scope
unauthorized users are correctly blocked from viewing salary, payroll results, national identifiers, bank details, address, dependent, beneficiary, candidate and performance data in HCM
unauthorized users are correctly blocked from viewing supplier bank accounts, payment bank accounts, customer sensitive data and payment output in Financials/SCM
extracts, reports and downloads correctly include permitted sensitive fields for authorized users and correctly exclude restricted sensitive fields for unauthorized users
any ${SENSITIVE_FIELD} value captured in SyntraFlow test evidence, screenshots or extracts is correctly masked according to the customer's configured Syntra DataVault masking rules
masked sensitive values remain consistent between Oracle Fusion evidence and downstream masked systems, and an auditable record of sensitive-field access is available for review
sensitive data access behavior reflects the customer's own configured security and masking model rather than assuming a universal Oracle restriction or masking scheme

A negative or security Sensitive Data Access scenario passes when Oracle correctly restricts unauthorized access to a sensitive field, or when SyntraFlow correctly masks a sensitive value in captured evidence; this test does not attempt to certify a specific Oracle application defect. This page catalogs 25 individual Sensitive Data Access scenarios as a single comprehensive reference rather than as separate indexable pages. All salary, national identifier, bank account and other sensitive values referenced throughout are ${PLACEHOLDER} tokens or explicitly masked test data, never real records.

When to Use This Test

Functional testing of salary, national identifier, bank account and other sensitive-field restriction during a new Oracle Fusion security implementation
Regression testing of sensitive-field restriction and masking after an Oracle quarterly update affecting security or field-level access
UAT sign-off for HCM sensitive-field access, Financials/SCM sensitive-field access, and masking/evidence continuity across the Sensitive Data Access catalog
Compliance and audit evidence for who can access which sensitive fields, and confirmation that captured test evidence never exposes unmasked sensitive values
Comprehensive scenario coverage for teams standardizing on a single Sensitive Data Access regression pack instead of dozens of near-duplicate scripts

Where This Test Fits in the Access-to-Masked-Evidence Process

Assign Role & Permission

→

Attempt Sensitive Field Access

→

Restrict or Allow per Configuration

→

Mask Captured Evidence & Downstream Data

Sensitive Data Access is the eighth family in the Security cluster. It exercises HCM sensitive-field restriction, Financials/SCM sensitive-field restriction, and masking continuity across test evidence, screenshots, extracts and downstream systems, and connects to User Access, Role Assignment, Data Role Security, Privilege Validation, Segregation of Duties, Access After Transfer and Access After Termination within the same cluster. Exact field-level restriction rules and masking configuration depend entirely on customer-specific Oracle Fusion security configuration and Syntra DataVault masking rules — no universal restriction or masking model is assumed.

← Previous Stage

Access After Termination

Preconditions

Oracle Fusion Security Console access is available to a test user with role, data role and privilege administration rights.
Representative ${ROLE}, ${DATA_ROLE} and ${FUNCTIONAL_PERMISSION} definitions covering sensitive HCM and Financials/SCM fields are available or can be constructed in the target Oracle Fusion environment.
Test users are available to represent personas with and without access to each ${SENSITIVE_FIELD} under test.
A valid ${WORKER_POPULATION}, ${BUSINESS_UNIT} and representative extract/report definitions are configured in the target Oracle Fusion environment.
Syntra DataVault masking rules are configured for the sensitive fields under test, covering test evidence, screenshot and downstream masking — see /datavault/data-masking/.
A downstream system, extract or masked copy is available for comparing masked values — see /datavault/downstream-masking/.
A user without the relevant role, data role or functional permission is available for unauthorized-access security testing.

Exact sensitive-field definitions, restriction rules and masking configuration vary by Oracle Fusion implementation and customer-specific security and DataVault configuration; no universal restriction or masking model is assumed. All user, salary, national identifier, bank account and other values used in testing are masked/synthetic DataVault data — never real records.

Sample Test Data

User	${USER}
Role	${ROLE}
Data Role	${DATA_ROLE}
Functional Permission	${FUNCTIONAL_PERMISSION}
Worker Population	${WORKER_POPULATION}
Sensitive Field	${SENSITIVE_FIELD}
Salary	${SALARY}
National Identifier	${NATIONAL_ID}
Bank Account	${BANK_ACCOUNT}
Supplier Bank Account	${SUPPLIER_BANK_ACCOUNT}
Extract / Report	${EXTRACT_FILE}
Business Unit	${BUSINESS_UNIT}

Sample values are illustrative ${PLACEHOLDER} tokens, not real salary, national identifier, bank account or other sensitive data. Replace them with masked/synthetic values from Syntra DataVault for the target Oracle Fusion TEST or UAT environment; not every field applies to every scenario. No real PII, salary figures, national identifiers or bank account numbers are ever used — placeholder tokens only, everywhere in this catalog.

Test Steps

8 business-readable steps. SyntraFlow's automation executes ~31 underlying UI actions to complete these steps — see How SyntraFlow Automates This Test.

#	User Action	Expected Result
1	Sign In as Test User Sign in to Oracle Fusion Cloud with a test user account under evaluation for sensitive-data access.	The Oracle Fusion Cloud home page loads successfully for the authenticated test user.
2	Attempt Authorized Sensitive Field AccessBusiness assertion As ${USER} holding ${ROLE} and the required ${FUNCTIONAL_PERMISSION}, attempt to view ${SENSITIVE_FIELD} (for example ${SALARY}, ${NATIONAL_ID} or ${BANK_ACCOUNT}) within the granted ${WORKER_POPULATION} or scope. ${USER} / ${ROLE} / ${SENSITIVE_FIELD} Confirming correctly authorized visibility is the counterpart assertion to the restriction scenarios in this catalog.	The sensitive field is correctly displayed for the authorized user.
3	Attempt Unauthorized Sensitive Field AccessBusiness assertion As a user without ${ROLE} or the required ${FUNCTIONAL_PERMISSION}, attempt to view the same ${SENSITIVE_FIELD}. ${SENSITIVE_FIELD} This is the main assertion tested across the HCM and Financials/SCM sensitive-field scenarios in this catalog.	Access to the sensitive field is correctly restricted or hidden.
4	Run Extract or Report Containing Sensitive FieldsBusiness assertion Run ${EXTRACT_FILE} both as an authorized and as an unauthorized user, where the extract or report would include ${SENSITIVE_FIELD}. ${EXTRACT_FILE}	The extract or report correctly includes permitted fields for the authorized user and correctly excludes restricted fields for the unauthorized user.
5	Capture Test Evidence for the Access Attempts Capture screenshots and step-level evidence for the authorized and unauthorized access attempts using SyntraFlow's evidence capture.	Evidence is captured for each step.
6	Verify Sensitive Field Masked in EvidenceBusiness assertion Inspect the captured evidence for any ${SENSITIVE_FIELD} value; confirm Syntra DataVault masking rules are applied to the value shown in the evidence. ${SENSITIVE_FIELD} See /datavault/data-masking/ for how Syntra DataVault masking rules are configured and applied to captured evidence.	Sensitive field values are correctly masked in the captured test evidence, according to the customer's configured masking rules.
7	Compare Masked Value with Downstream SystemBusiness assertion Compare the masked ${SENSITIVE_FIELD} value captured during testing with the corresponding masked value in a downstream system or extract, per Syntra DataVault downstream masking. ${SENSITIVE_FIELD} See /datavault/downstream-masking/ for how masked values are propagated consistently to downstream systems.	The masked value is consistent between the Oracle Fusion evidence and the downstream masked representation.
8	Review Access Audit TrailBusiness assertion Review the audit log entry recorded for the ${SENSITIVE_FIELD} access attempt. ${SENSITIVE_FIELD}	An auditable record of the access attempt, including user, role and outcome, is correctly available for review.

Expected Results

Authorized users correctly view ${SENSITIVE_FIELD} within their granted scope.
Unauthorized users are correctly blocked from viewing salary, payroll, national identifier, bank, address, dependent, beneficiary, candidate and performance data.
Unauthorized users are correctly blocked from viewing supplier bank accounts, payment bank accounts, customer sensitive data and payment output.
Extracts and reports correctly include permitted sensitive fields and exclude restricted sensitive fields based on the requesting user's access.
Sensitive field values are correctly masked in captured test evidence, screenshots and extracts.
Masked values remain consistent between Oracle Fusion evidence and downstream masked systems.
An auditable record of sensitive-field access is correctly available for review.

Key Validation Checkpoints

Authorized access to sensitive fields correctly granted within scope.
Unauthorized access to HCM sensitive fields correctly blocked.
Unauthorized access to Financials/SCM sensitive fields correctly blocked.
Extracts and downloads correctly include/exclude sensitive fields per access.
Sensitive fields correctly masked in test evidence and screenshots.
Masked values correctly consistent between evidence and downstream systems.
Sensitive data access correctly recorded for audit.
No real PII, salary figures, national identifiers or bank numbers ever used in testing.

Core Business Scenario

Sensitive Data Access

Scenario Catalog

25 Scenarios

Business Steps

Test Data

DataVault-Driven

Execution

On-Demand / Scheduled / Batch

Automation

SyntraFlow Ready

Jarvis AI

Go Beyond the Standard Test with Jarvis AI

The Syntra Standard Test Library defines the core Sensitive Data Access scenario. Jarvis AI can extend this scenario by systematically generating additional Positive, Negative, Security and Integration variations across every sensitive field, persona and masking rule using customer-specific test data available through Syntra DataVault.

Teams do not need to manually construct dozens of near-identical restriction and masking scenarios for every sensitive field and persona combination. Jarvis follows a consistent pipeline: it starts from a Standard Test such as Sensitive Data Access, combines it with DataVault dimensions — User + Role + Data Role + Sensitive Field + Masking Rule — and produces an Allowed, Restricted or Masked outcome for the customer's own configuration, without creating additional indexable pages. This is a strong differentiator for SyntraFlow: sensitive-field coverage expands automatically as DataVault data and masking rules grow, rather than requiring a new test to be written and published for every field and persona combination.

From Standard Test to Executed Regression Pack

Security

Oracle Fusion Security product area.

Security Test Library Module

Scenario cluster covering User Access, Role Assignment, Data Role Security, Privilege Validation, Segregation of Duties, Access After Transfer, Access After Termination and Sensitive Data Access.

Scenario Family — Sensitive Data Access

Salary, national identifier, bank account and other sensitive-field restriction across HCM and Financials/SCM, plus masking continuity in test evidence, screenshots, extracts and downstream systems.

Standard Test Scenarios

25 Syntra Standard Sensitive Data Access scenarios covering HCM sensitive fields, Financials/SCM sensitive fields, and masking/evidence continuity.

DataVault Personas & Data

Payroll Specialist Test User persona and supporting dimensions — User, Role, Data Role, Privilege, Business Unit, Worker Population, Manager Hierarchy, Security Scope, Sensitive Field.

Jarvis AI Variations

Positive, Negative, Security and Integration variations generated from the standard scenarios.

Regression Packs

Selected variations grouped into an executable Sensitive Data Access regression suite.

Scheduled Execution

Execute on demand or schedule the regression pack for unattended batch execution.

Failure Intelligence

Execution evidence classified into DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, INTEGRATION_ERROR, AUTOMATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR rather than assumed as an Oracle defect.

Rather than maintaining a separate test for every sensitive field, persona and masking-rule combination, SyntraFlow maintains one core Sensitive Data Access scenario and allows Jarvis AI to generate Positive, Negative, Security and Integration variations using the customer's available user, role and sensitive-field test data.

AI-Generated Test Variations

The same Sensitive Data Access business scenario can produce many test variations without creating separate public library pages. Below is a real slice of SyntraFlow's Build Scripts library, filtered to Security.

Positive Scenarios

Authorized visibility of salary, payroll, national identifier and bank data within granted scope
Authorized visibility of supplier, payment and customer sensitive data within granted scope
Extracts and reports correctly including permitted sensitive fields for authorized users
Sensitive fields correctly masked in test evidence and screenshots
Masked values correctly consistent between evidence and downstream systems
Sensitive data access correctly recorded for audit
Security and DataVault masking continuity across the full access-to-evidence path

Negative Scenarios

Unauthorized salary and payroll result view attempts
Unauthorized national identifier, address, dependent, beneficiary and candidate PII access attempts
Unauthorized supplier and payment bank account access attempts
Unauthorized customer sensitive data and payment output access attempts
Unauthorized extract or download attempts including restricted sensitive fields
Unmasked sensitive value appearing in captured evidence (correctly prevented)
Masked value mismatch between evidence and downstream system (correctly flagged)

These are representative examples only. Sensitive-field definitions, restriction rules, masking configuration and downstream masking behavior can depend on the customer's Oracle Fusion configuration and Syntra DataVault setup — not every Oracle configuration behaves identically, and not every field or persona shown here exists for every customer.

Generated Using Your DataVault Test Data

Generic test data rarely represents every sensitive field, persona and masking-rule combination in a real Oracle Fusion security and masking configuration. Where connected, Jarvis can use approved test data available through Syntra DataVault — User, Role, Data Role, Privilege, Worker Population, Business Unit, Sensitive Field and Masking Rule — to construct realistic Sensitive Data Access variations relevant to the customer's actual implementation.

Standard Library Definition

User                    ${USER}
Role                    ${ROLE}
Data Role               ${DATA_ROLE}
Functional Permission   ${FUNCTIONAL_PERMISSION}
Worker Population       ${WORKER_POPULATION}
Sensitive Field         ${SENSITIVE_FIELD}
Salary                  ${SALARY}
National Identifier     ${NATIONAL_ID}
Bank Account            ${BANK_ACCOUNT}
Supplier Bank Account   ${SUPPLIER_BANK_ACCOUNT}

DataVault

Users and Roles
  Users with valid and invalid role, data role and functional permission assignments for sensitive fields
Sensitive Fields
  Salary, payroll result, national identifier, bank account, address, dependent, beneficiary, candidate PII and performance document combinations
Financials/SCM Sensitive Fields
  Supplier bank account, payment bank account, customer sensitive data and payment output combinations
Extracts and Reports
  Extract and report definitions with and without sensitive fields, run by authorized and unauthorized users
Masking Rules
  Field-level masking patterns applied to test evidence, screenshots and extracts
Downstream Systems
  Masked copies used to verify downstream masking continuity

Jarvis AI Generates

Scenario 01 — Positive: Salary Visible to Authorized HR
Scenario 02 — Negative/Security: Salary Hidden from Unauthorized User
Scenario 03 — Negative/Security: Supplier Bank Account Restricted
Scenario 04 — Positive: Sensitive Field Masked in Test Evidence
Scenario 05 — Positive/Integration: Downstream Masked Value Consistent
Scenario 06 — Positive: Sensitive Data Access Audit
...

All user, salary, national identifier, bank account and other sensitive test data used in Sensitive Data Access testing are masked/synthetic via DataVault — never real records. This follows the same masked-only standard used across the Security cluster — see /datavault/data-masking/ for how DataVault masks sensitive values captured in evidence, and /datavault/downstream-masking/ for how masked values are propagated consistently to downstream systems.

Example Test Variations

A comprehensive catalog of 25 individual Sensitive Data Access test scenarios spanning HCM sensitive fields, Financials/SCM sensitive fields, and masking/evidence continuity. Filter or search below.

ID	Variation	Type	Key Difference	Execution
SEC-SENS-001	Salary Visible to Authorized HR	HCM/Positive	As an authorized HR user with the required ${FUNCTIONAL_PERMISSION}, view ${SALARY} for a worker within the granted ${WORKER_POPULATION}; Oracle Fusion correctly displays the salary field.	SyntraFlow Ready
SEC-SENS-002	Salary Hidden from Unauthorized User	HCM/Negative/Security	As a user without payroll or compensation access, attempt to view ${SALARY} for a worker; Oracle Fusion correctly hides or restricts the salary field.	SyntraFlow Ready
SEC-SENS-003	Payroll Result Restricted	HCM/Negative/Security	As a user without payroll access, attempt to view a worker's payroll result; Oracle Fusion correctly restricts the payroll result.	SyntraFlow Ready
SEC-SENS-004	National Identifier Restricted	HCM/Negative/Security	As a user without the required functional permission, attempt to view a worker's ${NATIONAL_ID}; Oracle Fusion correctly restricts the national identifier.	SyntraFlow Ready
SEC-SENS-005	Bank Details Restricted	HCM/Negative/Security	As a user without payroll or banking access, attempt to view a worker's ${BANK_ACCOUNT}; Oracle Fusion correctly restricts the bank details.	SyntraFlow Ready
SEC-SENS-006	Address Access Restricted	HCM/Negative/Security	As a user without the required personal-data access, attempt to view a worker's home address; Oracle Fusion correctly restricts address data.	SyntraFlow Ready
SEC-SENS-007	Dependent Data Restricted	HCM/Negative/Security	As a user without dependent-data access, attempt to view a worker's dependent records; Oracle Fusion correctly restricts dependent data.	SyntraFlow Ready
SEC-SENS-008	Beneficiary Data Restricted	HCM/Negative/Security	As a user without benefits access, attempt to view a worker's beneficiary records; Oracle Fusion correctly restricts beneficiary data.	SyntraFlow Ready
SEC-SENS-009	Candidate PII Restricted	HCM/Negative/Security	As a user without recruiting access, attempt to view a candidate's personal identifiable information; Oracle Fusion correctly restricts candidate PII.	SyntraFlow Ready
SEC-SENS-010	Performance Document Restricted	HCM/Negative/Security	As a user without performance-management access, attempt to open a worker's performance document; Oracle Fusion correctly restricts the performance document.	SyntraFlow Ready
SEC-SENS-011	Supplier Bank Account Restricted	Financials/SCM/Negative/Security	As a user without supplier-payment administration access, attempt to view a ${SUPPLIER_BANK_ACCOUNT}; Oracle Fusion correctly restricts the supplier bank account.	SyntraFlow Ready
SEC-SENS-012	Payment Bank Account Restricted	Financials/SCM/Negative/Security	As a user without payment-processing access, attempt to view the bank account used on a payment; Oracle Fusion correctly restricts the payment bank account.	SyntraFlow Ready
SEC-SENS-013	Customer Sensitive Data Restricted	Financials/SCM/Negative/Security	As a user without customer-account access, attempt to view sensitive data on a customer record; Oracle Fusion correctly restricts the customer sensitive data.	SyntraFlow Ready
SEC-SENS-014	Payment Output Restricted	Financials/SCM/Negative/Security	As a user without payment-output access, attempt to view or download a payment output file; Oracle Fusion correctly restricts the payment output.	SyntraFlow Ready
SEC-SENS-015	Extract/Download Restricted	Financials/SCM/Negative/Security	As a user without extract or reporting access, attempt to download ${EXTRACT_FILE} containing sensitive fields; Oracle Fusion correctly restricts the extract/download.	SyntraFlow Ready
SEC-SENS-016	Sensitive Field Masked in Test Evidence	Masking/Evidence/Positive	Capture test evidence for a step referencing ${SALARY} or ${NATIONAL_ID}; SyntraFlow correctly masks the sensitive field in the captured test evidence per Syntra DataVault masking rules.	SyntraFlow Ready
SEC-SENS-017	Sensitive Field Masked in Screenshots Where Configured	Masking/Evidence/Positive	Capture a screenshot of a screen displaying ${BANK_ACCOUNT} where screenshot masking is configured; SyntraFlow correctly masks the sensitive field in the screenshot.	SyntraFlow Ready
SEC-SENS-018	National Identifier Masking	Masking/Evidence/Positive	Capture evidence referencing a worker's ${NATIONAL_ID}; SyntraFlow correctly applies national identifier masking consistent with Syntra DataVault data-masking rules.	SyntraFlow Ready
SEC-SENS-019	Bank-Account Masking	Masking/Evidence/Positive	Capture evidence referencing a ${BANK_ACCOUNT} or ${SUPPLIER_BANK_ACCOUNT}; SyntraFlow correctly applies bank-account masking to the captured value.	SyntraFlow Ready
SEC-SENS-020	Salary Masking in Shared Evidence	Masking/Evidence/Positive	Share evidence containing ${SALARY} with a broader review audience; SyntraFlow correctly masks the salary value in the shared evidence.	SyntraFlow Ready
SEC-SENS-021	Downstream Masked Value Consistent	Masking/Evidence/Positive/Integration	Compare a masked ${SENSITIVE_FIELD} value captured during execution with the corresponding value in a downstream masked system or extract; the masked representation is correctly consistent, per Syntra DataVault downstream masking.	SyntraFlow Ready
SEC-SENS-022	Unauthorized Extract Excludes Sensitive Field	Masking/Evidence/Negative/Security	As a user without the required functional permission, run ${EXTRACT_FILE}; Oracle Fusion correctly excludes the restricted sensitive field from the extract output.	SyntraFlow Ready
SEC-SENS-023	Authorized Extract Includes Permitted Field	Masking/Evidence/Positive	As an authorized user, run ${EXTRACT_FILE} that includes a permitted sensitive field within the user's granted scope; Oracle Fusion correctly includes the permitted field in the extract output.	SyntraFlow Ready
SEC-SENS-024	Security + DataVault Masking Continuity	Masking/Evidence/Positive/Integration	Trace a ${SENSITIVE_FIELD} from Oracle Fusion Security access testing through Syntra DataVault masking and into downstream masked evidence; the masked value remains consistent end-to-end across the Security and DataVault masking layers.	SyntraFlow Ready
SEC-SENS-025	Sensitive Data Access Audit	Masking/Evidence/Positive	Review the access log for a ${SENSITIVE_FIELD} access event; SyntraFlow correctly records an auditable entry of who accessed the field, when and under which role, for security audit purposes.	SyntraFlow Ready

Positive and Negative Sensitive Data Access Testing

Positive Testing

Jarvis generates scenarios designed to confirm that Oracle Fusion correctly grants sensitive-field visibility and that SyntraFlow correctly masks sensitive values in evidence, when the role, data role, functional permission and masking configuration are all valid and authorized.

Valid Role + Data Role Scoped to Correct Population + Authorized Functional Permission → Sensitive Field Correctly Visible; Masking Rule Applied → Evidence Correctly Masked

Negative Testing

Jarvis can also generate scenarios that deliberately attempt to view or extract a sensitive field without authorization, or that check for an unmasked value in evidence, to confirm Oracle and SyntraFlow correctly reject or mask the condition rather than silently exposing it.

Unauthorized Salary View Attempt → Access Prevented
Unauthorized National Identifier Access → Access Prevented
Unauthorized Bank Account Access → Access Prevented
Unauthorized Supplier/Payment Bank Account Access → Access Prevented
Unauthorized Extract Including Sensitive Field → Field Excluded
Unmasked Sensitive Value in Captured Evidence → Correctly Prevented
Masked Value Mismatch with Downstream System → Correctly Flagged

A negative security scenario passes when Oracle correctly denies unauthorized access, blocks an unauthorized action, or restricts visibility exactly as the customer's security configuration requires.

Scenario	Oracle Outcome	Test Result
Authorized user views permitted sensitive field	Field displayed	PASS
Unauthorized user attempts to view sensitive field	Access prevented	PASS
Extract run by unauthorized user	Sensitive field excluded	PASS
Sensitive value captured in evidence	Value masked per DataVault rule	PASS
Unexpected application exception	Unexpected failure	FAIL

Turn AI-Generated Variations into a Regression Pack

Users can select generated Sensitive Data Access scenarios and group them into reusable execution packs.

Sensitive Data Access Regression Pack

Salary Visible to Authorized HR
Salary Hidden from Unauthorized User
National Identifier Restricted
Bank Details Restricted
Supplier Bank Account Restricted
Extract/Download Restricted
Sensitive Field Masked in Test Evidence
Bank-Account Masking
Downstream Masked Value Consistent
Security + DataVault Masking Continuity
Sensitive Data Access Audit

Add Selected to Regression Pack(coming soon)Run Now(coming soon)Schedule(coming soon)

Run On-Demand or Schedule Automated Batch Execution

SyntraFlow can execute selected Sensitive Data Access scenarios individually or as a batch. Users can schedule regression packs according to their testing cycle.

Once scheduled, SyntraFlow executes the selected Sensitive Data Access scenarios unattended and records the outcome of each test and business assertion, including masking verification.

Run immediatelyNightly regressionWeekly regressionBefore releaseAfter configuration changesAfter environment refreshQuarterly Oracle update testingPre-UAT validation

Pack	Sensitive Data Access Regression Pack
Schedule	Weekly Regression
Tests	25 scenarios
Execution	Batch Mode
Start	9:30 PM
Environment	Oracle Fusion TEST
Status	Scheduled

Illustrative example — not a live schedule.

Review Results Across the Entire Test Pack

Users can drill from the regression pack into a scenario, its business steps, the underlying automation actions, and the evidence captured for each — including masking verification.

Illustrative example data — not actual production metrics.

Total Scenarios

Passed

Failed

Exceptions

Positive Tests

Negative Tests

175

Business Assertions

Regression Pack → Scenario → Business Step → Automation Action → Evidence

DataVault HCM Persona

Rather than generating variations from disconnected field values, Jarvis can draw on a DataVault persona built for sensitive-field testing — keeping user, role, data role and scope dimensions coherent so that Sensitive Data Access testing constructs realistic, internally consistent access and masking scenarios rather than arbitrary field combinations.

Persona: Payroll Specialist Test User

User	${USER}
Role	${ROLE}
Data Role	${DATA_ROLE}
Privilege	${PRIVILEGE}
BU	${BUSINESS_UNIT}
Legal Employer	${LEGAL_EMPLOYER}
Worker Population	${WORKER_POPULATION}
Manager Hierarchy	${MANAGER_HIERARCHY}
Security Scope	${SECURITY_SCOPE}
Sensitive Field	${SENSITIVE_FIELD}

DataVault personas keep user, role, data role, scope and sensitive-field dimensions coherent, so Jarvis constructs realistic, internally consistent sensitive-data access and masking scenarios without relying on arbitrary or conflicting field combinations.

Sensitive Data Visibility Variations

Oracle Fusion sensitive-field visibility is customer-specific, so SyntraFlow can exercise access under different DataVault personas to confirm the customer's own restriction and masking model behaves as expected, rather than assuming a universal Oracle visibility or masking scheme.

Persona	Action	Expected	Syntra Result
Payroll Specialist	View Salary and Payroll Result Within Scope	Allowed	PASS
HR Specialist	View National Identifier Within Scope	Allowed	PASS
Employee	View Own Salary	Allowed	PASS
Line Manager	View Salary of a Worker Outside Compensation Access	Access prevented	PASS
Unauthorized User	View Bank Account or National Identifier	Access prevented	PASS
Security Administrator	Review Masked Sensitive Data Access Audit Entry	Allowed	PASS

Understand Why a Test Failed

SyntraFlow execution evidence can help distinguish business-data failures, configuration issues, automation problems and potential application defects.

DataConfigurationSecurityAutomationApplicationEnvironmentExpected Validation

Jarvis Failure Intelligence — Coming Soon

From Business Scenario to Execution Evidence

Business teams get readable test documentation; automation teams retain detailed execution traceability.

Standard Business Scenario

AI-Generated Variation

Regression Pack

Business Test Step

Automation Actions

Business Assertion

Masked Screenshot / Evidence

Execution Result

Meet Jarvis — SyntraFlow's AI Testing Engine

Jarvis extends the Syntra Standard Test Library by analysing the Sensitive Data Access scenario, available DataVault test data and expected business outcomes to systematically generate Positive, Negative, Security and Integration coverage for the customer's environment.

Generate

Positive, Negative, Security and Integration variations.

Parameterize

Use relevant user, role and sensitive-field data from DataVault.

Assemble

Build reusable regression packs.

Execute

Run scenarios autonomously.

Schedule

Execute unattended test batches.

Validate

Evaluate expected business outcomes and masking correctness.

How SyntraFlow Automates This Test

The Standard Test defines the scenario; DataVault, Jarvis AI and SyntraFlow's execution engine take it from a single reusable business definition to executed, evidenced regression coverage.

Standard Library — Sensitive Data Access, 8 Business Steps

↓

DataVault — Security Persona-Specific Test Data

↓

Jarvis AI — Generate Positive/Negative/Security/Integration Variations

↓

Regression Pack — Select Relevant Coverage

↓

SyntraFlow Execution — Each Variation

↓

Detailed UI Actions

↓

Business Assertions

↓

Masked Evidence

↓

PASS / FAIL

Business Step → Underlying UI Actions

Business Step

Attempt Unauthorized Sensitive Field Access

May internally include

Sign In as Unauthorized User → Navigate to Worker/Supplier/Customer Record → Attempt to View Sensitive Field → Capture Access-Denied or Hidden-Field Response

Business Step

Verify Sensitive Field Masked in Evidence

May internally include

Capture Screenshot → Apply Syntra DataVault Masking Rule → Compare Masked Value Against Expected Mask Pattern → Record Result

What SyntraFlow Captures Per Run

Parameterised input valuesReusable navigationAutomation action traceScreenshots / evidence capture with maskingExecution timingPass / fail statusBusiness assertionsEnvironment-independent test data

Action Status vs. Business Validation

A successful sign-in or navigation action does not automatically prove that a sensitive field was correctly restricted or correctly masked in evidence — this is illustrative of how SyntraFlow separates action success from business validation; it does not reflect a specific live execution. Because this page aggregates 25 individual scenarios across HCM sensitive fields, Financials/SCM sensitive fields, and masking/evidence continuity, evidence-based failure classification matters most here. When a step or business assertion fails, SyntraFlow's evidence is intended to help classify the likely cause into one of eight categories — DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, INTEGRATION_ERROR, AUTOMATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR — rather than assuming a defect. For example: an unauthorized user unexpectedly sees a sensitive field — Likely category: SECURITY_ERROR or CONFIGURATION_ERROR — Evidence: the assigned ${ROLE} or ${DATA_ROLE} grants broader visibility of ${SENSITIVE_FIELD} than intended for the test scenario — Recommended action: verify the role, data role and field-level security configuration before treating the result as an Oracle defect. A failure should not be labeled as an Oracle application defect until data, configuration, security, automation and integration causes have been eliminated.

Step	Action Status	Business Validation
Attempt Authorized Sensitive Field Access	Pass	Pass
Attempt Unauthorized Sensitive Field Access	Pass	Pass
Verify Sensitive Field Masked in Evidence	Pass	Pass

Related Security Tests

Sensitive Data Access is the eighth family in the Security cluster, covering 25 individual scenarios across HCM, Financials/SCM and masking/evidence continuity that connect to User Access, Role Assignment, Data Role Security, Privilege Validation, Segregation of Duties, Access After Transfer and Access After Termination within the same cluster.

User Access Role Assignment Data Role Security Privilege Validation Segregation of Duties Access After Transfer Access After Termination

Turn This Standard Test into Your Oracle Sensitive Data Access Regression Suite

Start with the Syntra Standard Sensitive Data Access test, use DataVault to provide environment-specific, masked user, role and sensitive-field data, let Jarvis generate additional Positive, Negative, Security and Integration variations, and execute the resulting regression pack automatically with SyntraFlow.

Automate with SyntraFlow Explore Security Test Library

Use This Oracle Fusion Test Case

Download Test Case

Excel, CSV or JSON export.

Coming soon

Automate with SyntraFlow

Run this script against your own tenant today.

Related Oracle Testing Resources

Oracle ERP Testing Tool Test Library Security Test Library Syntra DataVault DataVault Data Masking DataVault Downstream Masking

Frequently Asked Questions

How does this test catalog validate salary and payroll data restriction?

Scenarios SEC-SENS-001 through SEC-SENS-003 confirm that salary and payroll result fields are correctly visible to an authorized HR or payroll user within their granted worker population, and correctly hidden or restricted from a user without the required role or functional permission. Exact field-level visibility rules depend entirely on the customer's own Oracle Fusion HCM security configuration.

How are national identifiers, bank account details and other sensitive HCM fields protected during testing?

Scenarios SEC-SENS-004 through SEC-SENS-010 exercise national identifier, bank account, address, dependent, beneficiary, candidate and performance-document access restriction for unauthorized users, while SEC-SENS-011 through SEC-SENS-015 exercise the equivalent restrictions for supplier bank accounts, payment bank accounts, customer sensitive data and payment output in Financials/SCM. All test values used are ${PLACEHOLDER} tokens or masked/synthetic DataVault data, never real records.

How does SyntraFlow mask sensitive fields captured in test evidence and screenshots?

Scenarios SEC-SENS-016 and SEC-SENS-017 confirm that any sensitive value appearing in captured test evidence or screenshots is masked according to the customer's configured Syntra DataVault masking rules before it is stored or displayed. See /datavault/data-masking/ for how masking rules are defined and applied.

What is the relationship between Sensitive Data Access testing and Syntra DataVault data masking?

Sensitive Data Access testing confirms that Oracle Fusion correctly restricts who can view a sensitive field, while Syntra DataVault data masking confirms that any sensitive value captured during that testing — in evidence, screenshots or extracts — is never exposed in plain form. Scenarios SEC-SENS-018 through SEC-SENS-020 apply this masking specifically to national identifiers, bank accounts and salary values; see /datavault/ and /datavault/data-masking/ for the underlying masking platform.

How does downstream masking continuity work across systems?

Scenario SEC-SENS-021 compares a masked sensitive value captured during Oracle Fusion testing with the corresponding masked value in a downstream system or extract, confirming the masked representation stays consistent end-to-end. Scenario SEC-SENS-024 extends this to confirm continuity specifically between Security access testing and DataVault masking. See /datavault/downstream-masking/ for how Syntra DataVault propagates masked values to downstream systems.

How does SyntraFlow classify a failed Sensitive Data Access test?

When a step or business assertion fails, SyntraFlow's evidence is intended to help classify the likely cause into one of eight categories — DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, INTEGRATION_ERROR, AUTOMATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR — along with supporting evidence and a recommended action. For example, an unauthorized user unexpectedly seeing a sensitive field is likely a SECURITY_ERROR or CONFIGURATION_ERROR. A failure should not be labeled as an Oracle application defect until data, configuration, security, automation and integration causes have been eliminated.