Oracle Fusion Recruit-to-Pay Test Scenarios
Validate the complete Oracle Fusion Recruit-to-Pay journey — job requisition, candidate, offer, offer acceptance, worker, assignment, compensation, payroll enrollment, payroll calculation, prepayments and payment — with emphasis on offer salary correctly carrying into hire salary and hire salary correctly carrying into the worker's first payroll calculation. This flagship end-to-end test orchestrates and links to the individually tested Recruiting, Core HR, Compensation and Payroll family pages rather than duplicating their atomic, field-level coverage.
| Test ID | ORCL.HCM.E2E.RECRUIT2PAY |
| Application | Oracle Fusion Cloud |
| Product | HCM |
| Module | End-to-End HCM |
| Process | Recruit-to-Pay |
| Business Flow | Hire-to-Retire |
| Scenario Type | End-to-End / Cross-Module |
| Test Usage | Functional Testing / Regression Testing / UAT |
| Priority | High |
| Automation | SyntraFlow Ready |
| Library | Syntra Standard Journey |
Note on test design: SyntraFlow executes the detailed Oracle Fusion UI interactions across every linked stage automatically while presenting the journey 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 240 underlying Oracle Fusion UI actions to complete it.
Test Objective
The objective of this test is to validate the complete Oracle Fusion Recruit-to-Pay journey — job requisition, candidate, offer, offer acceptance, worker, assignment, compensation, payroll enrollment, payroll calculation, prepayments and payment — with emphasis on offer salary correctly carrying into hire salary and hire salary correctly carrying into the worker's first payroll calculation, 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 Job Requisition, Candidate Application, Candidate Screening, Interview, Job Offer, Candidate-to-Worker, Convert Pending Worker, Hire Employee, Salary Change, Payroll Processing, Payroll Calculation, QuickPay, Retro Pay, Prepayments, Payment Processing, Costing and Payroll Validation pages. Instead, it links to those live pages and adds scenarios that specifically test the hand-offs and value continuity between them.
The scenario should confirm that:
- job requisition, candidate, offer, worker, assignment, compensation and payroll data correctly carry forward from one stage to the next
- offer salary correctly carries into hire salary at the point of hire
- hire salary correctly drives the worker's first payroll calculation and payment
- job, position and legal employer correctly carry from offer to worker assignment
- the worker is correctly assigned to the configured payroll relationship before the first payroll calculation runs
- prepayments and payment amounts correctly equal the calculated net pay for the worker's first payroll period
- Oracle correctly enforces validation when data errors, configuration errors, security restrictions or missing payroll setup are introduced at any stage of the journey (DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION)
This scenario orchestrates and links to the individually tested Recruiting, Core HR, Compensation and Payroll 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 Recruit-to-Pay journey in Oracle Fusion Cloud HCM TEST/UAT environments and does not cover internal transfers or promotions without a preceding recruiting event, which are covered by separate Core HR scenarios outside this journey.
When to Use This Test
- Flagship cross-module regression test validating cross-module continuity across the complete Recruiting to Payroll journey for a new Oracle Fusion implementation — it does not duplicate the atomic scenario coverage already tested on the 17 linked family pages
- Regression testing of hand-offs between Job Requisition, Job Offer, Candidate-to-Worker, Hire Employee, Salary Change, Payroll Processing, Payroll Calculation and Payment Processing after an Oracle quarterly update
- UAT sign-off across recruiters, hiring managers, HR specialists and payroll administrators who each own a different stage of the same recruit-to-pay transaction
- Validating offer-to-hire salary continuity and hire-to-first-payroll-calculation continuity for newly hired workers
- Diagnosing DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR and INTEGRATION_ERROR conditions surfaced at a stage hand-off before escalating as a possible APPLICATION_ERROR
The Recruit-to-Pay Journey
Recruit-to-Pay is SyntraFlow's flagship end-to-end Recruiting-to-Payroll HCM journey, spanning eleven stages from job requisition through payment. It does not duplicate the atomic scenario coverage already tested individually on the 17 linked family pages below. Instead, it focuses on the hand-offs and cross-stage data continuity between them — with emphasis on offer salary correctly carrying into hire salary, and hire salary correctly driving the worker's first payroll calculation. Exact configuration — recruiting workflow, approval routing, payroll cutoff dates and payment methods — depends on customer-specific Oracle Fusion setup.
Preconditions
- A job requisition ${REQUISITION} is approved and open for ${LEGAL_EMPLOYER} in the target Oracle Fusion environment.
- Recruiting, Core HR, Compensation and Payroll are configured for the legal employer, including salary basis, payroll definitions and payment methods.
- The test user or users hold appropriate access to progress a transaction through recruiting, hire, assignment, compensation and payroll stages.
- A valid payroll relationship, payroll calendar and an open ${HIRE_DATE}-relevant payroll period are configured in the target environment.
- This scenario assumes each linked family page's own preconditions are separately satisfied — it does not re-verify field-level setup already covered on those pages.
Exact configuration — including recruiting workflow, approval hierarchies, salary basis, payroll cutoff dates and payment methods — depends on customer-specific Oracle Fusion setup and is never assumed to be universal across implementations.
Sample Test Data
| Candidate | ${CANDIDATE} |
| Requisition | ${REQUISITION} |
| Offer | ${OFFER} |
| Worker | ${WORKER} |
| Legal Employer | ${LEGAL_EMPLOYER} |
| Salary | ${SALARY} |
| Payroll | ${PAYROLL} |
| Hire Date | ${HIRE_DATE} |
Sample values are illustrative placeholder tokens. Replace with valid data from the target Oracle Fusion HCM TEST/UAT environment. Not every field applies to every journey variation — for example, ${PAYROLL} does not apply to scenarios that stop before payroll enrollment.
Test Steps
8 business-readable steps. SyntraFlow's automation executes ~240 underlying UI actions to complete these steps — see How SyntraFlow Automates This Test.
| # | User Action | Expected Result |
|---|---|---|
| 1 | Create and Approve the Job Requisition Through Offer Acceptance Create job requisition ${REQUISITION} for ${LEGAL_EMPLOYER}, progress candidate ${CANDIDATE} through application, screening and interview, extend offer ${OFFER}, and confirm offer acceptance, using the linked Job Requisition, Candidate Application, Candidate Screening, Interview and Job Offer scenarios. ${REQUISITION} / ${CANDIDATE} / ${OFFER} This step orchestrates the Job Requisition, Candidate Application, Candidate Screening, Interview and Job Offer family pages rather than repeating their individual field-level test coverage. | The requisition, candidate and offer are correctly created and progressed, with offer salary ${SALARY} carried forward for hire. |
| 2 | Convert the Candidate to a Worker and Hire Convert accepted candidate ${CANDIDATE} to pending worker ${WORKER} and complete the hire for ${LEGAL_EMPLOYER} on ${HIRE_DATE}, using the linked Candidate-to-Worker, Convert Pending Worker and Hire Employee scenarios. ${WORKER} / ${HIRE_DATE} | Worker ${WORKER} is correctly hired, carrying candidate identity, job, position and legal employer forward from the offer. |
| 3 | Verify Salary and Assignment Continuity Compare offer salary ${OFFER_SALARY} against hire salary for worker ${WORKER}, and confirm job, position and legal employer on the worker's assignment match the offer, using the linked Salary Change scenario where a correction is required. ${SALARY} | Offer salary correctly carries into hire salary, and job, position and legal employer correctly carry into the worker's assignment. |
| 4 | Verify Payroll Relationship and Payment Method Setup Confirm worker ${WORKER} is assigned to payroll ${PAYROLL} with a valid personal payment method and bank details, using the linked Payroll Processing scenario. ${PAYROLL} | A valid payroll relationship and payment method exist for ${WORKER} before the first payroll calculation runs. |
| 5 | Run the First Payroll Calculation Execute the first payroll calculation for worker ${WORKER} on payroll ${PAYROLL}, confirming hire salary correctly drives the calculated pay, using the linked Payroll Calculation scenario. | The first payroll calculation correctly reflects hire salary ${SALARY} and any applicable bonus, allowance, benefit deduction, time or absence input. |
| 6 | Resolve Any Payroll Validation Exceptions Review and resolve any payroll validation exceptions raised during the first payroll calculation for ${WORKER}, using the linked Payroll Validation scenario, before resubmitting for prepayments. | Validation exceptions are correctly identified and resolved, or the calculation correctly proceeds where no exception applies. |
| 7 | Generate Prepayments and Payment Generate prepayments and payment for worker ${WORKER}'s first payroll calculation, using the linked Prepayments, Payment Processing and Costing scenarios. | Prepayments and payment amounts correctly equal the calculated net pay, and payroll costing is correctly generated. |
| 8 | Verify the Full Audit Trail Links Recruiting Through Payment TogetherBusiness assertion Trace the completed transaction from job requisition through candidate, offer, hire, assignment, compensation, payroll calculation, prepayments and payment to confirm the audit trail links every stage together. This is the primary business assertion for the scenario — a fully linked, correctly continuous and correctly paid worker across every stage is the expected pass condition, not merely a successful hire. | The audit trail correctly links requisition ${REQUISITION}, candidate ${CANDIDATE}, offer ${OFFER}, worker ${WORKER} and payroll ${PAYROLL} end-to-end, with payment correctly reflecting hire salary. |
Expected Results
- The job requisition, candidate, offer, worker, assignment, compensation and payroll are correctly linked end-to-end.
- Offer salary correctly carries into hire salary at the point of hire.
- Hire salary correctly drives the worker's first payroll calculation and payment.
- The worker is correctly assigned to the configured payroll relationship before the first payroll calculation runs.
- Prepayments and payment amounts correctly equal the calculated net pay for the first payroll period.
- Payroll validation exceptions and unauthorized actions at any stage of the journey are correctly enforced.
Key Validation Checkpoints
- Offer salary correctly carries into hire salary.
- Worker correctly assigned to the configured payroll relationship.
- Missing payroll relationship correctly blocks calculation.
- Payment method and bank details correctly validated before payment.
- First payroll calculation correctly reflects bonus, allowance, benefit and time inputs.
- Salary correction correctly triggers retro calculation.
- Payroll costing correctly generated.
- Unauthorized payroll or payment access correctly blocked.
Go Beyond the Standard Test with Jarvis AI
The Syntra Standard Test Library defines the core Recruit-to-Pay business journey as an orchestration across Recruiting, Core HR, Compensation and Payroll. Jarvis AI extends this journey by following the pipeline from HCM to Functional Area, Scenario Family and Standard Test Scenarios, then combining it with DataVault test data to generate Jarvis Variations — organized as Positive, Negative, Boundary, Security and Integration categories — before they can be assembled into a Regression Pack and Scheduled Execution, with results surfaced through Failure Intelligence.
Teams do not need to manually build a separate test for every candidate, offer, hire, assignment, compensation and payroll combination, or for every payroll timing edge case. Jarvis uses the standard journey as the foundation and generates relevant Positive, Negative, Boundary, Security and Integration variations for the customer's environment — including offer-to-hire salary correction paths, payroll cutoff timing, and missing payroll setup exceptions. These Jarvis-generated variations do not create additional public SEO pages, and this page itself does not duplicate the individual family pages it links to — it remains the canonical reference for the end-to-end journey.
From Standard Test to Executed Regression Pack
Rather than maintaining a separate test page for every candidate, offer, hire, assignment, compensation, payroll or payment-timing combination, SyntraFlow maintains one core Recruit-to-Pay journey scenario — with 45 example scenarios documented below — and allows Jarvis AI to generate salary-continuity, timing, boundary and security-specific variations using the customer's available test data. These variations do not create additional public SEO pages.
AI-Generated Test Variations
The same Recruit-to-Pay 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 HCM End-to-End.
- Complete the standard requisition-to-first-payroll-payment happy path for an external candidate
- Complete external and internal candidate hiring journeys through to first payroll
- Complete annual salaried and hourly worker hire journeys through to first payroll
- Complete hires timed before and after the configured payroll cutoff
- Complete journeys validating offer-to-hire salary continuity
- Complete journeys establishing payroll relationship and payment method setup for the new worker
- Complete first payroll calculations with bonus, allowance, benefits deduction, time input and absence during the first period
- Complete QuickPay journeys for a newly hired worker
- Missing salary or invalid salary basis at hire is correctly blocked before payroll enrollment
- Missing or invalid payroll relationship correctly blocks the first payroll calculation
- Missing payment method or invalid bank details are correctly blocked before payment
- Payment blocked due to invalid payment data is correctly enforced
- Payroll validation exceptions are correctly raised and surfaced
- Security restrictions on payroll and payment access are correctly enforced
These are representative examples only. Negative-scenario behavior and available payroll paths can depend on the customer's Oracle Fusion configuration, controls and security — not every Oracle configuration behaves identically.
Generated Using Your DataVault Test Data
Generic test data rarely represents every candidate, offer, worker, legal employer, salary, payroll and hire-date combination in a real Oracle Fusion Recruit-to-Pay environment. Where connected, Jarvis can use approved test data available through Syntra DataVault to construct Recruit-to-Pay journey scenarios relevant to the customer's actual implementation.
Standard Library Definition
Candidate ${CANDIDATE}
Requisition ${REQUISITION}
Offer ${OFFER}
Worker ${WORKER}
Legal Employer ${LEGAL_EMPLOYER}
Salary ${SALARY}
Payroll ${PAYROLL}
Hire Date ${HIRE_DATE}
DataVault
Candidates Active candidates available for offer and hire Requisitions Open, approved job requisitions by legal employer Offers Extended and accepted offers by salary and position Workers Newly hired workers by assignment and legal employer Payrolls Payroll definitions, calendars and cutoff dates by legal employer Payment Methods Personal payment methods and bank details by worker Security Roles authorised at each stage of the journey
Jarvis AI Generates
Scenario 001 — Standard Recruit-to-First-Pay Happy Path, ${WORKER}
Scenario 009 — Offer Salary Matches Hire Salary, ${OFFER}
Scenario 014 — Missing Payroll Relationship, ${WORKER}
Scenario 021 — First Payroll Calculation, ${PAYROLL}
Scenario 044 — First-Pay Audit Trail, ${WORKER}
...
Candidate, worker and payroll data used in Recruit-to-Pay testing is masked or synthetic through Syntra DataVault — never real production data or real PII. The public Syntra Standard Test Library uses illustrative placeholder data only, and where DataVault is connected, customer-specific journey dimensions remain within the customer's controlled SyntraFlow environment and access model, protected according to DataVault's data masking policies. See /datavault/data-masking/ for details.
Example Test Variations
This catalog spans 45 end-to-end Recruit-to-Pay journey scenarios validating requisition-to-first-payroll-payment continuity across Recruiting, Core HR, Compensation and Payroll, plus negative/boundary journey testing. These are illustrative, not separate indexable pages — the canonical page for all of them remains this one.
| ID | Variation | Type | Key Difference | Execution |
|---|---|---|---|---|
| HCM-R2P-001 | Standard Recruit-to-First-Pay Happy Path | Positive | Complete the full eleven-stage journey from job requisition ${REQUISITION} through candidate ${CANDIDATE}, offer ${OFFER}, hire, assignment, compensation and payroll calculation to first payment for worker ${WORKER} at ${LEGAL_EMPLOYER}, with every stage passing cleanly. | SyntraFlow Ready |
| HCM-R2P-002 | External Candidate to First Payroll | Positive | Progress external candidate ${CANDIDATE} through application, offer ${OFFER} and hire to worker ${WORKER}, confirming the external hire correctly reaches first payroll calculation on payroll ${PAYROLL}. | SyntraFlow Ready |
| HCM-R2P-003 | Internal Candidate to New Assignment and Payroll | Positive | Progress internal candidate ${CANDIDATE} through an internal requisition ${REQUISITION} to a new assignment for worker ${WORKER}, confirming the new assignment's salary correctly carries into the next payroll calculation. | SyntraFlow Ready |
| HCM-R2P-004 | Annual Salary Hire | Positive | Hire worker ${WORKER} at ${LEGAL_EMPLOYER} on an annual salary basis with salary ${SALARY}, confirming the annual salary correctly drives the first payroll calculation. | SyntraFlow Ready |
| HCM-R2P-005 | Hourly Worker Hire | Positive | Hire worker ${WORKER} at ${LEGAL_EMPLOYER} on an hourly salary basis with rate ${SALARY}, confirming the hourly rate correctly drives the first payroll calculation on payroll ${PAYROLL}. | SyntraFlow Ready |
| HCM-R2P-006 | Hire Before Payroll Cutoff | Positive/Boundary | Hire worker ${WORKER} on ${HIRE_DATE} at the boundary just before the configured payroll cutoff for payroll ${PAYROLL}, confirming the new hire is correctly included in the current payroll period's calculation. | SyntraFlow Ready |
| HCM-R2P-007 | Hire After Payroll Cutoff | Positive/Boundary | Hire worker ${WORKER} on ${HIRE_DATE} at the boundary just after the configured payroll cutoff for payroll ${PAYROLL}, confirming the new hire is correctly deferred to the next payroll period's calculation. | SyntraFlow Ready |
| HCM-R2P-008 | Future-Dated Hire | Positive | Create a future-dated hire for worker ${WORKER} with ${HIRE_DATE} set ahead of the current date, confirming the assignment and payroll relationship correctly activate on the future hire date rather than immediately. | SyntraFlow Ready |
| HCM-R2P-009 | Offer Salary Matches Hire Salary | Positive | Confirm offer ${OFFER} salary ${OFFER_SALARY} for candidate ${CANDIDATE} equals the hire salary recorded for worker ${WORKER} at hire, with no manual correction required. | SyntraFlow Ready |
| HCM-R2P-010 | Offer Salary Differs from Hire Salary | Positive | Record a hire salary for worker ${WORKER} that differs from offer ${OFFER} salary ${OFFER_SALARY}, confirming the discrepancy is correctly identified and the intended value is the one that drives the first payroll calculation. | SyntraFlow Ready |
| HCM-R2P-011 | Missing Salary at Hire | Negative | Attempt to hire worker ${WORKER} without a salary value recorded at hire, confirming Oracle correctly blocks progression to payroll enrollment until a valid salary ${SALARY} is entered. | SyntraFlow Ready |
| HCM-R2P-012 | Invalid Salary Basis | Negative | Attempt to hire worker ${WORKER} with a salary basis that is invalid or inconsistent with ${LEGAL_EMPLOYER}'s configuration, confirming Oracle correctly rejects the invalid salary basis before payroll enrollment. | SyntraFlow Ready |
| HCM-R2P-013 | Payroll Relationship Created | Positive | Confirm a payroll relationship is correctly created for worker ${WORKER} on payroll ${PAYROLL} following hire, ready for the first payroll calculation. | SyntraFlow Ready |
| HCM-R2P-014 | Missing Payroll Relationship | Negative | Attempt to run the first payroll calculation for worker ${WORKER} where no payroll relationship exists on payroll ${PAYROLL}, confirming Oracle correctly blocks the calculation until the relationship is created. | SyntraFlow Ready |
| HCM-R2P-015 | Worker Assigned to Correct Payroll | Positive | Confirm worker ${WORKER} is assigned to the payroll ${PAYROLL} appropriate to ${LEGAL_EMPLOYER} and assignment, and that this payroll is the one used for the first payroll calculation. | SyntraFlow Ready |
| HCM-R2P-016 | Invalid Payroll Assignment | Negative | Assign worker ${WORKER} to a payroll ${PAYROLL} that is invalid or inconsistent with ${LEGAL_EMPLOYER}, confirming Oracle correctly rejects the invalid payroll assignment before calculation. | SyntraFlow Ready |
| HCM-R2P-017 | Personal Payment Method Available | Positive | Confirm worker ${WORKER} has an active personal payment method ${PAYMENT_METHOD} on file before the first payroll calculation and payment are processed. | SyntraFlow Ready |
| HCM-R2P-018 | Missing Payment Method | Negative | Attempt to process payment for worker ${WORKER} where no personal payment method ${PAYMENT_METHOD} is on file, confirming Oracle correctly blocks payment until a valid method is added. | SyntraFlow Ready |
| HCM-R2P-019 | Valid Bank Details | Positive | Confirm worker ${WORKER}'s bank details attached to payment method ${PAYMENT_METHOD} are valid and verified, allowing electronic payment to be correctly processed. | SyntraFlow Ready |
| HCM-R2P-020 | Invalid Bank Details | Negative | Attempt to process electronic payment for worker ${WORKER} against invalid or unverified bank details on payment method ${PAYMENT_METHOD}, confirming Oracle correctly blocks the payment rather than transmitting it. | SyntraFlow Ready |
| HCM-R2P-021 | First Payroll Calculation | Positive | Run the first payroll calculation for worker ${WORKER} on payroll ${PAYROLL}, confirming hire salary ${SALARY} correctly drives the calculated gross and net pay. | SyntraFlow Ready |
| HCM-R2P-022 | Partial-Period Payroll | Positive | Run the first payroll calculation for worker ${WORKER} where ${HIRE_DATE} falls mid-period, confirming pay is correctly prorated for the partial period on payroll ${PAYROLL}. | SyntraFlow Ready |
| HCM-R2P-023 | Full-Period Payroll | Positive | Run the first payroll calculation for worker ${WORKER} where ${HIRE_DATE} aligns with the start of the payroll period, confirming pay is correctly calculated for the full period on payroll ${PAYROLL}. | SyntraFlow Ready |
| HCM-R2P-024 | New Hire with Bonus | Positive | Add a one-time bonus ${BONUS} to worker ${WORKER}'s first payroll calculation, confirming the bonus is correctly included in the calculated gross pay. | SyntraFlow Ready |
| HCM-R2P-025 | New Hire with Allowance | Positive | Add a recurring allowance ${ALLOWANCE} to worker ${WORKER}'s first payroll calculation, confirming the allowance is correctly included in the calculated gross pay. | SyntraFlow Ready |
| HCM-R2P-026 | New Hire with Benefits Deduction | Positive | Enroll worker ${WORKER} in a benefits plan with deduction ${BENEFIT_DEDUCTION} before the first payroll calculation, confirming the deduction is correctly applied to net pay. | SyntraFlow Ready |
| HCM-R2P-027 | New Hire with Time Input | Positive | Submit time entry ${TIME_ENTRY} for worker ${WORKER}'s first payroll period, confirming the time input is correctly reflected in the calculated pay for an hourly or time-based worker. | SyntraFlow Ready |
| HCM-R2P-028 | Missing Required Time Input | Negative | Attempt to calculate the first payroll for a time-based worker ${WORKER} where required time entry ${TIME_ENTRY} is missing, confirming Oracle correctly raises a validation exception rather than calculating an incomplete result. | SyntraFlow Ready |
| HCM-R2P-029 | New Hire with Absence During First Period | Positive | Record an absence ${ABSENCE} for worker ${WORKER} during the first payroll period, confirming the absence is correctly reflected in the first payroll calculation. | SyntraFlow Ready |
| HCM-R2P-030 | QuickPay for New Hire | Positive | Run a QuickPay calculation for worker ${WORKER} outside the standard payroll cycle, confirming hire salary ${SALARY} correctly drives the QuickPay result consistently with the standard first payroll calculation. | SyntraFlow Ready |
| HCM-R2P-031 | Salary Correction After Hire | Positive | Correct worker ${WORKER}'s salary from ${SALARY} to a revised value after hire, using the linked Salary Change scenario, confirming the correction is correctly recorded with an effective date. | SyntraFlow Ready |
| HCM-R2P-032 | Retro Calculation After Correction | Positive | Following a salary correction for worker ${WORKER}, run a retroactive payroll calculation, confirming the retro amount correctly reflects the difference between the original and corrected salary for the affected period. | SyntraFlow Ready |
| HCM-R2P-033 | Prepayments Generated | Positive | Generate prepayments for worker ${WORKER}'s first payroll calculation on payroll ${PAYROLL}, confirming the prepayment amount correctly equals the calculated net pay. | SyntraFlow Ready |
| HCM-R2P-034 | Payment Generated | Positive | Generate payment for worker ${WORKER} from the completed prepayments, confirming the payment amount and payment method ${PAYMENT_METHOD} correctly match the prepayment record. | SyntraFlow Ready |
| HCM-R2P-035 | Payment Blocked Due to Invalid Payment Data | Negative | Attempt to generate payment for worker ${WORKER} where payment data — such as payment method ${PAYMENT_METHOD} or bank details — is invalid, confirming Oracle correctly blocks the payment rather than issuing it. | SyntraFlow Ready |
| HCM-R2P-036 | Payroll Costing Generated | Positive | Generate payroll costing for worker ${WORKER}'s first payroll calculation, confirming costing correctly reflects the assignment's cost center and accounting distribution. | SyntraFlow Ready |
| HCM-R2P-037 | Invalid Costing Setup | Negative | Attempt to generate payroll costing for worker ${WORKER} where the costing setup for the assignment is invalid or incomplete, confirming Oracle correctly raises a costing exception rather than generating an incorrect distribution. | SyntraFlow Ready |
| HCM-R2P-038 | Payroll Validation Exception | Negative | Introduce a data condition that triggers a payroll validation exception during worker ${WORKER}'s first payroll calculation, confirming the exception is correctly raised and blocks progression to prepayments until resolved. | SyntraFlow Ready |
| HCM-R2P-039 | Payroll Security Restriction | Negative/Security | Attempt to access or modify worker ${WORKER}'s payroll calculation as a user without the payroll administrator role, confirming Oracle correctly restricts access. | SyntraFlow Ready |
| HCM-R2P-040 | Payment Security Restriction | Negative/Security | Attempt to access or process payment for worker ${WORKER} as a user without the payment-processing role, confirming Oracle correctly restricts access to the payment stage. | SyntraFlow Ready |
| HCM-R2P-041 | Offer-to-Hire Salary Continuity | Positive/Integration | Trace offer ${OFFER} salary ${OFFER_SALARY} through to worker ${WORKER}'s hire salary, confirming the value correctly carries forward without discrepancy across the offer-to-hire hand-off. | SyntraFlow Ready |
| HCM-R2P-042 | Hire-to-Pay Worker Continuity | Positive/Integration | Trace worker ${WORKER}'s identity, assignment and legal employer from hire through payroll enrollment to the first payment, confirming the same worker record is correctly referenced at every stage. | SyntraFlow Ready |
| HCM-R2P-043 | Payroll-to-Payment Amount Reconciliation | Positive/Integration | Reconcile the net pay calculated for worker ${WORKER} on payroll ${PAYROLL} against the prepayment and payment amount, confirming the amounts correctly tie out across the payroll-to-payment hand-off. | SyntraFlow Ready |
| HCM-R2P-044 | First-Pay Audit Trail | Positive/Integration | Trace worker ${WORKER}'s first pay from payroll calculation through prepayments to payment, confirming a complete and correctly linked audit trail exists for the first payroll payment. | SyntraFlow Ready |
| HCM-R2P-045 | End-to-End Recruit-to-Pay Traceability | Positive/Integration | Trace the completed journey from requisition ${REQUISITION} through candidate ${CANDIDATE}, offer ${OFFER}, worker ${WORKER}, assignment, compensation, payroll ${PAYROLL} and payment, confirming every stage correctly cross-references its upstream and downstream neighbors. | SyntraFlow Ready |
No variations match this filter.
Positive and Negative Journey Testing
Positive Testing
Jarvis generates journey scenarios using job requisition, candidate, offer, worker, assignment, compensation and payroll combinations expected to successfully complete the Recruit-to-Pay journey end-to-end in Oracle Fusion.
Accepted ${OFFER} + Hire ${WORKER} + Valid ${PAYROLL} Relationship → Journey Completes to First Payment
Negative Testing
Jarvis can also generate journey scenarios designed to exercise Oracle's validations around salary, payroll relationship, payment method and security controls across the journey.
- Missing Salary at Hire → Payroll Enrollment Blocked
- Missing Payroll Relationship → First Payroll Calculation Blocked
- Missing Payment Method → Payment Blocked
- Invalid Bank Details → Payment Blocked
- Payroll Validation Exception → Calculation Blocked
- Unauthorized User → Payroll or Payment Access Prevented
A negative end-to-end HCM scenario passes when Oracle correctly enforces the expected data, configuration or security rule at any stage of the journey
| Scenario | Oracle Outcome | Test Result |
|---|---|---|
| Valid journey data at every stage | Journey completes end-to-end | PASS |
| Data mismatch between stages | Validation or warning occurs | PASS |
| Missing required upstream document | Validation occurs | PASS |
| Unauthorized user at any stage | Access prevented | PASS |
| Unexpected application exception | Unexpected failure | FAIL |
Turn AI-Generated Variations into a Regression Pack
Users can select generated Recruit-to-Pay journey scenarios and group them into reusable execution packs.
HCM End-to-End Recruit-to-Pay Regression Pack
- Standard Recruit-to-First-Pay Happy Path
- Offer Salary Matches Hire Salary
- Payroll Relationship Created
- First Payroll Calculation
- Prepayments Generated
- Payment Generated
- Missing Payroll Relationship
- End-to-End Recruit-to-Pay Traceability
Run On-Demand or Schedule Automated Batch Execution
SyntraFlow can execute selected Recruit-to-Pay journey scenarios individually or as a batch. Users can schedule regression packs according to their testing cycle.
Once scheduled, SyntraFlow executes the selected Recruit-to-Pay journey scenarios unattended across Recruiting, Core HR, Compensation and Payroll, and records the outcome of each stage hand-off and business assertion.
| Pack | HCM End-to-End Recruit-to-Pay Regression Pack |
| Schedule | Weekly End-to-End Regression |
| Tests | 45 scenarios |
| Execution | Batch Mode |
| Start | 11:00 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 journey scenario, its business steps, the underlying automation actions, and the evidence captured at each stage hand-off.
Illustrative example data — not actual production metrics.
Regression Pack → Scenario → Business Step → Automation Action → Evidence
DataVault Journey Persona
Rather than generating an independent random value for each stage, Jarvis preserves one linked set of persona values — candidate, requisition, offer, worker, legal employer, job, position, salary, payroll, payment method and hire date — across every stage of the journey, so the offer, hire, assignment, compensation and payroll calculation in a given test run all describe the same underlying worker.
| Candidate | ${CANDIDATE} |
| Requisition | ${REQUISITION} |
| Offer | ${OFFER} |
| Worker | ${WORKER} |
| Legal Employer | ${LEGAL_EMPLOYER} |
| Job | ${JOB} |
| Position | ${POSITION} |
| Salary | ${SALARY} |
| Payroll | ${PAYROLL} |
| Payment Method | ${PAYMENT_METHOD} |
| Hire Date | ${HIRE_DATE} |
Linked persona data matters because a realistic Recruit-to-Pay test must prove that the same candidate's offer salary carries correctly through hire and into the first payroll calculation — a set of unrelated random values per stage would never expose a genuine salary-continuity or payroll-setup defect.
Security & Persona Variations
Access to each stage of the Recruit-to-Pay journey — recruiting, hiring, compensation and payroll — is controlled by Oracle Fusion's security configuration, which varies by customer. Jarvis can generate representative persona-based variations to confirm that access behaves as expected at each stage — not to assert a single universal Oracle security model.
| Persona | Action | Expected | Syntra Result |
|---|---|---|---|
| Recruiter | Manage Requisition Through Offer Stages | Allowed | PASS |
| Payroll Administrator | Process Payroll and Payment | Allowed | PASS |
| Unauthorized User | Attempts to Access Payroll Data Without Role | Access prevented | PASS |
Cross-Stage Business Assertions
These assertions validate that data continuity is preserved as a transaction moves from one journey stage to the next — they do not re-test each stage's own field-level validation, which remains covered on the linked family pages.
| Stage Transition | Assertion | Example | Status |
|---|---|---|---|
| Offer -> Hire | Offer Salary = Hire Salary | Offer salary ${OFFER_SALARY} = hire salary for ${WORKER} | PASS |
| Hire -> Assignment | Job, Position and Legal Employer correctly carry forward | Offer job/position/legal employer = assignment values for ${WORKER} | PASS |
| Assignment -> Payroll | Worker correctly assigned to the configured payroll | ${WORKER} payroll relationship = ${PAYROLL} | PASS |
| Payroll -> Payment | Payroll Net Pay = Prepayment/Payment Total | Payroll calculation net pay = payment amount for ${WORKER} | PASS |
Illustrative example using DataVault variables — not hard-coded production values.
Stage-by-Stage Execution Evidence
This shows a worked example of a Recruit-to-Pay journey run in which one stage fails, and how upstream and downstream stages are reported around it.
Illustrative example run — not a live execution.
Journey Failure Model
SyntraFlow is designed to surface a failure at the journey level — showing what passed upstream and what is blocked downstream — rather than reporting only an isolated stage failure.
| Recruiting | PASS |
| Hire | PASS |
| Payroll Setup | PASS |
Missing Payroll Relationship
Worker's first payroll calculation processes using the assigned payroll relationship.
No valid payroll relationship exists for the newly hired worker.
Prepayments and payment blocked until the payroll relationship is corrected.
Verify payroll relationship setup for the worker before rerunning the payroll calculation.
Do not label as an Oracle application defect without eliminating data, configuration, security, automation, environment and integration causes first.
Additional Named Regression Packs
This journey can be executed as one pack or split into focused packs covering specific behavior.
Recruit-to-Pay Standard Pack
- Standard Recruit-to-First-Pay Happy Path
- Offer Salary Matches Hire Salary
- Payroll Relationship Created
- First Payroll Calculation
- Prepayments Generated
- Payment Generated
Recruit-to-Pay Negative Pack
- Missing Salary at Hire
- Missing Payroll Relationship
- Invalid Payroll Assignment
- Missing Payment Method
- Invalid Bank Details
Recruit-to-Pay Correction Pack
- Salary Correction After Hire
- Retro Calculation After Correction
- QuickPay for New Hire
Understand Why a Test Failed
SyntraFlow execution evidence can help distinguish business-data failures, configuration issues, automation problems and potential application defects.
From Business Scenario to Execution Evidence
Business teams get readable test documentation; automation teams retain detailed execution traceability.
Meet Jarvis — SyntraFlow's AI Testing Engine
Jarvis extends the Syntra Standard Test Library by analysing the Recruit-to-Pay journey, available DataVault test data and expected business outcomes to generate additional Positive, Negative, Boundary, Security and Integration coverage for the customer's environment, following the HCM → Functional Area → Scenario Family → Standard Test Scenarios → DataVault Test Data → Jarvis Variations → Regression Pack → Scheduled Execution → Failure Intelligence pipeline. These variations do not create additional public SEO pages, and this page itself does not duplicate the individual family pages it links to — it orchestrates and cross-references them.
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.
Business Step → Underlying UI Actions
What SyntraFlow Captures Per Run
Action Status vs. Business Validation
A successful UI interaction at any single stage does not automatically prove the end-to-end journey is correct — this is illustrative of how SyntraFlow separates action success from business validation across a multi-stage journey; it does not reflect a specific live execution. When a step fails, SyntraFlow's evidence trail is designed to help a tester classify the likely cause — for example DATA_ERROR, CONFIGURATION_ERROR, SECURITY_ERROR, EXPECTED_VALIDATION, INTEGRATION_ERROR, AUTOMATION_ERROR, ENVIRONMENT_ERROR or APPLICATION_ERROR — without asserting the cause automatically. For example: First Payroll Calculation Failed — Likely category: DATA_ERROR — Evidence: Worker ${WORKER} has no valid payroll relationship on payroll ${PAYROLL} — Recommendation: Verify payroll relationship setup for the worker before rerunning the payroll calculation. A failure should never be labeled as an Oracle defect without first eliminating data, configuration, security, automation, environment and integration causes.
| Step | Action Status | Business Validation |
|---|---|---|
| Hire Employee | Pass | — |
| Run the First Payroll Calculation | Pass | — |
| Verify the Full Audit Trail Links Recruiting Through Payment Together | Pass | Pass |
Related End-to-End HCM Journeys & Family Tests
Recruit-to-Pay is SyntraFlow's flagship Recruiting-to-Payroll orchestration journey. Explore the related end-to-end journeys and the family scenario pages it links to below.
Turn This Standard Test into Your Oracle Recruit-to-Pay Regression Suite
Start with the Syntra Standard Recruit-to-Pay journey test, use DataVault to provide environment-specific test data, let Jarvis generate additional salary-continuity, timing and security variations, and execute the resulting regression pack automatically with SyntraFlow across Recruiting, Core HR, Compensation and Payroll.
Use This Oracle Fusion Test Case
Download Test Case
Excel, CSV or JSON export.
Coming soonAutomate with SyntraFlow
Run this script against your own tenant today.