“Approved” and “done” are different things.

Permission is one step in the process

You review a proposed customer message and approve it. At that moment, you have given permission for a particular action. You have not yet been shown that the action succeeded.

The difference is easy to miss when a button immediately changes the label to “done”. It matters whenever an assistant takes actions in another system, where a connection can fail or a request can be rejected.

A useful workflow keeps the proposal, the decision and the outcome visible as separate stages.

Show what the approval actually covers

Before asking for a decision, show the details that would change that decision. For an outgoing message, that includes the sender, recipient and full content. For a record update, it includes the affected record and the proposed change.

“Handle the follow-up” is an instruction to prepare work. It should not be treated as open-ended permission for any future message about that customer.

• Which company does the action belong to?
• Which account or record will be used?
• What exactly will be sent or changed?
• Who is allowed to approve it?
• How long does the proposal remain valid?

If key details change after review, the workflow needs a fresh decision rather than carrying the old approval across to something different.

Give rejection a useful outcome

Approval screens should make declining an action straightforward. A rejected draft can stay visible with its status, leaving the reviewer free to revise the instruction or abandon it.

The point of a review step is not to make every request end in a yes. It is to put judgement where it belongs. An assistant asking for clarification at the right moment can be more useful than one that presses ahead with incomplete context.

For a pilot, agree what happens after a rejection. Does someone edit the draft? Is another proposal prepared? Does the task return to the owner? Define the next step so it does not vanish from view.

Check the external result

After approval, the execution step needs to confirm what happened in the connected system. A failed attempt should remain visible with enough information for the next action.

Retries need care too. If a connection drops after a request is sent, repeating it blindly could duplicate the action. The workflow should use an agreed method to identify an existing execution before trying again.

Customers do not need to read technical logs to understand the status. Plain labels such as “Waiting for review”, “Approved”, “Completed” and “Needs attention” are useful when they accurately reflect the underlying record.

Agree the boundaries before the pilot

List the actions in the first workflow and decide which need approval, which are read-only and what should stop for clarification. Then walk through a successful case, a rejected draft and a failed attempt.

This makes the expected behaviour concrete for both the business owner and the person building the setup. It also gives the pilot something specific to test.

AskMace’s example demo keeps these steps visible. The pilot scope defines the real permissions and available actions for your business; the demo itself does not execute anything.