Risk tiers and automation eligibility

Automation level is an authority decision. A system that can produce a correct recommendation can still be unsafe to let loose on the next action.

Use consequence and reversibility

Move down the ladder when the action is external, durable, hard to reverse, legally sensitive, or owned by a different team.

Eligibility is a predicate

Do not put the tier in a slide deck and hope the workflow remembers it. Make eligibility testable:

action: create-follow-up-task
automation_tier: queue
eligible_when:
  - decision.state == evaluated
  - decision.outcome == route-to-seller
  - consent.sales_contact_allowed == true
  - record.owner_id is present
  - duplicate_check.state == clear
blocked_when:
  - decision.state in [failed, unknown, needs-review]
  - action.preview_hash is missing

The system should store which predicate blocked the action. “Did not run” is an operational state, not a business outcome.

Reversible does not mean harmless

An internal task can be closed. A message sent to a prospect cannot be unsent. A field value can be restored only if the previous value and reason are stored. A merge may be technically reversible while relationships, activities, or integrations have already moved.

Before enabling act mode, document the undo path, the owner of the undo, the maximum volume per run, and the kill switch. Test the path with a sample record.

Classify the action, not the feature

One workflow can contain several authority levels. Reading a Contact, drafting an email, creating an internal task, changing an owner, and sending the email are five separate actions. Calling the whole feature “assistive” or “autonomous” hides the only distinctions that matter.

Build the inventory at action level:

The maximum is a ceiling, not a target. A reversible action may still stay at recommend while the team validates its rules. Moving from recommend to queue should be a deliberate release decision supported by observed results, not the default reward for passing a test set.

Pair every tier with controls

Authority is incomplete without volume, population, and failure controls. At minimum, record:

• the eligible population and explicit exclusions;
• the maximum actions per run and per day;
• whether a preview shows individual records and changes;
• the approval role, when approval is required;
• the stop condition and kill-switch owner;
• the rollback or remediation path;
• the event written to history after success, refusal, or failure.

An approval is useful only when the approver can see something the system cannot resolve. Asking a person to approve 2,000 individually correct, low-risk task creations is theater. Asking the Account owner to approve a reassignment because two ownership rules conflict is a real control.

Promotion checklist

Promote an action one tier at a time. Before each promotion, confirm that the eligible population is stable, the preview matches the eventual write, retries cannot duplicate the action, blocked actions preserve a reason, and operators have exercised both stop and recovery. Then monitor the first bounded cohort before widening the population or volume cap.

Do not promote because the decision reports high confidence. Promote because the consequence is understood, the action is bounded, the evidence is sufficient, and the recovery path has been tested.

Platform path

Salesforce record-triggered Flow and HubSpot workflows can express many bounded eligibility checks. Keep custom code for a rule that cannot be represented safely in the platform, and route that code through the same approval and logging contract. The Salesforce Flow documentation and HubSpot workflow documentation are the current implementation starting points.

Related: Decision Card template, Limits, kill switches, and staged rollout, and Permissions and safety.