Decide approvals
When your policy reserves an operation for a person, the agent's call waits on the Approvals page until an approver decides. This page is for approvers: what a request shows, how to decide it, and what happens next.
The Approvals page
Open Approvals. It shows the requests of the environment chosen in the sidebar, newest first, in two tabs:
- Waiting: every request that still needs a decision, however old.
- All: requests in every state.
The list loads more as you scroll down, and its end shows how many requests there are. Search finds requests by tool id, agent name, or the name of the person the agent acts for: every word must appear, in any case.
Each entry shows the tool id, its status, who the agent acts for and which agent asked (For … by …), when it was asked and, while it waits, when it expires. A request the customer has to confirm also says so. Click an entry to open its details beside the list.
Admins, approvers and auditors see the list. Only approvers and auditors of the environment can open a request's details, because the details contain the exact values the agent sent. An admin who isn't also an approver or auditor in that environment can't open them. Every time someone opens a request's details, it's recorded in the audit trail.
What a request shows
The details panel is built so you can judge the exact operation, not a summary of it.
| Part | What it tells you |
|---|---|
| Title and tool id | The operation, for example Create purchase order, with the tool id and tool version. |
| The values | The arguments that matter for this operation, such as the supplier, the order lines and the amount, as the agent sent them. |
| On behalf of | The person (or customer) the agent acts for. |
| Asked by agent | The agent that made the call. |
| Why approval is needed | The policy version and the rule that asked for approval, for example Policy v4, rule large-orders. |
| Who decides | An approver, the customer, or both. |
| Expires | When the request expires if nobody decides. |
| Exact arguments | Expand it to see every argument as JSON, with its SHA-256 hash. |
The coloured blocks next to the status are the request's fingerprint: a picture of the hash of the exact arguments, with the start and end of the hash beside it. The same fingerprint appears on the execution in Executions & audit, so you can check that what ran is what you approved.
Values are shown as Gatelion checked them: text is normalized, and decimals keep every digit. An amount of 1000.999 is shown as it is, never rounded.
Approve or reject
Add a Comment (optional) if it helps others understand your decision; it's kept with the decision in the audit trail. Then click Approve this operation or Reject.
Your approval covers exactly this operation with exactly these values. If the agent wants anything different, even one changed value, it has to ask again, and someone has to approve the new request.
A rejection is final. The agent is told the operation won't run.
When you can't decide
Sometimes the details open but the decision buttons don't appear. The panel says why:
| Message | Why |
|---|---|
| You asked for this operation, so someone else must approve it. | The agent acts on your behalf. |
| You own the agent that asked, so someone else must approve it. | You're the agent's owner. |
| You issued this agent's token, so someone else must approve it. | You issued the token the agent used. |
| You can see this request, but only approvers of this environment can decide it. | You're an auditor here, not an approver. |
| Only the customer can confirm this request. The agent gave them a link to a confirmation page. | The rule leaves the decision to the customer, on their own confirmation page. |
This is separation of duties: nobody can approve an operation they asked for or are responsible for. It's why an approval flow needs at least two people. If you're the only approver and you can't decide, ask an admin to make another person an approver in this environment.
For rules that need both the customer and your staff, you decide your part here, and the panel shows whether the customer has confirmed yet. A rejection by either side rejects the request.
Cancelled requests
Some changes mean a request can never run as it was asked. Gatelion then cancels it at once, so nobody spends time deciding it. The request shows as Cancelled, the decision buttons are gone, and the panel says "Cancelled by Gatelion, because it could no longer run:" followed by the reason:
| The panel says | Because an admin |
|---|---|
| The policy changed after the request. The agent has to ask again. | Saved a new policy version. |
| The tool changed after the request (a new API description). The agent has to ask again. | Re-imported the API description, and this tool changed. |
| The tool was switched off. | Switched the tool off, or re-imported a description without it. |
| The agent was stopped. | Switched the agent off. |
| The person it acted for no longer has access. | Removed that person's access. |
| Its Gateway was retired. | Retired the Gateway the request came through. |
This applies to requests still waiting and to approved requests that haven't started running yet. An approved request that has already started running isn't affected. The agent is told the request was rejected, with the reason, and has to ask again if it still needs the operation. See Approvals.
Expiry
A request that nobody decides expires 24 hours after the agent asked. An admin can choose another time for each environment on Settings, under Requests wait for approval for: 15 minutes, 1 hour, 4 hours, 8 hours, 24 hours, 3 days or 7 days. A new time applies to requests made after it's saved. An expired request can't be approved; the agent has to ask again.
Approval emails
When a request starts waiting, Gatelion emails every approver of the environment who could decide it. People excluded by separation of duties don't get the email. No email is sent when only the customer decides.
The email names the operation, the person it's for, the agent, the environment and the expiry, with a Review the request button that opens the request in the console. It never contains the values themselves; you see those after signing in.
To stop these emails, open Account and turn off When a request waits for my approval. See Sign-in security.
What happens after you approve
- The Gateway picks up the decision, within seconds.
- The Control Plane checks again. It confirms that the request hasn't expired, that the policy and the tool haven't changed since the request was made, that the agent, the tool and the Gateway are still turned on, and that the person it acts for is still active.
- The operation runs once. If the check passes, the Gateway gets a permission that lasts 60 seconds and is bound to these exact values, and sends the operation to your system once.
If the check fails, nothing is sent and the execution ends as failed, with the reason in its timeline. Most changes, such as a saved policy or a re-imported tool, cancel the request before it gets here (see Cancelled requests). The check catches whatever else changed.
The agent learns the outcome by asking the Gateway for the execution's status. You can follow every step on Executions & audit: open the execution to see its timeline, from the agent's request through your decision to the result. See Executions and audit.
Related
- Approvals explains why approvals work this way.
- Write a policy shows how to choose which calls need approval.
- Settings is where an admin chooses how long requests wait.
Still stuck? Contact support from the console.