Skip to content

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.

'Awaiting confirmation' is not a failure

Some M365 operations finish asynchronously on Microsoft's side — a Purview policy teardown, a mailbox/archive change — and can take longer than the platform's per-operation time limit. When that happens the platform does not call it Failed: it records the step as Indeterminate — awaiting confirmation (it was issued, but the outcome couldn't be confirmed in time), and it deliberately does not re-run it (re-running an unconfirmed change risks doing it twice). The PSA write-back says "awaiting confirmation," not "Failed." If you see this, check the actual end state in the tenant — the change has usually landed.

5. Status back to the PSA

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

  • By default this is a concise technical note (what ran, the outcome, the counts) — free, no AI.
  • At approval you can tick "include an AI summary in the write-back" to post a client-facing, plain-English summary of what was done instead of the technical note (this spends tokens).
  • Any time after a run you can post to the PSA on demand from the ticket or the execution view — either the technical note or an AI summary — without re-running anything.
  • If a ticket was answered by reading alone (the AI resolved a question — "where is this file?" — with no changes to make), there's nothing to execute; you can relay that answer straight to the ticket for the requester.

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.

Keeping track of work

Across a busy board with many queues, two tools help you not lose a ticket:

  • Follow a ticket (the star) to pin it to your personal Following panel — a slide-out reachable from any page that shows the live stage of every ticket you're tracking. It's per-operator; what you follow is yours.
  • Escalate a ticket (the flag) to raise it into a shared Escalation queue with an optional reason, so the team can see it needs attention. Escalation is shared across operators; de-escalate when it's handled.

You can also open any ticket directly by its link (/tickets/<id>) — useful for sharing or for a notification that points straight at the ticket that needs you.