Approval types

Every item in the approval queue carries a kind — a short machine name that says exactly what will happen if you approve it. This page lists the kinds in use, what each one means in plain English, and what approving it actually does. Read it as a reference to keep beside working the approval queue.

One rule covers all of them: nothing on this page runs until a person approves that specific item, and the kinds that reach the outside world stay human-approved permanently — see autonomy and the hard floor.

What is an approval kind?

An approval kind is the discriminator on the item — the field that decides which action fires when you press approve. It is not a category for filing; it is the action itself.

Two properties matter when you read one. First, whether the effect is external (something changes outside Business-Gym: an email leaves, a post publishes, a CRM record is written) or internal (a task, a filed document, a rule). Second, whether the path behind it is live or still staged — some kinds record your decision faithfully but deliberately stop short of acting.

A few more kinds exist for quotes, contracts and ad-platform writes. They follow the same rule and are covered on their own pages rather than here.

Note

Approving or rejecting any inbound_* item also moves the original message out of your triage queue — to done on approve, back to unclaimed on reject. That happens immediately and is separate from whether the action itself ran.

Which kinds change something outside my company?

These are the kinds whose purpose is an effect outside Business-Gym, so they deserve the slower read before you decide. Each row says what actually happens today, not what the kind is named after.

Kind	What it means	What approving it does
inbound_draft_reply	A reply to an inbound email, drafted for you to edit first	Hands the approved text to the email send path so it can leave your connected mailbox. The send has its own switch — confirm from the outcome, not from the click.
channel_reply	A reply on a non-email channel — WhatsApp, Slack, Telegram or a Meta inbox	Queues the reply for that channel. Each channel has its own send switch and transmits nothing while it is off.
crm_outreach	A first-touch email to a contact in your CRM	Queues the outreach email for delivery from your mail connector.
marketing (marketing.send)	A post or campaign staged under your brand name	Publishes the staged post to the connected surface — Facebook and Instagram through Meta, LinkedIn through the connected provider.
inbound_create_crm_lead	A lead built from an inbound message	Creates — or links to an existing — record in Dynamics. This is a real external write.
crm.writeback	A change to a field on a CRM customer record	Attempts the field update in Dynamics. The live write is off by default; while it is off the item records skipped, never a false success.
brief_comms_teams_send	Your daily brief, staged to post into Teams	Records your decision only. The server-side send gate is off in production, so the brief stays a draft and nothing posts to Teams.
invoice.issue	An invoice staged for issuing	Moves the invoice from staged to sent inside Business-Gym and stamps a placeholder reference. No money moves — see revenue and invoices.

The connector side of these is set out in integrations, which lists what each connection can read, write and propose.

Caution

A marketing post is marked sent only when it genuinely published. If the surface is not connected the send is marked failed with the reason, so a post that never appeared is never reported as sent.

Which kinds only change things inside Business-Gym?

These kinds move work around inside your workspace and send nothing to anyone. They are the bulk of a normal queue and can be cleared faster than the group above.

Kind	What it means	What approving it does
inbound_forward	Hand the message to a department head to handle	Creates a task assigned to that head in the Inbound project. It does not forward an email to anyone.
inbound_file	File the message into your team’s knowledge	Ingests the message as a knowledge document under that head’s knowledge scope.
inbound_create_task	Turn the message into a tracked piece of work	Creates a task in the Inbound project.
inbound_delegation	Name an owner — a real person or a head — for the work	Records the decision and closes the triage item. The approval itself is the tracked delegation; no other system is written.
inbound_bulk_action	One decision applied to a whole cluster of similar mail	Applies it across every clustered message and adds a suppression rule for that sender domain, so the same mail stops re-clustering. No unsubscribe email is sent.
inbound_sor_write	A proposed update to a company system of record, such as a SharePoint list	Records your decision and closes the item. The write itself does not run yet.
operator_directive	An instruction for a desktop operator to run	Stamps your approval on the directive so the operator can claim and run it. While it is unapproved the operator cannot pick it up at all.

operator_directive is the newest of these. It exists because a directive that requires approval was previously unclaimable forever — approving is the step that unlocks it, and rejecting leaves it pending and unrunnable, which is the correct end state for a refused instruction.

Which kinds are staged today but do not actually go out?

Four of them stop short on purpose, and knowing which ones saves you from assuming an action happened. Business-Gym would rather record an honest stop than a success it did not achieve.

• brief_comms_teams_send — the send gate is off in production. Your approval is recorded and the brief remains a draft.
• crm.writeback — the live Dynamics write is off by default. The outcome reads skipped.
• inbound_sor_write — the system-of-record write has no executor yet. Approving closes the item and writes nothing.
• invoice.issue — the status moves inside Business-Gym and a placeholder reference is stamped. Nothing is charged, posted to Stripe or booked to DATEV, which is not connected.

channel_reply sits half in this group: the reply is queued on approval, but each channel has its own switch, so a channel that has not been turned on transmits nothing.

What are the kinds ending in _proposed?

Those are rules the system wants to keep, not actions on a single item. They appear when your edits show a consistent pattern, and approving one writes that rule for your team.

• inbound_teach_rule_proposed — a triage rule, so mail like this is classified the way you keep classifying it.
• inbound_reply_guidance_proposed — guidance for drafting replies, learned from how you edit them.
• marketing_content_style_proposed — a content-style rule, learned from your edits to drafted posts.

All three are internal writes that send nothing. They are also the only way a learned rule ever takes effect: the system stages the proposal and waits, rather than applying it quietly. How your team learns covers what is designed versus live.

Why do I see inbound_reply and alert_rule if I cannot approve them?

Because those two names label records elsewhere in the product rather than cards in your queue, and it is easy to mistake them for approval kinds when you meet them in a list.

inbound_reply is the name the outbound ledger gives a reply that has actually been sent. You never approve it directly — approving the inbound_draft_reply is what produces it, which makes it a useful thing to look for when you want proof a reply left.

alert_rule tags a notification raised by an alert rule, such as a workflow failing repeatedly. It lands in your notification feed, and no action executes when you read or dismiss it.

Why does the queue label some kinds and not others?

The queue shows a type pill on each card, and only some kinds have their own label. Anything without one falls back to the workflow label, or to the plain word “Workflow”.

Labelled today: create task, forward, file, CRM lead, draft reply, delegate, CRM outreach, task draft, quote send, contract send-for-signature, task move, Teams brief delivery, run directive, and marketing sends, which name their platform — “Marketing · LinkedIn” rather than a generic pill.

Not labelled today: channel_reply, inbound_bulk_action, inbound_sor_write, invoice.issue, crm.writeback and the _proposed kinds. Those cards read “Workflow” even though no workflow is behind them. It is a display gap, not a behaviour one — the card body still describes the real action, so read the body rather than the pill on anything unfamiliar.

How do I check that an approved action actually ran?

Look at the outcome on the approval’s history row, which records executed, skipped or failed for the action you approved. Your approval is a decision; the outcome is what the system did with it.

This matters most for the kinds above that are deliberately staged. A skipped outcome means the path was off and nothing happened — that is the system being honest rather than failing, and it is exactly the behaviour described in the inbound → approve → execute loop.

Tip

When you need certainty that a message left, do not stop at the approval. Check the ledger too — outbound holds the record of what actually went out, on which channel, and who approved it.