A Java Approval Workflow for New Deployments.

Why approval matters more than it sounds

An approval workflow has a modest job with an outsized payoff. By asking a few questions before any new Java deployment goes live, it ensures that Oracle Java is only ever used where it is genuinely needed, and that every runtime in the estate has a recorded owner and reason. That record is exactly what an Oracle audit asks for, and exactly what most organizations cannot produce under deadline.

The reason this matters now is the metric. Since January 2023 Oracle has priced Java SE on the Universal Subscription, a per employee charge of 5.25 to 15.00 dollars per employee per month that counts every full time and part time employee, every contractor, and every temporary worker, regardless of who uses Java. With LMS audits running a three year lookback in 2026, the question is rarely whether you can pay, but whether you can prove what you deployed and why. An approval workflow builds that proof continuously.

What a good workflow asks

The workflow should be short enough that teams use it willingly and rigorous enough to capture what matters. For each new deployment it records the system and its owner, the Java runtime requested and its vendor, whether a free OpenJDK distribution would serve instead, and, if Oracle Java is genuinely required, the specific reason and the approver who signed it off. That is the whole gate. It takes minutes and produces a permanent, auditable record.

The default answer is the free distribution

The workflow only earns its keep if the default is right. In almost every case the approved free OpenJDK distribution serves the need with no functional difference, so the gate should treat Oracle Java as the exception that must be justified. When a request for Oracle Java arrives, the first question is whether the free distribution would work, and the burden sits with the requester to show why it would not. This single design choice keeps unbudgeted Oracle Java out of the estate while leaving room for the rare workload that truly needs it. It pairs naturally with controlling Java downloads across the organization, which enforces the same default technically.

A workflow at a glance

An illustrative approval flow

Step	Question	Outcome
Request	What system, which owner, which runtime?	Logged with an owner
Default test	Would the approved free distribution serve?	Most requests resolve here
Exception	If Oracle Java is required, why?	Reason recorded
Approval	Named approver signs the exception	Accountable decision
Record	Entry added to the inventory	Audit ready evidence

Indicative only. Adapt the steps to your change management tooling. The aim is a gate measured in minutes that produces a record measured in years.

Keeping it light enough to survive

Approval workflows die when they become bureaucracy. The fix is to make the compliant path the fast path. If a deployment uses the approved free distribution, approval can be near automatic, recorded but not delayed. Only the Oracle Java exception triggers a human decision. Teams accept a gate that rarely blocks them and rejects almost nothing they actually need. Over time the workflow becomes the place where the estate documents itself, which is what makes the next audit a confirmation rather than an investigation.

The same record also feeds your population defense. When you can show that Oracle Java is confined to a named set of approved systems, you have firm ground to argue that the rest of the workforce, and the rest of the estate, should not sit inside a population sized claim.

Standing it up

1. Define the gate. A handful of questions, no more, capturing owner, runtime, and reason.
2. Set the default. Make the approved free distribution near automatic and Oracle Java the justified exception.
3. Name approvers. Give the Oracle Java exception a real, accountable decision maker.
4. Wire it to the inventory. Every approval writes an entry, so the record builds itself.
5. Review the exceptions. Revisit Oracle Java approvals each quarter to see whether they still need it.

Where the workflow fits in change management

The approval gate should not be a separate queue that teams resent. It belongs inside the change and provisioning processes you already run. When a new server is requested, a new service is stood up, or a build pipeline is created, the Java question is asked at that moment, as one field among many, rather than as a special errand. Folding it into existing workflow is what keeps it alive, because nobody has to remember a parallel process. The output, a recorded runtime decision with an owner, simply becomes part of the standard record for every new system.

This placement also catches the deployments that matter most. New systems are where Oracle Java most often enters by accident, so a gate at the point of provisioning intercepts the problem before it becomes an installed fact that someone later has to discover and unwind.

What to do with the exceptions you accumulate

Every approval workflow produces a growing list of Oracle Java exceptions, and that list is an asset if you use it. Reviewed each quarter, it answers a question that directly shrinks exposure: does this system still need Oracle Java, or has the dependency that justified it gone away? Workloads change, vendors certify their software on free distributions, and components are retired. An exception that made sense a year ago may now be a candidate to migrate, which moves another system out of your genuine Oracle Java footprint. The workflow gathers the exceptions, and the quarterly review turns them back into migration opportunities rather than permanent commitments.

Treated this way, the approval record becomes the spine of your residual. When a claim arrives, you can show not only which systems use Oracle Java but that each one is reviewed, justified, and continually tested against the free alternative. That is a far stronger position than an estate where Oracle Java simply accumulated.

Questions about the approval gate

Does this not add bureaucracy?

Only where it should. The compliant path using the free distribution can be near automatic. The human decision is reserved for the Oracle Java exception, which should be rare.

Who approves the exceptions?

A named owner with the authority to say no, usually the Java governance owner, so that an exception is a real decision rather than a rubber stamp.

What if teams route around it?

That is why the gate lives inside provisioning and is reinforced by download controls. When the compliant path is also the easiest path, routing around it stops being worth the effort.

How a buyer side advisor helps

Most organizations can stand up governance themselves, and the controls described here are deliberately practical. Where an independent buyer side advisor adds value is in calibration and timing: knowing which evidence an LMS reviewer actually weighs, where Oracle's opening number is softest, and how to turn a clean estate into a smaller defended residual. We sit between you and Oracle and we never take vendor money, so the advice points one way only.

We work two ways, both built so the risk sits with us. A Fixed Fee starts from $18,000, agreed up front and backed by our guarantee. Or you can choose Gainshare, a share of verified savings or avoided exposure, with zero retainer and no risk to you. Across the work we do, we have defended more than $120M in Java exposure and over 300 Java audits, with more than 20 years of combined experience on the buyer side of the table, and an average reduction of 68 percent versus Oracle's opening number.

Where to go next

An approval gate works best alongside the other governance pillars. Combine it with a standing Java governance function and a usage policy that holds, and ground the whole approach in our Oracle Java licensing guide for 2026. Make every deployment a decision and the estate stops surprising you.