Skip to main content
This guide explains the key concepts you’ll use when setting up access management in Serval.

​
Access Layers

Understanding how Serval organizes access helps you configure it effectively. Apps, Resources, and Roles Serval organizes access in a three-level hierarchy: Every app has a default resource called “App Access” that controls baseline access to the application itself. You can then create custom resources for finer-grained control.
Example: In GitHub, “App Access” controls whether someone can use GitHub at all. A custom resource for the “Engineering” team controls who can access that specific team’s repositories, with roles like “Member” or “Maintainer.”

​
Profiles vs. Policies vs. Provisioning

Similar-sounding terms do different things:
  • Access Profiles = Who can request access (eligibility)
  • Access Policies = Under what rules they can request it (approval, duration, justification)
  • Provisioning = How am I going to get the user into that particular role
Think of profiles as the gate (“Can I even ask?”) and policies as the rules once you’re through the gate (“What do I need to provide?”). Application Role Example: A developer requests GitHub (application) —> Member (role) Resource Role Example: A developer requests GitHub (application) → Engineering Team repo (resource) → Write access (role)

​
Role Configuration

Access control in Serval uses three components that work together:
Access Profile → Access Policy → Provisioning Method(Who can request) → (What rules apply) → (How access is granted and removed)
1

Profile checks eligibility

When a user requests a role, Serval checks if they belong to a group in the Access Profile
2

Policy applies rules

If eligible, the Access Policy determines duration, justification requirements, and approval workflow
3

Provisioning grants access

Once approved, the Provisioning Method actually grants the access (via IdP group, API, workflow, or manual task)
4

De-provisioning removes access

Once the duration of access from the access policy has expired, the user is removed from role

​
Quick Reference

A resource is what you’re accessing (e.g., the Engineering Team in GitHub).A role is the permission level within that resource (e.g., Write access to the Engineering Team).
No. Simple applications can use just “App Access” as a single resource. Only create additional resources if you need to manage access to specific teams, channels, or subdivisions.
Yes. Profiles and policies are designed to be reused. Create them once and apply them to multiple roles for consistency.
Yes. Members with App Builder or Manager permissions on the owning team can delete custom roles. In Manage Access, open the role, select its delete control, and confirm. The custom resource remains available to members with permission to edit it or add another role. Imported roles and the last built-in App Access role remain protected from deletion through these controls.
You can update the provisioning method for a role at any time. This only affects future access requests. Existing access continues using the original method.