Workflows

Workflow definitions are saved JSON#

Matruno persists legal workflow definitions in PostgreSQL as JSON configuration plus metadata such as name, version, status, schema contract, execution policy, workspace, and practice-area domain. The backend supports create, import, export, validate, update, delete, usage, steps, and model-settings routes.

POST /api/v1/workflows/import
POST /api/v1/workflows
GET /api/v1/workflows
GET /api/v1/workflows/{workflow_id}
PUT /api/v1/workflows/{workflow_id}
DELETE /api/v1/workflows/{workflow_id}
GET /api/v1/workflows/{workflow_id}/export
POST /api/v1/workflows/validate

Workflow JSON shape#

Workflow definitions support:

• name, version, and description
• schema_definition or schema contract for matter payload fields
• field_permissions in blueprint-backed flows
• participants
• documents
• ordered steps
• terminal_keys
• validation metadata

Each step includes a stable key, index, name, instruction, agent_type, params, depends_on, and is_terminal. Branching steps can include branch definitions with conditions and next step keys.

Supported step types#

The validator accepts email, call, voice, doc_process, doc_draft, document, integration, branching, crm, and none. The crm type is an implemented coordination/checkpoint agent for matter and participant data, not a generic CRM product. Some types require provider credentials or implementation-specific params before they do useful work in a deployment.

These step types support legal intake, evidence processing, drafting, correspondence, and review. They do not connect Matruno to courts or case-law databases.

Sample workflows#

Create legal workflow definitions in the UI or import JSON. A legal-compliance sample lives under examples/workflows/. Treat any remaining non-legal example JSON in examples/ as workflow-shape samples only, not as Matruno product domains.