If you are preparing to test the Oracle Fusion Cloud 26C quarterly update before it reaches production, the short answer is this: build your test plan around change categories rather than a raw list of features, prioritise the business processes that carry the most financial and regulatory risk, and pay particular attention to the continued expansion of Oracle's agentic applications — including the new Agent2Agent (A2A) protocol introduced in 26C. This guide gives you a repeatable framework you can apply to 26C and to every future quarterly release, together with a ready-to-adapt 26C test-plan checklist. For the exact, module-by-module list of what changed in your environment, always cross-check against Oracle's official 26C readiness material and SyntraFlow's 26C release-intelligence pages, because the specifics that matter to you depend on which modules and features you have enabled.
Oracle ships four quarterly updates a year, and each one is mandatory — you cannot opt out, you can only schedule when your environment takes it. That makes each release a recurring test event, not a one-off project. Teams that treat every quarter as a fresh, ad-hoc scramble burn effort re-discovering the same risks; teams that run a disciplined, category-based readiness process turn the update into a routine. This pillar is written to help you build that routine.
Last reviewed: 19 July 2026. 26C is a current Oracle release; feature availability varies by module and configuration. Confirm every specific against Oracle's official 26C readiness documentation for your environment.
In this guide
- How to read a quarterly release for testing
- AI & agents in 26C (A2A, agentic apps, human approval, agent regression)
- Redwood UI changes
- ERP / Financials changes
- SCM changes
- HCM & payroll changes
- CX changes
- REST APIs & integrations
- Configuration changes
- Security & roles
- Deprecations: how to find and handle them
- High-risk business processes to prioritise
- Suggested test approach + 26C test-plan checklist
- Prepare now for 26D
How to read a quarterly release for testing
The biggest mistake teams make with an Oracle quarterly update is reading the "What's New" content as a reading exercise and then testing whatever they happen to remember. A release document can list hundreds of individual items across modules, and most of them will not touch your configuration at all. The skill is triage: converting a long, undifferentiated feature list into a short, ranked test plan. The most reliable way to do that consistently is to sort every change into a small number of change categories, because each category behaves differently and calls for a different testing response.
Every quarterly change tends to fall into one of the following buckets. Read the whole release once with this taxonomy in hand, tag each relevant item, and you will have the skeleton of your test plan before you write a single test case.
| Change category | What to look for | Testing response |
|---|---|---|
| AI & agents | New or expanded agentic apps, agent-to-agent coordination, new automated recommendations or approvals. | Define acceptable outcome envelopes; verify human-in-the-loop checkpoints; run scenario-based regression on agent decisions. |
| Redwood UI | Pages moved to Redwood, restyled components, changed field IDs, new flows replacing classic screens. | Re-validate automation selectors and end-to-end flows; check accessibility and any personalisation that assumed old markup. |
| Functional / module logic | Changes to calculations, matching rules, accounting, tax, planning logic, payroll elements. | Targeted functional regression on the affected process with representative and edge-case data. |
| REST APIs & integrations | New/changed/deprecated REST resources, altered payloads, versioned endpoints, event changes. | Contract-test each integration boundary; validate inbound/outbound payloads against your middleware. |
| Configuration & setup | New profile options, feature opt-ins, changed defaults, setup tasks that must be enabled. | Compare configuration before and after; confirm defaults did not silently change behaviour. |
| Security & roles | New privileges, changed duty roles, data-security predicate changes, seeded-role updates. | Re-run role provisioning tests and segregation-of-duties checks; verify access boundaries hold. |
| Deprecations & removals | Features flagged for removal, replaced screens, sunset APIs, "no longer available" notices. | Identify dependencies on the deprecated item; test the replacement path before the removal lands. |
Two habits make this triage reliable. First, always anchor it to your footprint: a change to Manufacturing costing is irrelevant if you do not run Manufacturing, and a change to a REST resource is only your problem if an integration consumes it. Second, keep the tagging evidence-based rather than from memory — connect the official release content to your test inventory so that each tagged change maps to specific test cases. This is exactly the kind of mapping SyntraFlow's Release Intelligence is designed to support: it can be configured to correlate the quarterly change list with your process coverage so the triage is repeatable rather than reliant on one person's institutional knowledge. For a lighter-weight starting point, our quarterly release readiness checklist walks through the same discipline step by step.
AI & agents in 26C
Oracle's agentic capability has been building steadily across recent releases, and 26C continues that expansion rather than resetting it. To keep the timeline straight: Oracle AI Agent Studio reached general availability in 25C; MCP tools, external REST tools, REST-API agent access, and Slack and Microsoft Teams channels arrived in 26A; the four Financials AI agents (Ledger, Payables, Payments, Expenses) and the broader Fusion Agentic Applications wave — Oracle describes more than 20 agentic applications across the suite — reached general availability in 26B, alongside Document IO becoming the default for Payables invoice ingestion. The headline agentic addition in 26C is the Agent2Agent (A2A) protocol, which allows agents to coordinate with one another rather than each operating in isolation. Confirm the precise scope of what is enabled in your pod against Oracle's official 26C readiness content, because agentic availability depends heavily on which modules and features you have opted into.
Agent2Agent (A2A) in 26C
A2A matters for testing because it changes the unit of behaviour you are validating. When a single agent makes a recommendation, you can reason about its inputs and its output envelope in isolation. When agents coordinate, the output of one becomes the input of another, and an acceptable-in-isolation decision can compound into an unexpected end-to-end result. Your test design should therefore treat agent-to-agent chains as first-class scenarios: seed a starting condition, let the coordinated agents run, and assert on the final business outcome as well as each intermediate handoff. SyntraFlow's coverage of this protocol is documented on the Oracle AI Agent2Agent (A2A) page, which is the right place to align your test scenarios with how the coordination actually behaves.
Agentic applications keep expanding
Because the agentic footprint grows most quarters, do not assume the set of agents you validated last release is the set you have now. Some agentic capability is delivered as a named agent (the Financials agents are the clearest examples), while much of it is described by function or workspace — Oracle's announcements reference capabilities such as SCM's Design-to-Source and Sourcing Command Center and the Cost Accounting Close, for instance, rather than singular branded "X Agent" products. Rather than reproduce a definitive list here, review Oracle's own 26C readiness material and our agentic applications overview to see what applies to your modules, then add each newly-enabled capability to your regression scope.
Human-approval checkpoints
A recurring risk with each agentic expansion is that a human review step you relied on quietly moves, changes threshold, or is bypassed for a class of transactions the agent now handles autonomously. This is precisely where financial and compliance exposure concentrates. For every agent in scope, explicitly test the boundary between what the agent decides on its own and what it must escalate: confirm that transactions above your approval thresholds, unusual patterns, and policy exceptions still route to a person, and that the approval audit trail is intact. Oracle's agentic applications are designed to operate within your existing permissions, policies, and approvals — but "designed to" is a claim you should verify against your own configuration, not assume.
Agent regression testing
Agent behaviour is probabilistic and can evolve with the data it sees, so the deterministic "input A always yields output B" assertion that works for a payroll calculation is the wrong shape for an agent. Instead, define an acceptable outcome envelope — the set of decisions that comply with your business policy — and validate that the agent's decision falls inside it, across a representative population of scenarios rather than a single case. This is a different discipline from classic regression, and it is worth reading our note on why traditional regression misses quarterly update risks. SyntraFlow's approach to this is described on the AI agent testing page, and our broader AI release intelligence capability can be configured to track how agentic changes in a release map to the scenarios you need to re-run.
Redwood UI changes
Oracle continues migrating Fusion pages to the Redwood design system, and this migration is one of the most reliable sources of test breakage each quarter — not because business logic changes, but because the underlying page structure does. Automated tests that were bound to older markup can fail when a page is rebuilt in Redwood even though the process still works perfectly for a human user. When you read the 26C content, treat every "now available in Redwood" or restyled-page note as a signal to re-validate any automation and any personalisation that touched that page.
Practically, that means three checks per affected page: does your end-to-end flow still complete; do your automation selectors still resolve to the right elements; and do any saved searches, personalisations, or embedded analytics that assumed the old layout still render. Selector fragility is the classic failure mode here — we cover the mechanics in Redwood UI changes that break Oracle test automation. Because Redwood churn is constant, resilient locators matter more than any single quarter's fix; SyntraFlow's Redwood UI testing is built specifically to reduce that fragility, and the topic is deep enough that it has its own dedicated pillar in our library. Cross-reference your 26C UI changes against SyntraFlow's 26C release-intelligence hub to see which pages moved.
ERP / Financials changes
Financials is usually the highest-stakes area to regress because errors surface as misstated numbers, blocked payments, or period-close delays. When you scan 26C for Financials, look for anything that touches accounting rules, tax determination, invoice matching tolerances, payment processing, and the period-close sequence — these are the changes most capable of producing a material impact. Do not overlook agentic changes here either, since the Payables and Ledger agents mean some Financials behaviour is now partly agent-driven and needs the outcome-envelope treatment described above.
For module-specific detail, work from the on-site 26C pages rather than a generic list: SyntraFlow tracks 26C Payables changes and 26C General Ledger changes so you can align your regression scope to exactly what shifted in each area. Prioritise Procure-to-Pay and Record-to-Report end-to-end flows with representative data plus deliberate edge cases (partial matches, tax exceptions, multi-currency, prepayments), and confirm every change against Oracle's official 26C readiness before you sign off.
SCM changes
Supply Chain changes tend to affect planning logic, costing, order orchestration, and manufacturing execution — areas where a subtle change compounds across a long process chain. As with Financials, some SCM capability is now delivered agentically; Oracle's announcements reference functional workspaces such as Design-to-Source and the Sourcing Command Center and the Cost Accounting Close, so treat these as coordination points to validate rather than assuming a single branded agent. Test order-to-cash and plan-to-produce flows end to end, and pay attention to costing and inventory valuation because those feed straight back into Financials.
If you run Manufacturing, the on-site 26C Manufacturing changes page is the place to check module specifics before scoping your work orders, resource, and costing tests. Keep the cross-module view in mind: an SCM costing change is also a Financials change once it posts.
HCM & payroll changes
HCM changes range from self-service and recruiting flows through to payroll calculation, and payroll is the part you cannot afford to get wrong — a miscalculated pay run or a broken statutory file has immediate, visible consequences. For HCM generally, focus on the hire-to-retire flows you actually use and on any Redwood migration of employee and manager self-service pages. For payroll, regress the full cycle: element entries, calculation, costing, payment, and every statutory or third-party output file you generate.
Payroll also intersects with regulatory frameworks — for example ZATCA e-invoicing in Saudi Arabia, HMRC Making Tax Digital in the UK, and GCC obligations such as WPS wage files, GOSI, and end-of-service gratuity. Describe these to your testers as "what to verify in Oracle Fusion," not as legal advice: confirm the current thresholds, deadlines, and file specifications against the relevant authority's own guidance rather than hard-coding numbers into your test plan, because those details change independently of Oracle releases. The module specifics for 26C are tracked on the 26C Payroll changes page.
CX changes
If you run Oracle's CX applications, quarterly changes typically touch service flows, configuration of guided processes, and the increasingly agent-assisted parts of case handling. The testing priorities mirror the rest of the suite: re-validate any Redwood-migrated CX pages against your automation, confirm that integration points to CPQ, order management, and Financials still exchange data cleanly, and give any AI-assisted response or routing capability the same outcome-envelope and human-checkpoint scrutiny you apply to agents elsewhere. As always, scope this to the CX capabilities you actually license and confirm the details against Oracle's 26C readiness material.
REST APIs & integrations
Integrations are where a quarterly update can break something you did not touch. A changed REST resource, an altered payload field, a newly required attribute, or a versioned or deprecated endpoint can silently break a middleware flow, a downstream system, or a partner integration — and because these run outside the Fusion UI, they are easy to miss in a UI-focused regression pass. When reading 26C, list every REST resource your integrations consume and check each against the release for changes or deprecations.
The right test here is a contract test at each integration boundary: send representative inbound and outbound payloads and assert that the structure, data types, and required fields still match what your middleware and downstream systems expect. Do this in a non-production pod that has already taken 26C, before your production window. Keep an inventory of integration boundaries as a living artefact so that each quarter you are re-checking a known list rather than rediscovering your own interfaces.
Configuration changes
Some of the most dangerous changes are the ones with no visible feature: a changed default, a new profile option, or a setup task that alters behaviour once enabled. Because these do not announce themselves in the UI, the reliable way to catch them is to compare configuration before and after the update in a controlled environment and investigate every delta. A default that flipped can change how a process behaves for every user without anyone consciously turning anything on.
Practically, snapshot the relevant setup and profile options in your test pod before applying 26C, apply the update, snapshot again, and diff. Anything that changed and was not something you deliberately enabled deserves a specific test. This is tedious by hand, which is exactly why a repeatable comparison is worth building into your process; it is also the kind of drift detection that a disciplined readiness workflow should include every quarter, not just when something breaks.
Security & roles
Quarterly updates frequently adjust seeded roles, add privileges, or change data-security predicates. The risk is two-directional: a change can quietly grant access that breaks your segregation-of-duties posture, or it can revoke access and block users from doing their jobs on day one. Both are release-day incidents you want to catch in testing. Review any security-related notes in 26C, and pay special attention to seeded-role updates because most organisations inherit at least some seeded structure.
Test this by re-running your role-provisioning scenarios for representative user personas and confirming that each persona can do exactly what it should and nothing it should not. Re-run your segregation-of-duties checks against the post-update role definitions, because a new privilege bundled into a duty role can create a conflict that did not exist before. Where agents now act on behalf of users, extend the same scrutiny to the effective permissions under which those agents operate.
Deprecations: how to find and handle them
Deprecations are the changes with the longest fuse and the sharpest surprise. Oracle typically announces that a feature, screen, or API will be removed some releases ahead of the actual removal, which gives you time — but only if you are reading for it. In the 26C content, look specifically for language like "no longer available," "replaced by," "will be removed," and "deprecated," and treat each as a dependency-mapping task rather than a feature to test.
For each deprecation, ask: does anything we run depend on this — a report, an integration, a personalisation, a trained user habit? If yes, identify the replacement path Oracle provides and test it now, while the deprecated item still works, so you have a validated alternative before the removal lands. Maintain a small running register of announced deprecations and their target removal releases; it turns a future emergency into a planned migration. When in doubt about timing or scope, confirm against Oracle's official readiness documentation rather than relying on second-hand summaries.
High-risk business processes to prioritise
You will never have time to test everything, so prioritise by business impact. The processes below are the ones where a defect introduced by an update tends to be most costly — financially, operationally, or in compliance terms. Use this as a default ranking and adjust it to your own risk profile.
- Period close (Record-to-Report): any change to accounting, allocations, or the close sequence can delay reporting and cascade across entities.
- Procure-to-Pay: invoice matching, tolerances, approvals, and payment runs — now partly agent-assisted via the Payables agent — directly affect cash and supplier relationships.
- Payroll: calculation, costing, payment, and statutory file generation, with regulatory files verified against current authority guidance.
- Order-to-Cash: pricing, order orchestration, fulfilment, and billing, where errors hit revenue and customers.
- Tax and e-invoicing: determination and statutory e-invoicing (for example ZATCA), where mistakes carry regulatory exposure.
- Segregation of duties and critical access: role changes that could create SoD conflicts or block essential access.
- Agent decision boundaries: the escalation and human-approval checkpoints around any agentic process in scope.
A useful rule of thumb: a process earns top priority if a silent defect in it would either misstate money, block a payment, breach a regulation, or take more than a day to detect. Everything that clears that bar goes in your first testing pass; the rest can follow.
Suggested test approach + 26C test-plan checklist
Pulling the categories together, a dependable 26C readiness cycle runs in five stages. First, triage the release into the change categories above, scoped to your footprint. Second, map each tagged change to the business processes and test cases it touches. Third, prioritise using the high-risk list. Fourth, execute in a non-production pod that has already taken 26C — functional regression, agent scenario runs, integration contract tests, configuration diffs, and role checks. Fifth, sign off against evidence and confirm anything uncertain against Oracle's official readiness content. Give yourself enough runway inside the quarter to fix what you find before the production window closes.
The checklist below turns that cycle into a concrete, adaptable 26C test plan. Treat the "priority" column as a starting default and tune it to your environment.
| Area | What to test in 26C | Test type | Priority |
|---|---|---|---|
| AI & agents | A2A coordination chains; expanded agentic apps; human-approval and escalation boundaries. | Scenario-based / outcome envelope | Critical |
| Financials | P2P and R2R end-to-end; matching tolerances; tax; period close; Payables/Ledger agent decisions. | Functional regression | Critical |
| Payroll | Full pay cycle; costing; statutory/third-party output files vs. current authority specs. | Functional regression | Critical |
| Redwood UI | Migrated/restyled pages: flow completion, selector resolution, personalisations. | UI / automation regression | High |
| SCM | Order-to-cash, plan-to-produce, costing and inventory valuation flow-through to GL. | Functional regression | High |
| REST APIs | Every consumed resource: changed payloads, required fields, versioning, deprecations. | Integration / contract test | High |
| Configuration | Before/after diff of profile options, defaults, and setup tasks. | Config comparison | Medium |
| Security & roles | Seeded-role updates, new privileges, data-security predicates, SoD re-check. | Access / SoD validation | High |
| Deprecations | Dependencies on announced removals; validate replacement paths early. | Dependency mapping | Medium |
| CX | Service flows, guided-process config, integrations, AI-assisted routing envelopes. | Functional / scenario | Medium |
This is a framework, not a substitute for the module detail. The specific items that land in each row depend on your configuration, which is why the on-site 26C release-intelligence pages and Oracle's official readiness content are the authoritative sources for the "what," while the checklist above governs the "how." Where you want the mapping from release change to test case automated and repeatable, SyntraFlow's quarterly patch testing and regression testing capabilities can be configured to run the functional and UI passes described here, and the broader Oracle ERP testing platform ties them together.
Get the 26C test plan as a working template
The checklist above is available as a fuller, editable Oracle 26C test plan — the change-category triage grid, the high-risk process ranking, and the area-by-area test matrix, structured so your team can drop in your own modules and coverage. SyntraFlow does not host it as a public download; request it and we will walk you through it on a short call so it fits your environment. Ask for the Oracle 26C test plan via a demo and we will tailor it to the modules and integrations you actually run.
Prepare now for 26D
26D is Oracle's next quarterly update and has not been released, so there is nothing specific to test in it yet — but the readiness discipline you build for 26C is exactly what makes the next update routine. The single best preparation is to keep the artefacts you create this quarter alive: your change-category triage grid, your integration-boundary inventory, your deprecation register, your configuration snapshots, and your prioritised process list. When 26D's readiness content appears, you will be re-running a known process against a new release rather than starting over. Watch Oracle's official readiness home for the 26D "What's New" when it publishes, and confirm details there rather than acting on any early speculation.
How SyntraFlow helps
SyntraFlow can be configured to connect Oracle release intelligence with your test planning — correlating the quarterly change list with your process coverage, helping your team triage 26C into the categories above, and running the functional, UI, and regression passes those categories call for. It helps organisations assess the impact of each update and focus effort where the risk is, including the outcome-envelope validation and human-checkpoint checks that agentic changes such as 26C's A2A protocol demand. SyntraFlow does not replace Oracle's own AI, and it does not automatically test every scenario or guarantee coverage; it is a testing engine that makes a disciplined, repeatable readiness process practical quarter after quarter. Generate your Oracle 26C test plan with SyntraFlow — schedule a demo and we will map it to your environment.
Official Oracle references
Always confirm 26C specifics against Oracle's own documentation:
- Oracle Fusion Applications Readiness (What's New home)
- Oracle Fusion Applications AI
- Oracle Fusion AI — key capabilities
- Oracle Financials AI agents (documentation)