Approvals

Serval workflows can require approvals before or during execution, adding a layer of control for sensitive operations. Approvals are built as an ordered sequence of steps, and each step asks one or more approvers at once.

​

Overview

An approval procedure is a sequence of steps. Each step is sent to one or more approvers, and you decide per step whether all must approve or any one can approve. Within a step, an approver can be:

• A specific user
• A group, optionally with a quorum, such as “4 of 8 must approve”
• The requester’s manager
• A custom approval workflow that decides automatically based on your own logic, or escalates

The same builder powers both workflow approvals and access-policy approvals.

​

Add approvals to a workflow

Approvals appear as a Get approvals step in the workflow. On a new workflow (on-demand or form-submit triggers), click Add Approvers above the workflow to create the first step. Once steps exist, the Get approvals node summarizes its approvers, and selecting it reopens the builder. Both open the Workflow approval procedure dialog, where you configure who approves the workflow, step by step.

​

Build the steps

1. Click Add approval step and pick the approvers for that step. A single step can mix several approvers: specific users, groups, and the requester’s manager.
2. If a step has more than one approver, choose All must approve or Any one can approve.
3. For a group with two or more members, set a quorum: the number of members who must approve. The step then reads as N of M must approve.
4. Add more steps for sequential approval. Steps run in order, and each begins only after the previous one completes.

​

Notified vs. backup approvers

Each approver in a step is either notified or backup:

• Notified approvers are alerted when the step is pending and count toward satisfying it.
• Backup approvers aren’t notified but can still step in and approve.

Every step needs at least one notified approver. On an All must approve step, every approver is required, so they’re all notified.

​

Approver justification

Approvers can be asked to record a note when they decide. Set Approver justification to None, Optional, Required, Required to approve, or Required to deny. The approver enters the note when they approve or deny, and it’s captured wherever they act (Slack, Microsoft Teams, and the Serval inbox) and stored with the decision.

​

Self-approval

Control whether an approver can approve their own request. Toggle it per approver, or set Allow all approvers to self approve? for the whole procedure. When a step has a single approver, self-approval stays on so a request they submit isn’t left stuck.

​

Mid-run approvals

A workflow can pause partway through to collect an approval, rather than only gating before it starts. When the workflow reaches a Get approvals step, it holds until an approver responds, then resumes automatically. If an approver denies the request, the workflow stops.

• Approve at the right moment: Run initial steps first, then request approval only when the workflow reaches a decision point.
• Respond anywhere: Approvers respond in Slack, Teams, email, or the Serval web portal, and the request appears in their inbox.
• Choose who approves: Route to a specific user, a group, or the requester’s manager, and chain multiple approval steps together.

Use this when one workflow needs a human decision at a specific point without splitting the logic across separate workflows. Common examples include mid-run approvals for budget sign-offs, access escalations, and security reviews.

​

Delegation

Approvers can delegate their approval authority to another user or group, so requests keep moving when an approver is out. Delegation covers workflow approvals, access-request approvals, and ticket assignments.

• Set rules in user settings: Configure delegation from a user’s settings, not a workflow’s approver dialog. Each rule names the delegator and one or more delegates.
• Delegate to a user or a group: Route delegated approvals to a specific person or to any member of a group.
• Route automatically: When an approval would go to the delegator, Serval sends it to the delegate instead, with no manual reassignment.
• Also applies to ticket assignments: When a ticket would be assigned to the delegator, Serval routes it to their delegate instead.
• New approvals and assignments only: Only new approvals and assignments are delegated. Anything already assigned to the delegator stays with them.
• Keep a clear audit trail: The approval timeline shows who delegated and who made the final decision.
• Manage through the API: Create and manage delegation rules with the Serval public API.

​

Best practices

• Use groups with a quorum for scalability: Instead of listing individual users, add a group and set how many of its members must approve, so approval keeps working as the team changes.
• Pick the right step rule: Use Any one can approve when any qualified person can sign off, and All must approve when every named approver is required.
• Use manager approval for hierarchical sign-off: Add the requester’s manager as an approver when a request needs a reporting-line decision.
• Add backup approvers for coverage: Include backup approvers on a step so someone can still act when the notified approver is unavailable.
• Require justification for sensitive steps: Set approver justification to Required on high-impact steps to capture why each decision was made.
• Review self-approval carefully: Decide whether approvers should be able to approve their own requests based on your security requirements. When a single user is the only approver on a step, keep self-approval on so a request they submit isn’t left stuck.