The wrong turn with no undo

Every Intune admin knows the moment: cursor hovering over Assign, knowing that if this change lands wrong there is no undo button. This page is about that moment — and what it actually costs.

You know the feeling before you click

It is a very specific feeling. The configuration profile is built. The assignment group is scoped. The cursor is over Assign. And then the question arrives, the one you never quite stop asking: if this is wrong, what exactly do I do?

Across most of a Microsoft Intune tenant, the honest answer is: unpick it by hand and hope. Remove the assignment, wait for devices to check in, verify each one, and try to work out whether the thing you just removed left anything behind. The community has been saying this for years:

"Intune is a labyrinth. Every wrong turn costs you, and there's no undo — you back out setting by setting and hope you found them all."
— r/sysadmin

The labyrinth is survivable when nothing is at stake. It stops being survivable the day the change touches two hundred laptops that belong to people with deadlines.

Wipe-and-hope: the community's recovery plan

Ask what to do when a device build goes sideways and the most common advice is not a rollback procedure. It is a reset: wipe the device, re-enrol it, see if the problem comes back.

That is not recovery. It is starting again and calling it recovery. The user loses a working day. You lose the afternoon shepherding the re-enrolment. And the change that caused the problem is still sitting in the tenant, unidentified, waiting for the next device to hit it — because a wipe tells you nothing about which of your changes was the wrong turn.

Wipe-and-hope persists not because anyone likes it, but because when changes are not designed to be reversed, a full reset is the only lever left.

A plan that declares its exits before you enter

Decolla approaches this from the other end: reversibility is decided before anything runs, not discovered after.

When you assemble a build — picking from a curated catalogue of 260+ industry-tested build items across 21 sections — the output is not an immediate deployment. It is an itemised written plan, and you read and approve it before anything touches a device. Every item on that plan shows two things:

• How it will be delivered — the mechanism that puts it on the device.
• Its reversibility class — auto (undone automatically), reverse (Decolla can back it out on demand), or irreversible, flagged plainly so you see it before you approve, not after it has run.

The wrong turns are marked on the map. If an item cannot be undone, you know that while your cursor is still hovering — which is when the knowledge is actually worth something.

Rollback that is honest about what it covers

Once a build has run, Decolla can roll back a single item or the whole build. Not by wiping the device — by reversing the specific changes it made, in your own tenant, against your own Intune and Autopilot estate.

The scope is deliberately narrow, and worth stating plainly: rollback covers Decolla's own changes only. It will not rescue a failed Microsoft application install, and it will not unstick an Enrolment Status Page — those run at Microsoft's pace, inside Microsoft's machinery, and no third-party tool can honestly claim otherwise. A rollback that promised more than that would just be wipe-and-hope with better branding.

What it does mean: when the wrong turn is one of yours — a policy, a script, a setting from the plan — there is a named, per-item way back that is not "rebuild the device".

For the person who signs off the risk

If you manage IT, you already know the real cost of a change is rarely the change itself. It is the recovery when it goes wrong — the wiped devices, the lost user-days, the not-knowing which of thirty settings did the damage. That risk sits with you, which is why sensible teams change less than they should, later than they should.

A written plan you approve first, with every item's delivery method and reversibility class in front of you, and a per-item route back for anything Decolla changed — that does not eliminate change risk. It makes it legible, bounded, and yours to accept on purpose.

Decolla is a product of The Cloud Platform, built out of years of doing this work in real tenants. It is in private build now. If changes-with-a-way-back is how you would rather run your estate, the early-access waitlist is where it starts.