AirLock365 Operator Docs

AirLock365 turns a PSA ticket into a safe, reviewed change against a client's Microsoft 365 tenant.

A ticket comes in, the platform's AI reads it and constructs an action plan against that client's live directory, an operator reviews and approves it, and only then does the platform execute it against M365 through the delegated (GDAP) access you already hold.

PSA ticket ──▶ AI builds a plan ──▶ operator approves ──▶ platform executes ──▶ status back to the PSA
                     │                      ▲
              reads live tenant       the human gate
                 evidence            (the real safety line)

The one idea to hold onto

The AI reasons about the ticket and builds the change; it does not pick from a fixed menu of canned actions. That is deliberate — a keyword router could pick from a menu. The platform's value is that it resolves the ambiguity in a real ticket ("give Candice the same access as Jane", "add the new starter to the Sales team") into concrete operations against the actual tenant.

Because the AI constructs the change, human approval is the safety mechanism. Every plan is shown in full — including the literal PowerShell/Graph call that will run in the customer tenant — before anyone can approve it. Nothing touches a tenant without that review.

Where to go next

• Getting started — what you need and the shape of the work.
• Onboarding a client — GDAP, consent, and readiness.
• Running the platform — ticket → plan → approve → execute.
• Admin controls — notifications, users, guidance, lifecycle.
• Troubleshooting — the things that trip people up.