AI Assistant Approvals: Decide What It Can Do Before It Acts

1. Give each action its own rule

Start with a short action list for one workflow. Name the allowed records, the person responsible and what happens when that person is unavailable. Keep existing account permissions in force; an assistant should not expose a record that the employee cannot otherwise access.

For a first implementation, a sensible acceptance scope can stop at reading and drafting. If a routine action will later run without individual approval, define its permitted inputs, affected records, limits and stop conditions separately. Do not let one approved example become permission for every future request.

2. Approve the change you can actually inspect

An approval should describe the proposed operation in business language. Use this review record during a demonstration:

• Target: the named system and exact customer, job, task or recipient identifier. Similar names need disambiguation.
• Change: current value and proposed value, or the full message with recipients and attachments. Show date, time and time zone when scheduling is involved.
• Basis: the source record, source revision or last update, plus any unresolved assumption.
• Effects: what will be saved, sent or notified, and what this operation leaves for a separate decision.
• Authority: the person allowed to approve, the scope of this approval and when it becomes invalid.
• Confirmation: the evidence that will show whether the intended change happened.

If the recipient, body, attachment, date or target record changes after review, show the new proposal and obtain a new approval. If the source changed while the proposal was waiting, recheck it before acting. A preview of yesterday's job status is not a reliable basis for today's commitment.

Instructions inside an email or document are source material. They must not grant permission to send a reply or bypass the business's review rule. Test that distinction with synthetic content before connecting private records.

3. Walk through one office-to-field handoff

This is an invented training example, not a customer project, a RAW product demonstration or a claim of an available integration. A fictional request, EX-104, asks whether a crew can return on Tuesday afternoon. The job note says an office employee must confirm crew availability.

1. Read the request. The assistant retrieves the approved request and note. It reports that availability is unconfirmed. It does not turn the customer's preferred time into an appointment.
2. Prepare two separate proposals. One is an internal task for the office to check availability. The other is a draft reply saying that the request is being reviewed. Neither creates a calendar booking.
3. Approve only the task. The employee verifies EX-104, the task owner and due date, then approves that save. The reply remains a draft. The request remains unconfirmed.
4. Inspect the result. The assistant supplies the saved task identifier and a link to the task. The employee can verify that one task exists with the reviewed fields.
5. Handle the later decision separately. When the office confirms availability, it reviews the precise appointment and customer message. The earlier task approval supplies no authority to send or book.

The useful output is not simply “done.” It is a small set of states: task saved and verified; reply still a draft; appointment not confirmed. Those distinctions help the next person avoid acting on an assumption.

4. Treat an uncertain result as unfinished work

Suppose the task system saves the new task but the connection drops before the assistant receives confirmation. A second click must not blindly create another task. The implementer needs a way to check the original operation, recognize a duplicate attempt and return the existing result where the target system supports that behavior.

Ask to see an operation record with the request identifier, reviewed revision, approver, attempted action, time, target result identifier and current status. Useful statuses distinguish prepared, approved, attempted, confirmed, failed and outcome unknown. They should describe evidence, not the assistant's confidence.

When the outcome is unknown, stop automatic retries and have a named operator reconcile the destination. If the destination cannot support reliable duplicate detection or result lookup, keep that action manual until there is an acceptable operating procedure.

Even a provider's positive response may mean less than the user expects. Microsoft's Graph sendMail documentation says its 202 response accepts a request without establishing completed processing or delivery. For a workflow that uses that API, “request accepted” and “message delivered” need different evidence. This is a provider example, not a statement that RAW offers automated email sending.

Define recovery before rollout. A saved internal note may be correctable with an audit record; a message already read by a customer cannot be made unread. Ask what can be reversed, who handles corrections and how employees pause the connection.

5. Ask for five small acceptance tests

Run these with fictional records in an approved test environment. A screenshot of an approval button does not establish the behavior.

1. Reject the proposal. Confirm that no destination record changes and no notification is sent.
2. Change a reviewed field. Replace the intended task owner or recipient after approval. The changed operation must require a fresh review.
3. Approve one action in a bundle. Save the internal task and verify that the reply and calendar request remain untouched.
4. Repeat the approved request. Simulate a lost confirmation. Show how the operator finds the existing action or an explicit unknown outcome without creating an unexplained duplicate.
5. Remove access or change the source. The pending operation should stop and explain what needs review, rather than proceed on stale authority.

Record the expected result, observed destination state and any manual step for each test. Accept only the demonstrated scope. The integration readiness checklist covers the earlier question of whether the assistant can reliably obtain the right information.

Bring one action you want help with

Write down the trigger, required information, proposed change, allowed approver and consequence of getting it wrong. Bring a fictional example and the names of the systems involved. That is enough to start an informed discussion without sharing customer records.

Explore RAW's automation and integration services or watch the public RAW Business Workspace demonstration. The demonstration shows a particular workflow with review steps; the acceptance tests in this guide are evaluation criteria, not a claim that every connected system or automated action is currently supported. Confirm the exact configuration and action boundaries during scoping.

Microsoft documentation checked October 25, 2026. Confirm current behavior for the provider and account selected for the actual project.