Routines

Repeatable workflows combine an automatic work-ticket note, a named-person check-in, required proof, and a discussion on the run ticket. Each run shows ordered step status, deadlines, answers, evidence and history. A person can answer inline from an Activity notification or on the run page.

Status: dark, platform setting routines.enabled defaults to off. An owner/admin with settings permission creates a disabled workflow, chooses an accessible project, binds each role to a person who can see the project, and enables it. Starts can be manual, scheduled or a named event. Disabling stops future starts while an existing run keeps its frozen workflow.

Only the named person can answer an open step, using their own signed-in session. Proof must match the requested kind: HTTP(S) link, a completed ticket file, a verified screenshot, or a dated finite metric with a source link. A routine confirmation does not grant permission to publish, send or charge.

A missed check-in is tracked once as overdue, keeps the native ticket blocked on that person, is adopted by the existing follow-up graph, and queues notifications for that person and the org owner. Email uses existing delivery preferences and the durable outbox. Actual email delivery remains subject to that delivery pipeline.

• Open Routines in the organization navigation after activation; open a run for checkpoints and its linked ticket.
• MCP: routine_list, routine_run, routine_respond, with the same live access checks. An org/bot key may read its permitted state but cannot answer as a person.
• API: /v1/orgs/{orgId}/routines; dark contracts appear in all-features OpenAPI.
• Portable routine@1 workflows use Org Blueprints. They import disabled without bindings or run data; a live org owner must permit installation.