The Loggie blog
How to require Slack approval before an AI agent takes action
Configure Loggie so an agent can read Asana tasks but needs Slack approval to create one. Understand pending requests, rejection, expiry, and failed actions.
An assistant reviewing an Asana project might find a missing follow-up task. You want it to suggest the task, including the project and description, but you want a person to approve the creation before anything changes in Asana.
Loggie can hold that API request for review and notify a Slack channel. The request has already been formed when the reviewer sees it. Approval tells Loggie to execute the saved request; rejection leaves the provider unchanged by that request.
This guide uses a disposable Asana project to test the workflow. You need an Asana connection in Loggie, an agent identity assigned to it, and a connected Slack workspace for approval notifications. Use a real project only after you have checked both approval and rejection.
Configure one specific write for review
Start by deciding which operations should run without intervention. Task reads needed for a report can be allowed directly. For this example, task creation requires approval, while task updates and deletions remain unavailable.
Discover the paths on your Asana connection before writing rules:
loggie discover
loggie discover asana --method POST --search tasks --limit 10
loggie discover asana --endpoint /tasks --method POST
These commands assume the connection slug is asana. Substitute the slug shown in your catalog.
In the agent's access policy for that connection, grant the underlying access needed for the intended write. Configure an allowlist containing the required reads and POST /tasks, then require approval for task creation. Check the saved endpoint and approval rules together. Do not leave unrelated writes open just because this one action needs write access.
A plain read-only assignment can reject a write before the approval step. An approval rule also does not make an otherwise inaccessible connection available. The permissions guide explains how the connection assignment and policy fit together.
Choose where the approval notification goes
Connect the workspace's Slack integration. Open the agent's settings and find Approval Notifications. Choose the Slack Channel that should receive requests and save the settings.
The channel belongs to the agent's approval configuration. Connecting Slack alone does not select a destination for every agent. Choose a channel whose members are appropriate for the task context being shared and who know who is responsible for reviewing requests.
The same settings include Timeout (min). The default is 60 minutes; choose a window appropriate for the workflow. A time-sensitive operation should not wait all day for a reviewer who is offline.
Submit a safe test request
Replace TEST_PROJECT_GID with a disposable project's ID. This command requests an actual task creation, so approving it will create the task:
loggie call asana POST /tasks \
--data '{"data":{"name":"Review the support handoff","notes":"Approval workflow test. Safe to remove after testing.","projects":["TEST_PROJECT_GID"]}}'
The request body follows Asana's create-task format. Confirm that your connection has permission to use the test project before testing approvals.
With the policy configured correctly, Loggie responds with HTTP 202 and a pending-approval payload. Its core fields look like this, with illustrative IDs:
{
"approvalRequestId": "example-request-id",
"status": "pending_approval",
"message": "This request requires human approval.",
"pollUrl": "/api/agent-pass/approval-requests/example-request-id"
}
The actual response also provides information for attaching request context. Keep the request ID so the assistant can refer to the same action while it waits.
HTTP 202 does not mean Asana created a task. The CLI returns the pending response without automatically waiting for a decision. An automation must inspect the response status rather than interpreting a successful shell exit as a completed business action.
Review the saved action in Slack
Check that the notification names the expected agent, connection, and operation. Inspect the available request details and the assistant's explanation. For a task creation, the reviewer should understand the intended project and task content before approving.
Request-body logging is configurable. Do not assume every log or notification contains every field. If the available details are insufficient to make a decision, reject the request and ask for a new, reviewable proposal rather than guessing.
Approval executes the captured request on the server. It does not ask the assistant to submit the command again. Repeating the original write after approval can create a duplicate task.
After approving the test, inspect the request result and confirm that the task exists in the test project. Then submit a separate test request and reject it. Confirm that rejection does not create a second task.
Handle each outcome explicitly
| Outcome | What the assistant should do |
|---|---|
| Pending | Retain the request ID and wait for the decision. Do not announce completion. |
| Approved and successful | Use the recorded result and confirm the intended provider change. |
| Rejected | Stop that action. Do not retry it through another identity or route. |
| Expired | Report that approval expired. A fresh proposal needs a fresh review. |
| Approved but failed upstream | Inspect the failure and provider state before deciding whether another request is safe. |
Human approval does not guarantee provider success. The saved request may fail because the provider credential expired, the resource changed, or the provider returned an error. A network failure can also leave uncertainty about whether a write took effect. Check Asana before retrying so you do not create a duplicate.
If Slack notification delivery fails, the pending request is not automatically forwarded. Check the approval request in Loggie and fix the notification configuration. A missing Slack message is not permission to bypass review.
Give the assistant a waiting rule
Add this instruction to the workflow that may request writes:
If Loggie returns pending_approval, record the approvalRequestId and say
that the action is awaiting review. Do not claim the provider action is
complete. Track that same request using the returned status information
or ask the operator to check it in Loggie.
Do not resubmit the original write after approval: Loggie executes the
saved request. Stop on rejection or expiry. If an approved action fails,
check its result and the provider state before proposing a retry.
The result is suitable for a workflow such as weekly Asana reporting: the assistant can read tasks and draft suggestions, then request a particular follow-up action for review. Keep actions with different risks in separate rules, and explicitly review pending requests when retiring an agent or changing its responsibilities.