Skip to main content
The Request Technician Approval tool enables the Technician-in-the-Loop workflow, requiring human approval before the agent takes certain actions.

​
What It Does

When enabled, the agent can:
  • Send an approval request to your configured technicians via Teams, or post it in a Teams channel or group chat where anyone can approve
  • Read the decision — approved, rejected or still pending — on a later step
  • Carry out the approved action
The tool sends the request and returns straight away, and it does not carry out the action it describes. To hold a write until a technician approves it, require approval on the write — see How to Use. Once the agent finishes its turn, the run waits for the answer, with no timeout: see If nobody answers.
Setup Required: Follow the Teams integration guide to allow Neo to ask approval in Teams.
An approver can use their own Microsoft Teams account from another directory after accepting an invitation to this workspace. See cross-workspace approvers.

​
How It Works

  1. Agent analyzes the ticket and determines an action is needed
  2. Agent prepares the action and explains what it wants to do
  3. A Teams message with approve/reject buttons is sent to the configured technicians, and posted in the configured channels and chats
  4. Technician reviews and makes a decision
  5. Agent proceeds or aborts based on the response

​
How to Use

This tool is automatically enabled when you enable “Require Technician Approval” on other tools like:
  • Execute RMM Script
  • Add Client-Facing Note
  • Microsoft Graph API writes, such as creating a user
  • And many others
It is also enabled on any agent that holds a write permission, so a high-impact write can still ask for a technician when you left approval off for that group. Pick the approvers on this tool — an agent with none has nobody to ask, and the request fails. To require approval before a write and still have that write happen, switch Require Technician Approval on for the write tool’s permission group. Neo then holds the write until a technician approves, and runs it. An approval request on its own leaves the action undone.

​
One approval for the same change to several records

When the agent makes the same kind of change to several records, such as correcting twelve memories or disabling five users, it reads the records first and then asks once. The approval card shows the agent’s summary, which names the records, and Neo stores the exact change for each record with the request. After you approve, each stored change runs exactly as stored, with no further check, and can be used again for the same change, for example when the agent retries after an error. A change that is not stored with the request, or that differs from it in any value that changes the call, needs a new approval. The one exception is a password or key in its own field: it is stored as a placeholder, so a change that sends a newly generated one still matches. Neo records each time a stored change runs. An approval with a note is checked the usual way, so your note is always read. For a single change, the agent writes the request as a summary without a list. A password or key in its own field of a stored change is kept as a placeholder. Neo recognises such fields by their names, as it does in the run’s step trace, so this is best effort. Neo refuses to list a change when it detects a secret anywhere else, such as a message that delivers a password it generated, and the agent describes that change in the summary instead. The summary and the name of each change are text the agent writes, and it is instructed never to put a secret in them.

​
Example Approval Message

Technician-in-the-Loop

Learn more about Technician-in-the-Loop

​
Best Practices

Have multiple technicians available to avoid delays when someone is unavailable.
Pick a channel or group chat in Teams channels & chats that can approve when a team shares approvals. Neo posts one card there, anyone in it can answer, and the first answer wins. See Approvals in a Teams channel or chat.
A request waits until someone answers it; there is no timeout, and the agent cannot wait inside the run to ask someone else. To bring in a second approver after a set time, have the agent schedule a check-back: see If nobody answers.
Guide the agent on when to seek approval vs. proceed autonomously.
A request asks a technician to approve changes the agent will make. When your rule leaves a choice open, such as two contacts that both fit, the agent proposes one and names the other, and the technician can pick the other in a comment. A review, a manual step for the technician, or a “flag for review” goes in the internal note; when your PSA has no review status the agent can set, that note is the flag. A triggered agent with no way to add a ticket note puts these items in its dashboard summary instead, and a chat agent puts them in its reply. To have the agent notify a technician through this tool anyway, say so in the instructions, for example: “When the company is not linked to a tenant, use Request Technician Approval to notify Joe.”
If your instructions give one approval wording for a specific end client and another for everything else, state each condition and keep the two texts apart. The agent writes only the branch whose conditions are met, in that branch’s own words, and does not name the other branch in the request — not as a heading, and not as a note saying it does not apply. The approver reads the request on its own, so a label from a branch that did not apply would tell them the wrong thing about what they are approving.
Regularly check what’s being approved to identify automation opportunities.