Workflow Types

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

---

​

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

---

​

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

​

Common schedules

---

​

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

---

​

Event-Triggered Workflows

Event-triggered workflows run automatically when specific events occur within Serval—like a ticket being created, access being granted, or a workflow completing. 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
• Sending notifications when access is granted
• 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

​

Setting up event triggers

---

​

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 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”

---

​

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.”

---

​

Choosing the Right Type

---

​

Best Practices