Actions

Multi-step workflow execution for claims operations — prebuilt templates, Signal-triggered flows, and custom workflows via MCP.

Isomer Actions is the workflow execution layer built on Isomer Core. It runs multi-step workflows triggered by a Signal or standalone on an inbound message. Use it for cases that require more than a notification: gathering context, drafting responses, filing entries, validating data.

Simple notifications don't need Actions — Signals handles routing to email, Slack, and CMS writeback natively. Actions is for the heavier layer.

When to use Actions

Prebuilt templates

Isomer ships prebuilt workflow templates for the most common claims operations. Templates are configured to your environment — they are not installed from scratch.

FNOL intake

Processes a first notice of loss: extracts loss details, verifies policy coverage, identifies involved parties, populates your CMS, and routes to the assigned adjuster. Supports straight-through processing for qualifying FNOLs.

Invoice validation

Validates provider invoices against policy coverages and billing rules. Flags discrepancies for review; approves clean invoices for payment processing.

Claims triage

Evaluates inbound claims for severity and complexity signals. Routes high-complexity claims to specialized handlers; keeps routine claims in standard queues.

Coverage & benefit validation

Checks a claim against active policy coverages and benefit schedules. Surfaces coverage gaps, limits thresholds, and coordination-of-benefits issues before they become disputes.

Policy servicing

Handles inbound policy service requests — endorsements, cancellations, certificate requests — without routing through a claims adjuster.

Workers' comp intake

Specialized FNOL intake for Workers' Compensation: captures injury details, employer information, medical provider assignment, and state-specific reporting requirements.

Post-bind review

Reviews newly bound policies for risk indicators before the first claim arrives. Identifies coverage ambiguities and policy-level signals that affect future handling.

Triggering a workflow

Actions workflows run in three modes.

Signal-triggered. A Signal fires and its configured action is an Actions workflow. The workflow receives the signal payload — source evidence, urgency, confidence — as input context.

Standalone. A workflow runs directly on an inbound message, without requiring a Signal to fire first. Use standalone mode for structured intake flows where you want consistent processing regardless of whether a risk is detected.

Claim-change triggered. A workflow listens for changes to a claim and dispatches when one is detected. Use this mode for workflows that should react to a claim's state over its lifecycle — re-running validation after new evidence arrives, re-evaluating coverage after a party is added, or driving follow-up after a status change.

Claim-change triggers are configured in workflow Settings → Listeners, alongside email-inbox listeners. A single workflow may have multiple listeners of either type.

When a claim updates and a matching workflow already has an in-progress run for that claim, the trigger appends the update to that run rather than starting a new one. When all prior runs are completed, the listener's auto-create setting controls whether a new run is started.

Claim-change events are dispatched on a short schedule rather than in real time. New runs and resumed runs both appear in the inbox with a dedicated icon so they're easy to tell apart from Signal- and email-triggered events.

Building custom workflows

Teams with specific requirements can build custom workflows using MCP. Custom workflows have the same access to the claim graph, ingestion pipeline, and action primitives as prebuilt templates.

# List available MCP tools for Actions
isomer mcp tools --product actions

See Core as Infrastructure for the full MCP reference.

Deployment

Actions workflows require configuration before go-live:

1. Requirements gathering — define the trigger condition, input context, steps, and output.
2. Configuration — map workflow steps to your CMS fields, routing rules, and user assignments.
3. Testing — validate against representative claim samples before enabling in production.
4. Change management — brief the team members whose queues the workflow will affect.

Prebuilt templates shorten this process significantly — requirements and step logic are predefined; configuration focuses on your environment specifics.

Next steps