> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serval.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Admin Quickstart

> Set up just-in-time access management for your applications in minutes

Set up just-in-time (JIT) access management to control who requests application access, duration limits, approvovals, and provisioning methods. [Connect an application](#1-connect-an-application),
[configure roles](#2-configure-roles),
[test requests](#3-test-access-requests),
then [audit and monitor access](#4-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](https://docs.serval.com/sections/integrations/overview).

<CardGroup cols={2}>
  <Card title="Pre-built integrations" icon="plug">
    Use Serval's native integrations for common applications like GitHub, Slack, AWS, and more
  </Card>

  <Card title="Custom integrations" icon="code">
    Build a custom integration for applications not in our library
  </Card>
</CardGroup>

<Tip>
  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 an app" and fill in the name of the app as a placeholder for a full integration connection.
</Tip>

<Note>
  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.
</Note>

***

## 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:

<CardGroup cols={2}>
  <Card title="Application roles" icon="window">
    Configure role access to an application under "Applications"

    **Example:** Admin, Member, Viewer or Billing Manager access to GitHub
  </Card>

  <Card title="Resource roles" icon="folder-tree">
    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
  </Card>
</CardGroup>

### Configure roles three ways

Serval offers [manual role setup](#manually-configuring-roles) (most common),
[importing roles from your IdP](#importing-roles-from-your-idp),
and [auto-filled roles](#auto-filled-roles).

### Manually configuring roles

Navigate to the relevant team from the sidebar, click **Applications**, then select the relevant application.

<Tip>
  **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.
</Tip>

**Creating roles**

<Steps>
  <Step title="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
  </Step>

  <Step title="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
  </Step>

  <Step title="Set up access controls">
    Configure the following for each role:

    * [**Access Profiles**](https://docs.serval.com/sections/access-management/configuration/access-profiles)**:** Which groups can request this role
    * [**Access Policies**](https://docs.serval.com/sections/access-management/configuration/access-policies)**:** Rules for access requests (duration, business justification, approval process)
    * [**Provisioning Methods**](https://docs.serval.com/sections/access-management/configuration/access-provisioning)**:** How access is granted (manual task, SCIM, custom workflow, API)
  </Step>
</Steps>

### Importing roles from your IdP

Once you've [connected an IdP](https://docs.serval.com/sections/access-management/configuration/connect-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.

<Note>
  **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.
</Note>

<Steps>
  <Step title="Submit a test request">
    Request access to one of your configured roles through Slack, Teams, or the Serval interface
  </Step>

  <Step title="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
  </Step>

  <Step title="Refine as needed">
    Adjust policies, profiles, or provisioning methods based on test results
  </Step>
</Steps>

***

## 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](/sections/access-management/reviews/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](/sections/access-management/configuration/access-profiles) and [access policies](/sections/access-management/configuration/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

<AccordionGroup>
  <Accordion title="IdP groups as resources">
    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.
  </Accordion>

  <Accordion title="Applications to exclude from access management">
    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.
  </Accordion>
</AccordionGroup>

***

## 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

<CardGroup cols={2}>
  <Card title="Connect your IdP first" icon="link">
    Leverage existing group structures and enable Linked Group provisioning
  </Card>

  <Card title="Centralize to fewer teams" icon="layer-group">
    Manage applications with the fewest teams possible for easier management and auditing
  </Card>

  <Card title="Create reusable policies" icon="copy">
    Maintain consistency across roles with common access patterns
  </Card>

  <Card title="Verify with test requests" icon="vial">
    Test each role configuration before rolling out to your organization
  </Card>

  <Card title="Review logs regularly" icon="chart-line">
    Identify opportunities for automation and policy refinement
  </Card>
</CardGroup>

## **FAQs**

<AccordionGroup>
  <Accordion title="Is Serval a Privileged Access Manager (PAM)?">
    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.
  </Accordion>

  <Accordion title="What's the difference between Access Profiles and Access Policies?">
    **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?"
  </Accordion>

  <Accordion title="Does Serval replace my identity provider (IdP)?">
    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.
  </Accordion>

  <Accordion title="How long does it take for access to be provisioned?">
    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
  </Accordion>

  <Accordion title="What happens when temporary access expires?">
    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.
  </Accordion>

  <Accordion title="Can I use different provisioning methods for different roles in the same app?">
    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.
  </Accordion>

  <Accordion title="What's the difference between a resource and a role?">
    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.
  </Accordion>

  <Accordion title="Can Serval manage access to Slack channels or Google Groups?">
    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.
  </Accordion>

  <Accordion title="Do I need to configure every application role in Serval?">
    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.
  </Accordion>

  <Accordion title="What if an application doesn't have an API or IdP integration?">
    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.
  </Accordion>

  <Accordion title="Can I set different approval requirements for the same role based on who's requesting?">
    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.
  </Accordion>

  <Accordion title="Can users extend their access before it expires?">
    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.
  </Accordion>

  <Accordion title="Can approvers change the requested duration?">
    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.
  </Accordion>

  <Accordion title="What happens if a user amends their request before approval?">
    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.
  </Accordion>

  <Accordion title="What happens if no approval procedure is configured?">
    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.
  </Accordion>
</AccordionGroup>