What a workflow is

A workflow in Serval is deterministic TypeScript code generated from a plain-language description. It connects a trigger, defined inputs, approval logic, and actions executed across your connected integrations. It executes exactly as written, every time. The same onboarding workflow runs identically for employee 1 and employee 10,000.

Once built and published, the code lives in version control. You can read it, diff it, and hand it to a security reviewer the same way you'd review application code.

Start with an installable workflow

Before building from scratch, check whether a pre-built workflow already exists for your use case. Serval ships installable workflows for 30+ integrations, including Okta, Google Workspace, GitHub, Slack, AWS, Microsoft 365, and Jira.

Examples:

To find installable workflows: go to Applications, select a connected integration, and open the Workflows tab. Serval also surfaces suggestions based on your help desk activity automatically.

Installing a workflow creates an independent copy you can customize freely. Adjust inputs, approvals, execution scope, and workflow name before publishing. The original template isn't affected.

Serval's AI also analyzes your help desk activity and proactively suggests relevant workflows in Guidance → Suggestions and Workflows → Suggestions.

Building from scratch: write a clear prompt

When building a new workflow, describe the outcome in plain English. The Workflow Builder generates the TypeScript code and asks follow-up questions if it needs clarification.

What to include in your prompt:

• What the workflow should do

• Which systems are involved (Okta, Slack, GitHub, Workday, etc.)

• What should happen at decision points (approved, denied, timed out)

• Who gets notified and where

Example prompts:

• "Reset a user's password in Okta and send them a Slack DM with a temporary login link. Log the action in the ticket."

• "Every Monday at 9am, list all open tickets older than 7 days and post a summary to #it-ops in Slack."

• "When a user requests access to Salesforce, send a Slack DM to their manager for approval. If approved, add them to the Salesforce Standard User group in Okta. If denied or no response after 48 hours, notify the employee with the reason."

Start simple. Test, then add complexity through follow-up prompts in the builder chat: "Add an approval step before the Okta group assignment" or "Also send a confirmation to #it-ops when the workflow completes."

Define the trigger clearly and narrowly

Every workflow starts with a trigger. Choose based on who initiates it and when:

Keep triggers narrow. A password reset and a software installation request should be separate workflows, not branches inside one. Narrow workflows are easier to test, audit, and update when policies change.

Map required inputs before building logic

Before adding decision branches, identify what data the workflow needs to run correctly:

• What fields does the downstream integration require?

• Which values determine the approval path?

• What information affects routing or action sequence?

Input types:

Serval detects required inputs from your description and generates the form automatically. You can adjust input types, mark fields as required or optional, and add descriptions to guide users.

Two ways inputs are collected:

• Conversationally through the Help Desk Agent

• Structured form that appears as a catalog item when inputs are configured on the workflow (visible under New Request → Browse Catalog)

For sensitive workflows, enable form confirmation: users review all inputs on a summary screen before the workflow executes.

Use dropdowns instead of text fields whenever you have a known set of valid values. This prevents typos and ensures the downstream API receives consistent data.

Translate policy into conditional logic

Conditional logic encodes your access and operational policies into the workflow.

Examples:

• A request from a specific department routes to a designated approver

• A high-privilege access level inserts a multi-step approval chain

• A device type triggers a different integration action

Because workflows are TypeScript, conditions can reference any attribute available from your connected systems: requester department, employment type, location, prior access history, or anything in your IdP or HRIS. Policy lives in the code, not in runtime AI interpretation.

Clear, mutually exclusive conditions produce predictable execution paths. Overlapping conditions produce inconsistent results.

Insert approvals where policy requires oversight

Approvals are checkpoints embedded in the workflow before an action executes. They're hard-coded in, not optional at runtime.

Approval options:

• Individual users or groups: Route to one or more specific people. When multiple users or groups are selected, Serval draws from the combined pool.

• Manager approval: Automatically routes to the requester's manager.

• Multi-step chains: Require sequential approvals. Example: manager first, then security team, then IT lead.

• Custom approval workflow: Automate the approval decision itself. Auto-approve if the user had this access in the past 30 days, auto-deny if denied in the past 24 hours, otherwise route to the resource owner.

• Self-approval: Configure whether approvers who are also requesters can approve their own runs. Recommended to enable when a specified user is the sole approver, otherwise the workflow can't complete when that person submits the request.

Define behavior for both approval and rejection, including timeout handling. Every approval decision is logged with timestamp, approver, and outcome.

Use groups rather than individual users for approval steps wherever possible. As your team changes, you update the group, not every workflow.

Sequence actions deliberately across integrations

Actions are the execution layer. They interact with your connected systems to complete the task.

Serval supports:

• Native integration actions: Pre-built actions from connected apps (Okta, Slack, GitHub, Google Workspace, Workday, and others)

• Custom actions: Call any external API endpoint not covered by a native integration

Design action order intentionally:

1. Execute the primary system change

2. Update related records if needed

3. Notify stakeholders

Workflows can never exceed the API scopes set at integration setup, regardless of what the code says. If the Google Workspace integration is scoped read-only on user profiles, no workflow can write to it.

Control who can build and who can run

Who can build: Only team members with Builder or Manager roles can create or modify workflows. Only Managers can configure integrations and team settings. A regular IT agent using the help desk can't reach the building layer. This is enforced, not advisory.

Who can run (execution scope):

Execution scope also determines which Slack channel modes can surface a workflow:

Add approval steps to org-wide workflows that touch sensitive systems. Even if any employee can trigger the request, the action won't execute until the right person approves it.

Test before publishing

Run the workflow manually before publishing. The run panel shows each step's execution status, the input and output at every step, and any errors with detail.

If a workflow fails, Serval gives you two ways to diagnose it:

1. Run history: Step-by-step breakdown showing which step failed, the error message, and the inputs and outputs at that step. Common causes: expired API credentials, missing resources, permission gaps, rate limiting.

2. Workflow builder agent: Ask the builder chat directly ("Why did this workflow fail?" or "What went wrong in the last run?"). The agent searches the 10 most recent runs, identifies failures, and surfaces the exact error with suggested fixes. No need to copy run IDs or navigate the Runs tab manually.

Version control and audit

Every published change is tracked with a version number, timestamp, and who published it. To restore a previous version: open the version history, select the version, and click Restore. Restoring creates a new version at the top of the history — it doesn't overwrite or delete any existing versions.

Every workflow run produces a complete execution record: inputs, outputs, approvals, and status at each step. This log is exportable and serves as audit evidence for compliance reviews.

Common audit workflows you can build:

• Weekly run report: List all workflow runs from the past 7 days, generate a CSV with workflow name, workflow ID, run ID, status, started at, completed at, triggered-by, and duration, and post to #it-ops

• Access change audit: Every Friday, pull all provisioning and deprovisioning runs from the past week, generate a CSV with user email, application, action, approver, and timestamp, and post to #security

• Approval turnaround report: Weekly summary of approval times and any approvals that took longer than 24 hours

These cover SOC 2 evidence generation, change management, access reviews, and incident response.

Review workflows as systems and policies evolve

Workflows encode operational logic at a point in time. When integrations change, access policies update, or team structures shift, workflows should be reviewed.

Common updates:

• Modifying approval assignments when org structure changes

• Adjusting conditional rules when policies update

• Updating integration mappings when APIs change

• Removing unused branches that no longer reflect real scenarios

Periodic review keeps workflows accurate and reduces the risk of stale logic executing against current systems.