Slack and email as policy steps — not another place to chat.
A policy that runs for a client store can end with a notification: post to that client's ops channel, email the client's owner, page the on-call. The message carries the facts and a link to the inbox item. Approvals still happen in the inbox or the mobile app, so the ledger always knows who signed off.
Already have an account? Set this up on a client store →
Three refunds over the client's €50 autopilot threshold are queued (€71.20, €98.00, €145.50). Each has an inbox item with the exact amount and reason; nothing moves until approved.
The right person hears about it late, or everyone hears about everything.
Ten client stores generate events all day. Route them all to one channel and it becomes noise nobody reads. Route none and a €145 refund sits unapproved until someone remembers to open the admin.
One channel for everything
Northwind's stock-outs next to Bluefin's refunds next to Maple & Oak's 404s. Nobody owns the channel, so nobody reads it.
Clients want to be told, not to log in
A client owner wants an email when revenue drops or a big refund goes out. They don't want a dashboard, and they certainly don't want your Slack.
Decisions made in chat don't get recorded
A thumbs-up in a thread is not an approval. If the action isn't tied to a signed-off inbox item, the ledger can't say who allowed it.
Notify is a `then` step. Per client, per channel, per threshold.
Any policy can end with a notification, and a policy can exist only to notify. Slack channels, email addresses and mentions are parameters of the step — so each client's events land in that client's channel and the client's own inbox.
- Scoped to one client: its channel, its owner's email, its thresholds.
- Direct steps only — nothing here needs a model. The message is built from the policy's fields.
- Every notification carries a link to the inbox item; approve or deny there, or from the mobile app.
- Delivered messages are on the ledger with channel, recipients and timestamp.
Event or schedule → policy → notify → ledger.
Something happens, or it's 09:00
A store webhook fires, an agent queues an item for sign-off, a schedule ticks. The client's policy evaluates its conditions.
Threshold, then route
Field expressions decide whether it's worth a message at all, and to whom: the ops channel, the account lead, the client's owner. A quiet store sends nothing.
Context, when it helps
Where an agent step precedes the notify step, its summary travels with the message — the refund reason, the revenue-drop breakdown — so the reader doesn't open three tabs to understand it.
Delivered and recorded
Channel, recipients, the inbox item it pointed to, and — once someone acts — who approved or denied it. The client's monthly report shows what they were told and when.
Typed notification steps — delivery, not conversation.
A notification never approves anything. It tells the right person that an approval is waiting, a threshold was crossed, or a batch ran on autopilot. The decision stays in the inbox, where the ledger can see it.
- toolPost to a per-client Slack channel with a mention
- toolEmail the client's owner or your account lead
- toolDaily digest of pending sign-offs per client
- toolAlert on a threshold crossed — revenue, stock, refunds
- toolSummary after an autopilot batch runs
- toolLink every message to its inbox item
Route every client's events to the people who own them.
Connect Slack or add an email, set the channel per client, and attach a notify step to the policies you already run. Free for one store; agency plans from the second.
Free for one store · 14-day trial on paid plans · no card · bring your own AI key