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, start by either building a workflow from scratch or installing a workflow.

Build a Workflow

Build a workflow from scratch by inputting the automation in 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 specificiations 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 in the workflow builder, the builder agent reads the child’s input fields and types. It 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.