Approvals

Approvals are the decision queue. An agent, a workflow, or an ingest job inserts a pending row. You resolve it. The database runs the card's on_approve action only when the status becomes approved.

Open Approvals (/approvals). Deck is one card at a time: approve, reject, or skip. List is the same pending queue with a domain filter, type tabs, and bulk approve or reject. /deck redirects to the deck view. The list and the deck call the same resolve API.

You can also open a card's chat from the deck. That chat can search indexed text. It does not resolve the card for you.

Statuses

Status	Meaning
pending	Waiting
approved	Accepted. on_approve has run, or has recorded its result
rejected	Declined. on_approve does not run
deferred	Set aside. The deck and list resolve actions use approve and reject
expired	No longer actionable
delegated	Handed to someone else

The Cockpit resolve buttons send approved or rejected. Other statuses exist on the row for agents and for bulk tools.

An approve must be attributed. A session in Cockpit, or resolve_approval from a token, stamps who decided. A raw update that sets approved with no actor is refused.

What approve does

on_approve.kind selects the action. The kinds you will see on entity cards:

Kind	Effect
entity_create	Insert one row in accounts, contacts, deals, projects, campaigns, or territories
entity_update	Write the listed fields through the field-provenance path
entity_merge	Merge the loser into the keeper. Needs the merge decision on the card
entity_alias_add	Add an alias
task_status	Move the linked tasks from one status to another
row_status	Flip an allow-listed marketing or campaign-member status
enqueue	Send a job to an allow-listed queue

Duplicate protection on create skips the insert when the slug or domain is already present. Keys that are not in the entity shape are dropped. Shapes are editable under Admin → Approval types (/settings/approvals).

What you send on a create card

Agents call approval_create (scope approvals:write) or include the entity on a graph check-in. For a create, send item_type graph_entity_create and either on_approve or table plus fields.

A contact example, with no address on purpose:

{
  "item_type": "graph_entity_create",
  "title": "Create contact: Jane Example",
  "table": "contacts",
  "fields": {
    "full_name": "Jane Example",
    "title": "VP Operations",
    "lifecycle_stage": "lead"
  }
}

Required and allowed fields are in Entity fields. Do not send tags, domain_wall, references, slug, id, or owner_user_id. Do not send name on a contact. Foreign keys accept an id or a slug.

graph_entity_update is the matching type for a field change. project_create is a project-shaped create.

Human-only cards

These types stay with a person. approval_resolve from an agent token refuses them:

• graph_entity_merge
• graph_entity_rename
• graph_entity_create
• graph_entity_alias
• merge_proposal
• stage2_identity
• product_create
• product_rename
• engagement_outcome_achieve
• workflow_cross_desk_grant

Agents may still propose a create. A person approves it in Cockpit. Agents may resolve types that are not on this list, including graph_entity_update and extraction cards, when the token has approvals:write.

Fuzzy name matches are not auto-merged. The card should show the candidates. You confirm.

Task cards

Promoting a backlog task and closing a task that has human_approval_to_close set both show up here (task_promote, task_close_ack). Rejecting a proposed task cancels the linked task. It does not promote it.

Where else cards come from

Meeting and activity extraction files a card per proposed action when the confidence is under the threshold. Those cards use the type extraction.<action>. They sit in this same queue. There is no separate extraction inbox. See Meetings and extraction.