Skip to main content
After creating a workflow, configure how it runs, who can run it, and what information it needs. This guide provides an overview of all configuration options.

​
1. Create a Workflow

To get started with automations, build a workflow from scratch in Catalyst, install a pre-built workflow, or duplicate an existing one.

Build a Workflow

Build a workflow from scratch in Catalyst using natural language

Install a workflow

Select a pre-built workflow to start with and configure as needed

Duplicate

If there’s another Team in Serval already set up, you can duplicate workflows across teams

​
2. Configure the Workflow

Once you’ve created a workflow, you can configure that workflow with the following specifications to meet your organization’s needs.

Workflow Types

Choose the right type: help desk, team-only, scheduled, webhook, event-triggered, or access workflows

Triggers

Configure when workflows run: manually, on schedule, via webhook, or on events

Approvals

Require approval before execution using static approvers or custom approval workflows

Inputs

Collect information from users: text, dropdowns, dates, and more. Workflows with form inputs automatically appear as catalog items.

Execution Scope

Control who can run the workflow: anyone in the org or team members only

Versioning

Track changes and restore previous versions of your workflows

​
Quick Reference

​
Common Configurations

​
Self-Service Help Desk Workflow

For workflows that help desk users can trigger:

​
Internal Team Workflow

For workflows restricted to your team:

​
Automated Report

For scheduled reports and notifications:

​
Sensitive Operation

For workflows that need oversight:

​
Child Workflows

A child workflow is a workflow that the parent workflow calls as a step in its own process. Build a piece of logic once, then reuse it across any number of parent workflows instead of rebuilding it each time. Use child workflows to keep shared logic in a single source of truth. Common use cases include:
  • Shared onboarding and offboarding steps that several team workflows depend on
  • Centralized approval flows reused across any workflow that needs approval
  • Standard escalation routines that multiple teams run the same way
When you describe a parent workflow calling a child, Catalyst reads the child’s input fields and types, then wires up the call with the right parameters. If a child workflow requires approval, that approval surfaces on the parent workflow’s ticket and sends a Slack notification, so a pending child never stalls the parent silently. Serval links child runs to the parent run, so the tree in run history shows the entire, combined process.

​
Send WhatsApp notifications

Connect your Twilio account on the team that owns the workflow. Create and manage notification templates in that account’s Content Template Builder. For business-initiated messages outside the customer service window, use approved WhatsApp templates. Call twilio.common.sendWhatsAppMessage with the workflow’s Twilio context:
The action returns messageSid and status. It sends WhatsApp only. To notify everyone by both channels, call the existing email action as well, and use each recipient’s phone for the WhatsApp action. Users without a phone can still receive email. Handle failures independently so one channel’s failure doesn’t skip the other. For an initial invitation, send the ordinary Journey URL. Opening it takes the recipient through sign-in if necessary. The action doesn’t generate authentication tokens, create a Serval inbox entry, or automatically run when a Journey is created. Schedule reminders and check whether tasks remain incomplete in your workflow. For other Twilio API calls, use twilio.apiRequest with body for JSON requests or form for form-encoded fields (Record<string, string>). Supply only one of these options. Both use the connected Twilio account and return the parsed JSON response.