Workflows

Workflows are event-driven automations: when something happens in Contents Capture, a workflow can send messages, update statuses, or call webhooks, without anyone lifting a finger.

What workflows are

Every significant thing that happens in your org emits an event: an assignment is created, media is uploaded, a submission arrives. A workflow listens for one event, optionally checks conditions, and then runs actions. Three concrete examples:

1. Submission alert: when a submission arrives, send an SMS to the team's admins so the desk knows field work just landed.
2. Status notification: when an assignment status changes, email the claims inbox with the assignment name, reference, and new status.
3. System sync: when media is uploaded, call your own system's webhook so your claim platform stays in sync.

The full list of events workflows can listen to is in Reference → Event types.

The Workflows list

Open Automation → Workflows. The page describes itself: "Event-driven flows: when something happens, send messages, update statuses, call webhooks."

Column	Meaning
Name	The workflow name.
Scope	Org-wide, a specific team, or a specific profile.
Enabled	Toggle to turn the workflow on or off without deleting it.
Runs	How many times it has run.
Last run status	Success, partial, or failed.
Updated	When it was last edited.

Row actions: Edit, Duplicate, Export (downloads a .workflow.json file), and Delete (deleting a workflow keeps its message templates but removes its run history).

Header actions:

• New workflow: start from scratch.
• From library: start from a preset in the gallery, which is the fastest way to get a proven workflow running.
• Import: upload a .workflow.json file, handy for moving workflows between organizations or restoring an export.

Viewing the list requires audit.read; creating and editing requires team.manage.

Creating a workflow

The creation wizard walks through five steps:

1. Template: start blank or pick a preset.
2. Basics: name and describe the workflow.
3. Scope: decide whether it applies org-wide, to one team, or to assignments built from one profile.
4. Trigger: pick the event that starts the workflow, for example submission.created.
5. Review: confirm, then open the builder to add conditions and actions.

The builder in plain terms

The builder is a visual canvas where each step is a node connected to the next. You do not need technical knowledge to read one: follow the arrows from the trigger at the top.

The trigger node

Every workflow has exactly one fixed trigger node. It holds the event type and optional filter rows, for example "only when the assignment's team is Sacramento CAT Crew". Filters keep workflows quiet so they only fire on the events you care about.

Condition branches

A Condition node splits the flow into true and false branches. Conditions are checks over values from the event, combined with AND, using operators like equals, for example "assignment status equals submitted". The true branch runs when all checks pass; the false branch runs otherwise.

Action nodes

• Send email / Send SMS: pick a message template or write an inline message. Inline messages support {{variable}} chips that insert event data, for example the assignment name or the submitter's name, into the text.
• Update assignment status: move the assignment to a new status automatically, for example setting in review when a submission arrives.
• Webhook: send the event to a URL of your choosing. You set the method, headers, and a JSON body template. The request is signed with your org webhook secret when one exists, so the receiving system can verify it came from Contents Capture. See Webhooks.

Recipients

Email and SMS steps offer four recipient choices:

• The actor: the person who triggered the event, for example the adjuster who submitted.
• Team admins: the admins of the relevant team.
• Assigned crew members: everyone assigned to the assignment.
• Custom address: a specific email address or phone number you type in, such as a shared claims inbox.

Testing before enabling

Every node has "Test this step", which runs just that step with sample data. You can also fire a full test run of the whole flow before enabling it. Test runs are clearly badged in the runs feed so they never look like real activity. Always run at least one full test before turning a workflow on.

Validation

The builder validates the flow as you work and blocks saving a broken workflow: loops, unreachable nodes, missing recipients, and unfinished templates are all flagged before the Save button will cooperate. A saved workflow is always a runnable workflow.

Runs

The Runs pages show every execution:

• Automation → Runs: org-wide feed of all workflows.
• A workflow's Runs action: runs for that workflow only.

Both poll every 10 seconds. Columns: Started, Workflow, Status (with a "Test" badge on test runs), Duration, Assignment link, and an Error preview when something went wrong. The Hide test runs toggle is on by default in the org-wide feed and off on per-workflow feeds.

Click a run to open the run detail drawer: a per-step timeline showing exactly what each node did and where a failure happened. From the drawer you can replay a run, which re-executes it, useful after you have fixed whatever made it fail.

Good first workflows

• Submission SMS to team admins (submission.created): the classic. The desk knows instantly when field work lands.
• Status-change email to the claims inbox (assignment.status_changed): keeps the claim file current without manual email.
• Failure alert (media.upload_failed): notify team admins when uploads fail so connectivity problems get fixed before evidence sits on a device.
• Webhook to your claim system (media.uploaded or submission.created): keep your system of record in sync automatically.