Skip to main content
Provisioning methods determine how Serval grants access once a request is approved. Choose the method that best fits your technical setup and security requirements.

​
Understanding Provisioning Method Selection

​
The Four Provisioning Methods

Serval offers four ways to grant access:
Provisioning method configuration showing Linked Groups, Custom Workflow, Direct, and Manual options

Configure access provisioning method for a role

​
Common Provisioning Scenarios

Best method: Linked GroupsWhy: Simple app-level access, likely already using Okta or similar IdP for SSOSetup:
  1. Create “App-Asana-Users” group in Okta
  2. Configure Okta to provision Asana based on group membership
  3. In Serval, link the “Member” role to this Okta group
  4. When users request Asana access, Serval adds them to the group
  5. Okta syncs the change to Asana (typically within 15 minutes)
  6. When access expires, Serval removes them from the group
Best method: Direct provisioning or Custom WorkflowWhy: GitHub teams are resources within GitHub, not separate appsSetup with Direct:
  1. Create “Engineering” as a custom resource in Serval
  2. Configure “Member” and “Maintainer” roles with direct provisioning
  3. Serval uses GitHub API to add/remove users from the team
  4. Access granted in seconds
Setup with Workflow (if you need approval notifications):
  1. Create workflow that calls GitHub API to add user
  2. Send Slack notification to team lead
  3. On expiration, call API to remove user
Best method: Custom WorkflowWhy: Multi-step process with dependenciesSetup:
  1. User requests AWS access
  2. Workflow creates Linear task: “Purchase AWS license”
  3. Workflow opens GitHub PR to Terraform config
  4. Workflow waits for Linear task completion
  5. Auto-merge PR when task marked done
  6. Apply Terraform to grant actual AWS access
Best method: Manual ProvisioningWhy: No automation possible yetSetup:
  1. Configure manual provisioning with clear instructions
  2. Assign tasks to tool owner
  3. Owner manually adds user in the tool
  4. Owner marks task complete in Serval
  5. For temporary access, Serval creates removal task when access expires
Plan to automate: As request volume grows, consider building a custom workflow with the tool’s database or building an API.

​
Different Provisioning Strategies in a Single Application

You can use different provisioning methods for different roles in the same application. Example: GitHub
  • App-level “Member” access → Linked Groups (via Okta)
  • Team-specific “Maintainer” access → Direct provisioning (via GitHub API)
  • Organization “Owner” access → Manual provisioning (too sensitive to automate)
This approach balances automation for common requests with control for sensitive access.

​
Linked Groups

Access granted by adding the user to a group in your Identity Provider (Okta, Google, Rippling, Entra). When access expires, the user is automatically removed.

​
How It Works

1

Request approved

User requests access and it’s approved per the access policy
2

Serval adds to group

Serval automatically adds the user to the specified IdP group
3

IdP provisions access

Your IdP’s existing rules provision the actual application access
4

Automatic removal

When access expires, Serval removes the user from the IdP group
Example: Add the user to the “GitHub-Engineering” group in Okta. Okta’s SCIM integration then grants GitHub access. After seven days, Serval removes the user from the group.

​
Who Holds a Linked Role

A role’s linked groups also tell Serval who holds it: anyone who is a member of every linked group appears on the role’s roster, whether Serval added them or they were already in the group when it synced. Removing the user from the group removes them from the role. When an access-review revocation or unused-license reclamation removes a role someone holds through linked groups, Serval removes them from those groups, whatever the role’s provisioning method. The review’s grant details show that the seat is held via linked groups and which groups confirm it. Linked groups can be configured on a role that uses any provisioning method. Turn off Members of every linked group hold this role on the role’s Configure tab to make the links provisioning-only, so that only users granted the role through Serval count as members. Use this for bundle roles like an on-call role that provisions several admin roles at once.

​
When to Use Linked Groups

✓ Use when

  • Your IdP already provisions access via groups
  • You want automatic cleanup when access expires
  • You need audit trails in your IdP
  • You’re managing access to multiple apps with one group

✗ Don't use when

  • The application doesn’t integrate with your IdP
  • You need more complex provisioning logic
  • Group membership would grant too much access

​
Custom Workflow

Access granted through a custom process—like using an API to send an email invite or opening a GitHub PR for a Terraform change.

​
How It Works

You define a workflow that Serval executes when access is granted. Workflows can include multiple steps, conditional logic, and integrations with various tools. Read more about how to set up custom access workflows here.

​
Examples

Add or remove users from a GitHub team that controls repository access.Steps:
  1. Use GitHub API to add user to team
  2. Send Slack notification to user and team lead
  3. On expiration, remove user from team
Open a GitHub PR for Terraform group membership, create a Linear task to purchase a license, auto-merge the PR when the task is complete.Steps:
  1. Create Linear task: “Purchase AWS license for [user]”
  2. Open GitHub PR to add user to Terraform AWS group
  3. Wait for Linear task completion
  4. Auto-merge GitHub PR
  5. Apply Terraform to grant actual AWS access
Coordinate access across multiple systems during employee onboarding.Steps:
  1. Create accounts in internal apps
  2. Send welcome email with credentials
  3. Add to Slack channels
  4. Create onboarding tasks in project management tool
  5. Schedule follow-up check-in with manager

​
When to Use Custom Workflows

✓ Use when

  • You need multi-step provisioning processes
  • Access requires API calls to multiple systems
  • You want to coordinate with other tools (Linear, GitHub, etc.)
  • Your provisioning logic has conditional branches

✗ Don't use when

  • A simpler method (Linked Groups or Direct) would work
  • You’re not comfortable building workflows
  • The process is entirely manual anyway

​
Direct Provisioning

Pre-built API provisioning for common applications. Serval uses the application’s API to grant access directly.

​
How It Works

1

Request approved

User requests access and it’s approved per the access policy
2

Serval calls API

Serval makes an API call directly to the application to grant the specified role
3

Access granted immediately

The user receives access within seconds, no manual intervention needed
4

Automatic removal

When access expires, Serval calls the API again to revoke access
Example: When a user requests Ramp admin access, Serval automatically calls the Ramp API to grant the admin role. After the access period expires, Serval revokes it via the same API.

​
Supported Applications

Direct provisioning is available for select applications with robust APIs.

​
When to Use Direct Provisioning

✓ Use when

  • The application supports direct provisioning in Serval
  • You want fully automated provisioning without IdP groups
  • The application isn’t connected to your IdP
  • You need immediate access grants

✗ Don't use when

  • The application doesn’t support direct provisioning yet
  • You prefer provisioning through IdP groups for consistency

​
Manual Provisioning

Access granted through a task assigned to the application owner (via ticket or Slack). A human manually grants the access. When you select a group configured as an assignment group for the task’s team, that group owns the provisioning and removal tasks. The team’s Group member assignment setting controls individual assignment: Human triage leaves the task with the group until someone claims it; Round-robin also assigns a group member. If you select multiple groups, the first group is the assignment target. To use group ownership, add the group through the team’s assignment rules, default assignment, or Ticket sidebar groups before selecting it for manual provisioning. Other org groups continue to select an individual member.
Instead of naming a user or group, you can leave the provisioner Unassigned. Serval then creates the provisioning task with no assignee, so it follows the team’s normal ticket assignment rules. Unassigned and named assignees are mutually exclusive.

​
How It Works

1

Request approved

User requests access and it’s approved per the access policy
2

Task created

Serval creates a task in your ticketing system or Slack assigned to the application owner
3

Owner grants access

The assigned person manually grants access in the application
4

Task marked complete

The owner marks the task complete in Serval
5

Removal task (for temporary access)

If access is temporary, Serval creates another task to remove access when it expires
Example: Jeff requests editor access to Linear. Serval creates a ticket assigned to the Linear admin. The admin adds Jeff as an editor and marks the task complete. For 12-hour temporary access, Serval creates a second task 12 hours later to remove Jeff’s access.

​
When to Use Manual Provisioning

✓ Use when

  • The application has no API or IdP integration
  • Provisioning requires human judgment
  • The process is very infrequent
  • You’re still building automation

✗ Don't use when

  • You have high-volume access requests
  • Faster automated methods are available
  • Manual intervention creates bottlenecks

​
Choosing the Right Method

Use this decision tree to select the best provisioning method:
1

Is this app connected to your IdP with SCIM or group-based provisioning?

Yes → Use Linked Groups
  • Most auditable approach
  • Works across multiple apps consistently
  • Best for apps your entire company uses
No → Continue to next step
2

Does Serval support direct provisioning for this app?

Yes → Use Direct Provisioning
  • Fully automated
  • Access granted in seconds
  • No IdP dependency
No → Continue to next step
3

Do you need multi-step logic, external tool integration, or conditional provisioning?

Yes → Use Custom Workflow
  • Most flexible option
  • Can coordinate across multiple systems
  • Handles complex approval chains
  • Requires workflow building skills
No → Continue to next step
4

Default to Manual Provisioning

Use Manual Provisioning when:
  • No automation options are available yet
  • Access requests are infrequent (< 5 per month)
  • You’re building automation but aren’t ready yet
Important: Document clear instructions for the person granting access. Plan to automate as request volume grows.

​
Start Simple, Then Automate

Don’t feel pressure to automate everything immediately. A pragmatic approach:
  1. Week 1: Set up manual provisioning for all apps to establish the request → approval flow
  2. Week 2: Convert high-volume apps to Linked Groups or Direct provisioning
  3. Month 2: Build custom workflows for complex provisioning scenarios
  4. Ongoing: Automate manual processes as volume increases
Manual provisioning today is better than delayed automation that never ships.

​
Best Practices

Name IdP groups consistently

Use clear naming conventions for groups linked to Serval roles. Pattern: App-[ApplicationName]-[RoleName]Examples: App-GitHub-Members, App-Asana-Admins, App-Figma-EditorsThis makes it obvious which groups are managed by access requests and easier to audit.

Prefer automated methods

Start with Linked Groups or Direct Provisioning when possible. They scale better and reduce manual work.

Use IdP groups consistently

Linked Groups provide the best audit trail and work across multiple applications simultaneously.

Document manual processes

If you must use manual provisioning, write clear instructions for the person who will grant access.

Plan to automate

Start with manual provisioning if needed, but plan to build workflows or integrations as volume grows.

Consider deprovisioning complexity

The same method that provisions access must deprovision it. If you use a custom workflow to grant access, make sure it can also revoke access cleanly when time expires. Test the full lifecycle, not just the grant.