Skip to main content
Set up just-in-time (JIT) access management to control who requests application access, duration limits, approvovals, and provisioning methods. Connect an application, configure roles, test requests, then audit and monitor access. Repeat this process for every application you want to manage. With access management, enforce least-privilege, role-based access control.

​
1. Connect an Application

Connect the first application you want to manage. You can find instructions for each application in the integrations overview.

Pre-built integrations

Use Serval’s native integrations for common applications like GitHub, Slack, AWS, and more

Custom integrations

Build a custom integration for applications not in our library
If you only want to use an application for access management and don’t need it for workflows, you can create a lightweight connection without setting up the full integration. Click “Connect Custom App” and fill in the name of the app as a placeholder for a full integration connection.
If you haven’t set up your Slack or Teams integration as a help desk yet, we recommend doing this now. You can use it to test roles and permissioning more efficiently.
Add application to Serval

​
2. Configure Roles

Navigate to the application you’d like to configure access to and identify which roles you’d like to configure first.

​
Access layers

In Serval, you can configure role access at two levels:

Application roles

Configure role access to an application under “Applications”Example: Admin, Member, Viewer or Billing Manager access to GitHub

Resource roles

Create a custom resource and configure role access within it under “Resources”Example: Add the engineering GitHub team as a resource and set up roles within that team
Add role for application and resource

​
Configure roles three ways

Serval offers manual role setup (most common), importing roles from your IdP, and auto-filled roles.

​
Manually configuring roles

Navigate to the relevant team from the sidebar, click Applications, then select the relevant application.
Best Practice: Connect your IdP before provisioning access. This lets you provision access via Linked Groups, which automatically adds and removes users from IdP groups as access is granted and expires.
Creating roles
1

Add a new role

  • For application roles: Click “New Role” in “App Access”
  • For resource roles:
    • Click “Create a Custom Resource,” fill in the Name and Description, then click “New Role” in that resource
    • Click into an existing resource and click “New Role” in that resource
2

Configure role details

  1. Name the role (e.g., Member, Admin, Editor)
  2. Add a description of what type of access this is. Serval will use this to guide users to the right access level
3

Set up access controls

Configure the following for each role:

​
Importing roles from your IdP

Once you’ve connected an IdP to Serval, Serval will populate suggested roles based on the groups you have set up in that IdP.
  1. Serval matches IdP group names to potential roles and lets you import them.
  2. After importing a role, configure provisioning through Linked Groups, Custom Workflows, or Direct (via API).

​
Auto-filled roles

For Linear and Ramp, Serval automatically identifies default application roles and adds them upon connection.
  • Navigate to the application
  • Configure each auto-filled role with the appropriate profiles, policies, and provisioning methods.

​
3. Test Access Requests

Use your configured help desk (or the ticketing system in app.serval.com) to verify your setup works as intended.
Recommended testing approach: Set up your Slack or Teams integration first if you haven’t already. Testing through conversational interfaces is faster and mirrors how users will actually interact with the system. You can verify the complete flow—request, approval routing, provisioning, and notifications—in a single thread.
1

Submit a test request

Request access to one of your configured roles through Slack, Teams, or the Serval interface
2

Verify the workflow

Check that:
  • The request routes to the correct approver
  • Business justification requirements work as expected
  • Access is provisioned correctly
  • Temporary access expires on schedule
3

Refine as needed

Adjust policies, profiles, or provisioning methods based on test results

​
4. Audit and Monitor Access

Once your access management system is in use, monitor access and view access logs to ensure compliance and identify potential security issues. Learn more about access reviews here.

​
5. Manage Profiles and Policies Centrally

Manage profiles and policies centrally to maintain uniform access controls across your organization. See access profiles and access policies for details. Navigate to the relevant team, click the ”…” button at the top right corner of the relevant team you’re managing, then select “access profiles” or “access policies.” From this view, you can:
  • Set default profiles and policies
  • Configure centralized access controls
  • Manage role assignments

​
Special Cases

Upon connecting your IdP, Serval ingests all groups from that IdP and stores them as resources with a “member” default role. These resources function as groups across Serval and are not treated as standard resources.
You should not manage role access through Serval for:
  • Slack channels
  • Google groups
  • Okta groups
  • Email distribution lists
Manage these through workflows, not access management. Manual configuration for each group doesn’t scale. Rely on IdP audits for full access trails.

​
Example Scenario: Starter use case for access management

Your organization uses Okta, Google, Slack, and GitHub. Your Engineering team uses AWS databases.
  1. Connect your IdP and help desk to Serval
  2. Configure application and resource access for company-wide and team-specific resources
  3. Define access policies with approval workflows and provisioning methods
Example: GitHub access configuration Your IT team manages GitHub application access for the entire company. Your Engineering team controls access to specific repositories and teams. Company-wide access
  • Name: GitHub - Member
  • Description: Standard user access
  • Policy: Indefinite access, no approval required
  • Provisioning: Linked Group - add user to “Engineering” group in Okta
Team-specific access
  • Name: GitHub Engineering Team - Administrator
  • Description: Full admin access to manage repos in GitHub Engineering Team
  • Policy: Seven-day temporary access, requires Engineering Manager approval
  • Provisioning: API provisioning through GitHub

​
Best practices

Connect your IdP first

Leverage existing group structures and enable Linked Group provisioning

Centralize to fewer teams

Manage applications with the fewest teams possible for easier management and auditing

Create reusable policies

Maintain consistency across roles with common access patterns

Verify with test requests

Test each role configuration before rolling out to your organization

Review logs regularly

Identify opportunities for automation and policy refinement

​
FAQs

Serval delivers Just-In-Time Privilege Access for databases, cloud roles, and application admin roles. Serval is adjacent to PAM but not a replacement for PAM’s vaulting/session recording.
Access Profiles determine who can request access (eligibility). Access Policies define the rules for those requests (approval requirements, duration limits, business justification). Think of profiles as “Can I ask?” and policies as “What do I need to provide?”
No. Serval sits on top of your existing IdP (Okta, Azure AD, Google Workspace) and uses it for provisioning. Serval manages the access request workflow while your IdP continues handling authentication and group membership.
It depends on the provisioning method:
  • Direct provisioning: Seconds
  • Linked Groups: 15 minutes to 1 hour, depending on your IdP’s sync schedule
  • Custom Workflows: Varies based on workflow complexity
  • Manual provisioning: Depends on human response time
Serval automatically revokes access using the same provisioning method. For Linked Groups, Serval removes the user from the IdP group. For Direct provisioning, Serval calls the API to revoke access. For Manual provisioning, Serval creates a removal task for the application owner.
Yes. You might use Linked Groups for common member access, Direct provisioning for team-specific roles, and Manual provisioning for highly sensitive admin access—all within the same application.
A resource is a grouping within an application (like a GitHub team or Slack channel). A role is the permission level within that resource (like Member, Admin, or Owner). Every app has a default “App Access” resource for baseline application access.
While technically possible, it’s not recommended. Managing individual channels or groups through Serval access management would require extensive manual configuration. These are better managed through custom workflows. For full audit trails of these resources, rely on your IdP logs.
No. Start with high-value, high-frequency access requests. Common starting points include admin roles, temporary database access, and sensitive application access. You can always add more roles as adoption grows.
Use Manual provisioning. Serval creates a task for the application owner to grant access manually. While not automated, this still centralizes the request and approval workflow and provides an audit trail.
Yes, through Access Profiles. You can create multiple profiles for the same role with different eligibility criteria and approval requirements. For example, engineers might auto-approve for database access while contractors require manager approval.
Yes. Users can request extensions to active access at any time, even while access is still being provisioned. Extension requests follow the same approval workflow as initial requests. Users can also shorten their access duration if they finish early.
Yes. Approvers can approve requests for a different duration than what was requested. For example, if a user requests 2 hours of access, an approver can approve it for 30 minutes instead. This applies to both initial requests and extension requests.
The amended request replaces the original pending request. If a user amends multiple times before approval, only the final amendment is what the approver sees. Earlier amendments are automatically superseded.
Requests auto-approve with the requested duration. This also applies to extension requests. If you want all requests to require approval, make sure to configure at least one approver in your access policy.