Station 9 of 10
Extensibility and quarterly updates in Oracle Fusion
What you leave this station with
Knowing where configuration stops and code starts, and building the habit of reading the quarterly update document before it lands rather than after.
Station eight stopped at the product’s edge in front of the state. This one is about its edge in front of you.
Start from the fact that governs everything after it: the update is not a decision. Oracle ships four updates a year to Fusion cloud applications — named for the year and the quarter, 26A, 26B, 26C and 26D — and no customer may refuse one. One version for everybody, and deferral is not on offer.
That inverts the meaning of customisation: the question is not “can I do this?” but “what happens to what I did, four times a year?”
The four-rung ladder
The rule at this tier is the rule in every enterprise cloud: do not climb a rung before proving the one below it will not do.
| Rung | What is on it | Effect of an update |
|---|---|---|
| 1. Configuration | Setup tasks, approval rules, subledger accounting rules, tax rules | Always survives |
| 2. Flexfields | Extra fields defined inside the product’s structure rather than outside it | Survives, and its screens are tested |
| 3. Extension in a sandbox | Page and layout changes inside a container published after testing | Usually survives, needs testing each quarter |
| 4. Code and integration | Web services, external integrations, bulk loads | Entirely yours, and an interface change breaks it |
Rung one is far wider than somebody arriving from smaller systems assumes. Most of what a typical Gulf project asks for — a different account under a given condition, an extra approval level, a specific tax treatment, a field on the invoice — sits entirely on rungs one and two.
Keep the sentence that compresses this station: most of what gets requested as code is a rule nobody knew about. You saw it in station seven: the account that “must be changed programmatically” is an account rule written in an hour.
The sandbox — the most important discipline instrument
Interface changes are made inside an isolated container, tested, then published.
Its value is administrative rather than technical: it is what makes “who changed this screen, and when” a question with an answer. A team editing the live environment directly loses that answer within three months, and every quarterly update then becomes a jump in the dark, because nobody knows what to test.
The discipline that works: one container per change request, a written record of what is in it, and deletion after publication. Many containers left open for months is the first shape of coming disorder.
What this policy does to a running budget is in the Oracle Fusion Cloud ERP guide.
Integrations — where the real bill is paid
Rung four is what costs, and its first day is not the expensive part.
An integration is built once and maintained for twelve years. Every integration added today is a permanent line on a test checklist run every quarter, forever.
Four questions before building any of them:
- What breaks it? An interface change, a new mandatory field, a data model change.
- Who finds out it broke? If the answer is “the customer, when a transaction fails”, the monitoring is missing.
- What is the manual fallback while it is down? The one with none stops the business.
- Who owns it after the partner leaves? The honest answer goes in the contract rather than in a meeting.
The quarterly update habit
This paragraph separates a mature team from the rest, and the habit is three steps.
One: the “what’s new” document is read before the update lands, not after. Oracle publishes one per module per quarter and it takes an hour. Read it beforehand and you plan; read it afterwards and you explain.
Two: the test environment goes first, against a fixed written checklist. The checklist is the working cycles you built in stations four to seven: a full purchase, a full sale, a miniature close, a printed tax invoice, and every live integration.
Three: what changed and what needs training is documented. Most post-update user complaints are not faults. They are a screen that moved with nobody told.
Four times a year means that checklist runs four times. Automate it in year one and you spare your team twelve years; leave it manual and you have created four extra weeks of work every year.
What you actually do in this station
- Open the latest financials “what’s new” document and read it through once, then summarise in half a page what matters to a Gulf customer.
- Take five realistic change requests and classify them on the four rungs. Four of them will land on one and two.
- Write the update test checklist for your cycles, with steps and expected results.
- Draw one integration and answer the four questions about it in writing.
- Write a sandbox policy: who creates, who approves, when they are deleted.
The three commonest mistakes
One: jumping to code. An integration is built to solve what was a configuration rule, adding permanent maintenance to a problem that took an hour.
Two: ignoring the update document. The change is then discovered from a user complaint, which is the most expensive way to learn something published free a month earlier.
Three: open sandboxes with no register. Three months on, nobody knows what was changed, by whom, or what needs testing.
The acceptance test for this station
- Name the four rungs and the effect of an update on each.
- Classify five change requests on the ladder, and justify each one.
- Explain the sandbox as an administrative discipline rather than a technical tool.
- Show the update test checklist you wrote.
- Answer the four questions about one specific integration.
What comes next
You have the product and its limits. The last station turns that into income: certification and a first job — the exam by name, number, duration, pass marks and price, and what an interview actually asks.