Running the platform¶

This is the day-to-day loop: a ticket becomes a plan, you review it, and the platform executes it. Every stage is visible in the Portal.

Intake ─▶ Tenant resolution ─▶ Plan generation ─▶ Human review ─▶ Execution ─▶ Status back to PSA
 (auto)       (auto)            (async job)        (you)         (async job)      (auto)

1. Intake and tenant resolution¶

A ticket enters from a connected PSA, the intake API, or direct entry. The platform normalizes it and resolves it to a managed tenant using the requester's domain and other hints. Only tickets that resolve to a single onboarded tenant proceed; the rest are held so nothing acts on an unknown or ambiguous target.

2. Generate a plan¶

From the ticket, you generate a plan. The AI reads the live tenant — existing users, groups, licenses, mailboxes — and constructs the operations that satisfy the ticket, resolving names and references into concrete targets.

Because a complex ticket can take several minutes to plan, generation runs as a background job. You submit it and the Portal shows progress until the plan is ready. You don't wait on a frozen screen, and you can come back to it.

The AI builds; it does not pick from a menu

The plan is constructed for this ticket against this tenant. That's why it can handle "same access as Jane" or "add the new hire to the Sales team" — it resolves those into real object IDs and real operations, or tells you plainly when it can't.

3. Review — the decision that matters¶

Open the plan in the Queue. You see:

The AI's reasoning, assumptions, and warnings, and its confidence.
Every proposed operation in order, with its risk level and dependencies.
For anything that runs in the customer tenant, the literal cmdlet and parameters that will execute — not a vague summary.

You then:

Approve — the plan becomes eligible to execute.
Deny — nothing runs.
Request clarification / hold parts — see the held-work loop below.

This review is the safety mechanism

There is deliberately no fixed allow/deny list of cmdlets. The platform's safety guarantee is that a human sees the exact operations and approves them first. Read what you're approving.

Held work and partial solves¶

A ticket often has parts that are clear and parts that need confirmation ("grant access to the Sales shared mailbox" without saying which one). You can action the clear parts now and hold the rest. The ticket stays open with a worklist of held items; when you get the missing detail, you instruct just that part and the AI re-plans only it. What already ran is left untouched.

Leaving a held part blank keeps holding it. Typing the detail re-plans that part.

4. Execution¶

Approved plans execute as a background job, one operation at a time, in dependency order. The Portal shows each step move through queued → running → succeeded (or failed / partially succeeded), with per-step evidence.

Dependent steps are skipped if the step they depend on fails, and the Portal tells you why.
Transient Microsoft propagation lag (a just-created object not yet visible everywhere) is handled automatically: the affected step is deferred and retried later in the run rather than failing the whole plan.

5. Status back to the PSA¶

When execution finishes, the outcome posts back to the originating PSA ticket as a status update / comment, closing the loop for whoever raised it.

Recovering a run¶

Three different situations, three different tools:

Situation	What to use
A step failed because of something you fixed externally (a permission, a config) and the plan is still correct	Retry — re-runs the failed operations of the same job.
The ticket changed, or you want a clean slate for this ticket	Reset / Start over — returns the ticket to a fresh, re-plannable state without deleting the audit history.
The plan itself is wrong and the failure is something the AI can correct	Regenerate / re-plan — the AI proposes a corrected revision, which you review and approve like any other plan.

Reset and retry never destroy the record of what happened — the audit trail stays intact.