The written plan

Nothing runs until you have read, line by line, exactly what Decolla intends to do in your tenant — and approved it. Here is what that plan looks like.

Why a plan at all

Every IT manager has a story about a tool that "just needed a service account" and then quietly rewrote half the tenant. The pattern is always the same: broad consent up front, opaque actions afterwards, and you find out what actually changed when something breaks.

Decolla is built the other way round. The wizard's output is not a deployment — it is a document. An itemised, human-readable plan of every change Decolla proposes to make in your Microsoft Intune tenant, with the parameters it will use, the mechanism it will use to deliver each item, and an honest statement of whether each change can be undone. Deployment is a separate, deliberate step that only happens after you approve that document.

If you have ever run a dry-run before an apply, or read a change request before it reached a CAB, the shape will feel familiar. That is deliberate. You own the risk in your tenant; the plan is how you exercise that ownership without reverse-engineering someone else's automation.

What an example plan looks like

Suppose you have run Discover for a fleet of new Windows laptops from a single OEM, corporate-owned, standard user-driven Autopilot. The plan you get back is a flat, numbered list. A representative slice:

Every line answers the three questions a sceptical reviewer actually asks: what is being changed and with what values, how it lands (a policy, a configuration profile, a packaged app, a script), and what happens if I regret it. The reversibility classes shown here are illustrative — your own plan states the class Decolla assigns to each line.

The reversibility badge, honestly defined

Each item carries one of three classes:

• Auto — no manual rollback step is needed from you for items in this class; unwinding them is not your job.
• Reverse — Decolla can cleanly remove or restore this change on request, per item or as part of a whole-build rollback.
• Irreversible — flagged — the change cannot be undone by removing what Decolla added. Disk encryption decisions and drive layout are the obvious examples. These items are visually flagged in the plan precisely so you cannot approve one by accident.

Two boundaries worth stating plainly, because vendors tend to blur them. First, rollback covers Decolla's own changes only. If a Microsoft app install fails or an Enrollment Status Page hangs, that is Microsoft's machinery, and no rollback button changes that — Decolla will not pretend otherwise. Second, nothing in the plan claims to make Microsoft's side faster. Installs, sync and ESP run at Microsoft's pace. What the plan compresses is the part that used to cost you weeks: assembling, testing and sequencing the 260+ items in the first place.

The items that are not there

A catalogue of 260+ items would make for an unreadable plan if every build got all of it. It does not. Decolla's conditional engine filters the item set against what you declared in Configure — platform, chassis, scenario and make — so the plan you review contains only the items that are relevant to the fleet you actually described.

Declared a desktop fleet? Battery and lid-behaviour items never enter your plan. Declared an existing tenant rather than a greenfield one? The item set is filtered to suit that scenario too. The result is a plan that is all signal: every line is there because your declared context calls for it, and the document you approve is the set of what will run — nothing more.

This is also where the plan earns its keep as a review artefact: your security lead can read the same document you did, object to line 14, and you can amend the build and regenerate the plan before anything has touched the tenant. On Graph permissions, the same principle applies — the scopes Decolla requests are published in full before you connect, so the access review can happen on paper too.

The plan as your audit artefact

Approval is explicit. You read the plan, you approve it, and only then does the deployment run — unattended, in your tenant, doing exactly what the document said and nothing else.

That document then outlives the build. When an auditor, a new team member or your own future self asks "what did we change on those devices and who signed it off?", the answer is not a scroll through the Intune audit log trying to reconstruct intent. It is the plan: the itemised record of what was proposed, what was flagged irreversible, and the fact that you approved it before execution. Change control for device provisioning, without the ceremony of writing it all up yourself.

It comes from The Cloud Platform Ltd, a working UK IT consultancy — which is to say it was shaped by people who have had to answer that auditor's question themselves.

Decolla is in private build. If a plan you can read before anything runs sounds like how provisioning should have worked all along, the early-access waitlist is open below.