HomeHow it works › Connect
How it works

Connecting your tenant

Granting a third-party tool access to your Intune tenant is a decision you own and will have to defend. Here is exactly what connecting Decolla means — what it can do, what it can never do, and how you take the access away.

What connecting actually is

Decolla does not stand up a parallel management plane, and it does not take custody of your devices. Your tenant remains the system of record: Intune applies configuration, Autopilot enrols hardware, and Microsoft's services run at Microsoft's pace, exactly as they do today.

Connecting means one thing: you authorise Decolla to call Microsoft Graph against your own tenant, through Microsoft's standard consent flow. Everything Decolla does after that — reading your existing setup during Discover, staging the items in your approved plan, running the deployment, rolling back its own changes — happens as Graph calls into your tenant, under permissions you granted and can withdraw.

Least privilege, in writing, before you consent

If a vendor has ever asked you for Directory.ReadWrite.All in the name of keeping the integration simple, you already know the feeling — that is usually the moment the evaluation should have ended.

Decolla publishes its full list of Graph scopes before you connect — the actual list, not a summary or a category description. You can read it, hand it to your security reviewer, and map every scope to the work it exists to do, before anything is granted.

This is not a promise you have to take on trust. Microsoft's consent model enforces it: if a permission is not on the list you consented to, Decolla does not have it, and no Graph call can exceed it.

No passwords change hands

You never hand Decolla a password. Consent is granted through Microsoft's own flow, and the resulting tokens are the only credentials involved — issued by Microsoft, scoped to the permissions you approved, and useless beyond them.

That is the design doing the work: there is no admin credential of yours for a third party to hold, because you never created one. What exists is consent — and consent is yours to withdraw at any time, which is what the next section is about.

Disconnecting is yours, not ours

There are two ways out, and the more important one does not involve us.

You can disconnect from within Decolla. But you can also revoke consent directly in your own Microsoft Entra tenant, at any time, unilaterally — the same way you would cut off any application you no longer trust. Once you revoke, Microsoft stops issuing Decolla new tokens; any token already issued runs out on Microsoft's standard short-lived expiry — typically within about an hour — and with it, the access ends. There is no long-lived back door and no "contact support to offboard" step.

What you deployed stays yours. Build items delivered through your Intune tenant remain your tenant's configuration after disconnection, managed like anything else in it. While connected, you can roll back per item or per build — Decolla's own changes only.

What Decolla can never touch

Boundaries matter more than features when you are the one who owns the risk, so here are Decolla's, stated plainly:

If you are the person who signs this off

Decolla is a product of The Cloud Platform, a working UK IT consultancy — an organisation that has sat on your side of this decision, evaluating other people's tools and other people's scope requests. The consent model above is the one we would want to be shown ourselves: the full scope list before connection, a consent flow that never puts your password in our hands, and a disconnect path that does not depend on our cooperation.

Decolla is currently in private build, and early access is by waitlist. When your invitation arrives, the scope list will be waiting for you to read before you connect. We built it expecting you to.

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