> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serval.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Workflow Types
> Understanding the different types of workflows and when to use each
Serval offers multiple workflow types, each designed for specific automation scenarios. Choose the right type based on who triggers the workflow, when it runs, and what it does.
## At a Glance
| Type | Triggered by | Best for |
| :------------------------------------------------------------ | :----------------- | :---------------------------------------------- |
| [**Help desk**](#help-desk-workflows) | Help desk agent | Self-service requests from anyone in the org |
| [**Team-only**](#team-only-workflows) | Team members | Internal operations and sensitive tasks |
| [**Scheduled**](#scheduled-workflows) | Time schedule | Reports, audits, and recurring maintenance |
| [**Webhook-triggered**](#webhook-triggered-workflows) | External HTTP POST | Integrations with external systems |
| [**Event-triggered**](#event-triggered-workflows) | Serval events | Automated responses to ticket or access changes |
| [**Access provisioning**](#access-provisioning-workflows) | Access requests | Granting application access |
| [**Access deprovisioning**](#access-deprovisioning-workflows) | Access requests | Removing application access |
| [**Custom approval**](#custom-approval-workflows) | Approval steps | Dynamic approval logic |
| [**Knowledge ingestion**](#knowledge-ingestion-workflows) | Knowledge sync | Pulling documents into the knowledge base |
***
## Help Desk Workflows
Help desk workflows are available to anyone in your organization through the help desk agent. When a user submits a request via Slack, Teams, or the Serval web app, the agent matches their request to available help desk workflows.
**Characteristics:**
* Visible to the help desk agent
* Can be triggered by any user in the organization
* Appear in Help Desk Mode and Silent Mode channels
**Use for:**
* Password resets
* Software installation requests
* PTO submissions
* Equipment troubleshooting
* General IT support requests
**Example:** "Reset a user's Okta password and send them instructions via Slack DM"
### How users trigger help desk workflows
* **Via chat** — Request the workflow through Slack or Teams DM with the help desk agent
* **In app.serval.com** — Click the "Run" button on the workflow
* **During tickets** — Agents can run workflows while resolving tickets
Help desk workflows should handle common, low-risk requests. For sensitive operations, add an approval step or use a team-only workflow instead.
***
## Team-Only Workflows
Team-only workflows are restricted to members of your Serval team. They don't appear to the help desk agent when handling requests from users outside your team.
**Characteristics:**
* Only visible to team members
* Triggered manually or via Team Only Mode channels
* Hidden from org-wide help desk requests
**Use for:**
* User onboarding and offboarding
* Security audits and compliance checks
* Administrative operations
* Sensitive data handling
* Internal team processes
**Example:** "Offboard a departing employee: disable Okta account, remove from all Google groups, revoke GitHub access, and post summary to #it-ops"
### How users trigger team-only workflows
* **Team Only Mode channels** — Message in a connected team-only Slack/Teams channel
* **In app.serval.com** — Click the "Run" button on the workflow
* **During tickets** — Team agents can run workflows while resolving tickets
***
## Scheduled Workflows
Scheduled workflows run automatically on a recurring schedule using cron expressions. They execute without user input at the configured time.
**Characteristics:**
* Triggered by cron schedule
* Run in a specific timezone
* Execute without user input (unless configured with defaults)
**Use for:**
* Daily/weekly reports
* Compliance audits
* Data synchronization
* Cleanup and maintenance tasks
* SLA monitoring and alerts
**Example:** "Every Monday at 9am, list all open tickets older than 7 days and post a summary to #it-ops"
### Setting up a schedule
Select "Scheduled" as the workflow type when creating
Set the frequency using preset options (daily, weekly, monthly) or custom cron expressions
Select the timezone for schedule evaluation
Publish the workflow to activate the schedule
### Common schedules
| Schedule | Cron Expression | Description |
| :---------------------- | :-------------- | :----------------------- |
| Daily at 9am | `0 9 * * *` | Every day at 9:00 AM |
| Weekly Monday 9am | `0 9 * * 1` | Every Monday at 9:00 AM |
| Monthly 1st at midnight | `0 0 1 * *` | First day of each month |
| Weekdays at 6pm | `0 18 * * 1-5` | Monday-Friday at 6:00 PM |
| Every hour | `0 * * * *` | On the hour, every hour |
Scheduled workflows run in the timezone you configure. Make sure to set the correct timezone for your team's location.
Even scheduled workflows can be run manually for testing or one-off needs.
***
## Webhook-Triggered Workflows
Webhook-triggered workflows run when an external system sends an HTTP POST request to the workflow's unique webhook URL. This enables integration with any system that supports webhooks.
**Characteristics:**
* Triggered by HTTP POST to a unique URL
* Receives payload data from the external system
* Runs immediately when webhook is received
**Use for:**
* Responding to events in external systems
* Integrating with tools that don't have native Serval integrations
* Building event-driven automation pipelines
* Processing form submissions or alerts
**Example:** "When an expense is submitted in Ramp, send a Slack DM to the employee's manager asking them to review and approve"
### Setting up a webhook trigger
Select "Webhook-triggered" as the workflow type when creating
After publishing, copy the unique webhook URL from the workflow settings
Set up the external system to POST to your webhook URL when the triggering event occurs
Add a webhook secret for request verification
Respond to alerts from monitoring tools like Datadog or PagerDuty
Process submissions from external forms or portals
React to events from systems without native Serval integrations
Trigger workflows from deployment or build events
Webhook URLs are unique per workflow. Keep them secure—anyone with the URL can trigger the workflow.
***
## Event-Triggered Workflows
Event-triggered workflows run automatically when specific events occur within Serval. Examples include a ticket being created, a reaction being added to a message, or a ticket being moved to another team.
**Characteristics:**
* Triggered by internal Serval events
* Run automatically without user action
* Can filter by event type and conditions
**Use for:**
* Auto-tagging tickets based on content
* Assigning or closing a ticket when a specific reaction is added
* Escalating tickets that match certain criteria
* Triggering follow-up actions after workflows complete
**Example:** "When a new ticket is created, analyze the message and automatically add relevant tags"
### Available event types
| Event | Description |
| :------------------------------- | :----------------------------------------------------------------------------------- |
| Any ticket activity | A ticket is created, gets a new message, or has a reaction or label added or removed |
| Ticket created | A new help desk ticket is created |
| New ticket message | A new message is added to a ticket |
| Ticket escalated | A ticket is escalated to a human |
| Ticket reaches a terminal status | The ticket moves to a Done or Canceled status |
| Message reaction added | A reaction is added to a ticket message |
| Message reaction removed | A reaction is removed from a ticket message |
| Ticket moved to team | A ticket is moved to this team from another team |
| Label added to ticket | A label is added to a ticket |
| Label removed from ticket | A label is removed from a ticket |
### Setting up event triggers
Select "Event-triggered" as the workflow type when creating
Choose which Serval event should trigger the workflow
Filter to specific tickets, labels, or criteria
Publish to activate the trigger
Be careful with event triggers that create responses or modifications. Test thoroughly to avoid infinite loops or spam.
***
## Access Provisioning Workflows
Access provisioning workflows grant users access to applications and resources. They're used by the access management system when processing access requests.
**Characteristics:**
* Triggered by approved access requests
* Receive user and resource information as inputs
* Execute the steps needed to grant access
**Use for:**
* Adding users to application groups
* Granting role-based access
* Creating accounts in third-party systems
* Configuring permissions
**Example:** "Add user to the specified GitHub team and grant them the requested repository permissions"
Access provisioning workflows are configured in **Access Management**, not the standard Workflows page. See [Access Provisioning](/sections/access-management/configuration/access-provisioning) for details.
***
## Access Deprovisioning Workflows
Access deprovisioning workflows remove users from applications and resources. They run when access expires, is revoked, or when a user is offboarded.
**Characteristics:**
* Triggered by access revocation or expiration
* Receive user and resource information as inputs
* Execute the steps needed to remove access
**Use for:**
* Removing users from application groups
* Revoking role-based access
* Disabling or deleting accounts
* Cleaning up permissions
**Example:** "Remove user from the Okta group and revoke their AWS IAM role access"
Access deprovisioning workflows are configured in **Access Management**, not the standard Workflows page. See [Access Provisioning](/sections/access-management/configuration/access-provisioning) for details.
***
## Custom Approval Workflows
Custom approval workflows dynamically determine who should approve a request and whether to auto-approve or auto-deny. They run as part of approval steps in other workflows or access requests.
**Characteristics:**
* Triggered when an approval decision is needed
* Return approval decision: approve, deny, or route to specific approvers
* Can access request context to make decisions
**Use for:**
* Auto-approving low-risk requests
* Auto-denying requests that violate policy
* Routing approvals based on request attributes
* Implementing complex approval logic
**Example:** "Auto-approve if the user had this access within the past 30 days. Auto-deny if they were denied in the past 24 hours. Otherwise, route to the resource owner."
***
## Knowledge ingestion workflows
Knowledge ingestion workflows feed **searchable documents** into Serval's knowledge base during integration sync. Serval chunks the text, generates embeddings, and surfaces content to the help desk agent with citations back to the source.
**Characteristics:**
* Run as part of the knowledge sync process for a connected application (not a manual "run workflow" action from chat)
* Return structured documents: display name, markdown body, stable external IDs, and URLs used in citations
* Support full syncs and incremental (delta) syncs so only changed or removed documents are updated
* Distinct from workflows that sync **assets** (devices, accounts, tickets as records) — knowledge ingestion is for articles, wiki pages, handbooks, and other text meant for AI search
**Use for:**
* Internal wikis or knowledge APIs without a first-party Serval connector
* Proprietary or legacy systems where you control the API and map responses into documents
* Fine-grained control over which records become knowledge documents and how they are titled or linked
**Example:** "On each sync, call our internal handbook API, convert each article to markdown, and emit one knowledge document per article with the public help URL for citations."
Knowledge ingestion workflows are authored in code (TypeScript) — ask Catalyst to create a knowledge ingestion workflow and it sets the type for you. They are typically paired with a [Custom App](/sections/integrations/custom-app) or another integration that supports custom workflows. End users manage the resulting source from **Knowledge Base** like any other synced source. See [Knowledge Base](/sections/documentation/knowledge-base/overview) for how this appears in the product.
***
## Choosing the Right Type
* **Anyone in the org** → Help desk workflow
* **Only team members** → Team-only workflow
* **External systems** → Webhook-triggered workflow
* **No one (automatic)** → Scheduled or event-triggered workflow
* **When a user asks** → Help desk or team-only workflow
* **On a schedule** → Scheduled workflow
* **When something happens in another system** → Webhook-triggered workflow
* **When something happens in Serval** → Event-triggered workflow
* **Grants access to an application** → Access provisioning workflow
* **Removes access from an application** → Access deprovisioning workflow
* **Decides who should approve a request** → Custom approval workflow
* **Loads documents into the knowledge base from an API** → Knowledge ingestion workflow
* **Everything else** → Help desk, team-only, scheduled, or event-triggered
***
## Best Practices
Run manual tests before activating automatic triggers
Watch newly configured workflows closely for the first few days
Match execution scope to workflow type—event-triggered may need org-wide scope
Include trigger conditions in workflow descriptions for clarity