Rollback & reversibility
Every item in a Decolla build plan declares how it is delivered and whether it can be undone — before anything runs. Rollback covers Decolla's own changes, per item or whole build, and the limits are stated plainly.
Undoing a change is the hard part
Deploying a change to a fleet is rarely the difficult bit. Undoing one is. Anyone who has unpicked a mis-scoped configuration profile, or chased an application conflict back through three weeks of changes, knows the real cost of a bad change is the untangling.
Most provisioning setups make that worse. The record of what was applied lives across a dozen Intune blades, a shared OneNote and the memory of whoever built it. By the time something needs to come back out, you are reconstructing the change before you can reverse it — and if you are the person who owns the risk, you are doing it under pressure.
Decolla is built on a different assumption: you should know, before anything runs, exactly what can be undone and what cannot.
Three classes, declared before anything runs
Every item in a Decolla build plan carries two declarations: how it is delivered, and what happens if you change your mind. The reversibility class is one of three:
- Auto — changes Decolla handles automatically. There is no manual rollback step for you to carry out on these.
- Reverse — changes Decolla can take back out on request: policies it created, applications it installed, settings it applied.
- Irreversible-flagged — actions that cannot be undone by any tool, honestly labelled as such. These are flagged in the written plan, in advance, so you approve them with your eyes open rather than discover the consequence afterwards.
The classes sit in the itemised plan you read and approve before deployment — not buried in documentation you would have to go looking for. If a build contains a one-way action, you see it at approval time, in writing.
What a rollback actually does
Rollback is scoped to the plan you approved. Every reversible item can be taken back out on request, and you can roll back a single item or the whole build: Decolla undoes its own changes — the policies it created, the applications it installed, the settings it applied.
Because rollback is itemised the same way the plan was, undoing a change is not an archaeology exercise. You are not reconstructing three weeks of edits across a dozen consoles before you can reverse one; you point at the item in the plan and take it back out.
And because the plan is written down, the change record is not in anyone's head. It is an artefact you can read — and point to when someone asks what changed.
What rollback will not do
Rollback covers Decolla's own changes. Only those. It is worth being precise about this, because provisioning tooling has a history of implying otherwise.
- It will not rescue a failed Windows or application install at the Microsoft layer. Installs run at Microsoft's pace and fail at Microsoft's layer; no third-party tool can honestly claim to reverse that.
- It will not unstick an Enrolment Status Page. ESP belongs to Microsoft, not to Decolla.
- It will not reverse changes made outside Decolla — by other admins, other tools or users. If Decolla did not make the change, it does not pretend to own it.
- It will not undo an irreversible-flagged action. That is the point of the flag: it tells you before you approve, not after.
A rollback claim that covered everything would be a claim you could not trust anywhere. The scope is narrow because narrow is what is true.
A worked example: three items from one plan
Take three items as they would appear in an approved plan:
| Plan item | Class | On rollback |
|---|---|---|
| Power configuration policy (laptop chassis) | Reverse | Decolla removes the policy it created. |
| Line-of-business application install | Reverse | Decolla removes the application it installed. |
| Secondary drive repartition (drive strategy) | Irreversible-flagged | Nothing — and the plan said so before you approved it. Repartitioning destroys data; no tool can roll that back. |
The first two are ordinary rollbacks: item-level, and limited to what Decolla itself changed in your tenant. The third is the one that matters. Decolla will not present a one-way action as quietly reversible, and it will not hide the flag in small print. It sits in the same itemised plan, at approval time, where the person signing off can see it.
Written for the person who carries the risk
If you own the consequences of a build, the questions you ask are not about features. They are: what exactly will this change, can I get it back out, and will I find out about the dangerous parts before or after they run?
Decolla's answer is structural, not reassuring copy: an itemised written plan before anything runs, a reversibility class on every item, rollback per item or whole build for the changes Decolla makes, and a flag on every action that cannot be undone. All of it in your own Microsoft Intune and Autopilot tenant, all of it limited to what Decolla itself changes.
Decolla is in private build, from The Cloud Platform — a working UK IT consultancy that has had to answer those questions for real. If you would rather read a plan than reconstruct one, the early-access waitlist is open below.
See it on a real device.
Decolla is in private build — early-access members see a build defined, deployed and rolled back first.
Get early access