Acceptance rules

An acceptance rule tells a seat what “finished” means. When the seat hands in its work, the platform checks the rule and either accepts the work or tells you what was missing.

A seat that runs on its own needs one

If a seat has a schedule, a webhook address or a polling trigger, it can start work without you. Such a seat will not start until it has a valid acceptance rule. Until then it is listed as blocked under “Needs you” on your organization’s overview page.

You cannot switch this off, and there is no default rule. A rule that always passed would let every piece of work through while making it look checked, which is worse than having no rule.

Writing a rule

Open Organization, click a seat, and find When has this seat finished its work? You do not need to write code or JSON: pick a starting point from the examples, then adjust it.

Every rule you add must pass. Rules combine with “and”, never “or”.

Kinds of rule

It saved a file

The work counts as done when the seat produced a file, optionally of a particular type or above a minimum size so an empty placeholder does not pass. Use it when the deliverable is a document, a report or an export. The seat’s agent needs a tool that can save files, and its prompt needs to ask it to.

It reported a result

The work counts as done when the seat replies with structured data containing a field you name: for example a status of ok, or a processed count of at least 10. Use it when the outcome is a fact rather than a file. Ask for that field in the seat’s prompt too, or the seat will not know to report it.

A measure reached a level

The work counts as done when a recorded business measure passes a threshold. This only works once something is recording that measure; a measure nobody records can never pass, so the rule would block the work for good. The platform warns you when that is the case.

Check before you save

Press Check these rules and the platform tells you in plain language what it will require, for example:

Read that text rather than the form. It is the same wording you see if the work later fails, so what you are promised now and what you are told then cannot disagree.

When work is not accepted

Work that fails its rules is marked Not accepted. Click why? to see, for each rule that did not pass:

• What was required, for example “Must save at least one file.”
• What actually happened, for example “It saved no matching files.” If the seat reported a result but not the field you asked for, this also lists the fields it did report, which is usually enough to spot a naming mismatch.
• What to change: the seat’s tools, its prompt, or the rule itself.

Editing as JSON

The builder covers the common cases. For anything it cannot express, use Edit as JSON to write the rule in full. A rule the builder cannot show always opens in JSON, so it is never simplified without you knowing.

Your edits carry across when you switch between the two: edit in JSON, switch back to the builder, and your changes are still there.