Reclamations

Reclamation removes application access that people have stopped using, so unused access doesn’t linger as standing risk. Serval tracks when each user last signed in to a connected app. When a grant sits unused past a threshold you set, Serval either reclaims the access automatically or routes it to a reviewer to decide. Every reclaim runs through the role’s normal deprovisioning method and is logged.

​

How reclamation works

Reclamation runs on your access grants (one user holding one role) for roles that have a reclamation policy attached:

1. Serval syncs last-login data from the app, or from the identity provider that fronts it, so it knows when each user last signed in. Where you turn this on depends on how the role is provisioned (see Step 1).
2. A background sweep flags unused grants. On a recurring schedule, Serval finds grants whose last login is older than the policy’s inactivity threshold and turns each one into a reclamation candidate.
3. The policy decides what happens next:
   • No reviewers on the policy: the grant is reclaimed automatically (auto-reclaim).
   • One or more reviewers on the policy: the candidate goes to those reviewers, who reclaim or dismiss it.
4. Reclaiming deprovisions the access using the role’s existing provisioning method and opens a reclamation ticket you can follow. Dismissing keeps the access and closes the candidate.

Serval never removes access on its own unless the policy is set to auto-reclaim (no reviewers). With reviewers, nothing is deprovisioned until someone decides.

​

Who can manage reclamation

• Turning on Last Login Sync requires an organization admin.
• Creating reclamation policies, attaching them to roles, and using the Reclamations page require the View Settings permission, which Managers and org admins have. See Permissions.

Setting up reclamation is three steps: sync last-login data, create and attach a reclamation policy, then reclaim on the Reclamations page.

​

Step 1: Turn on last login sync

Reclamation decides whether a grant is unused from each user’s last sign-in to the app the role is on. Serval reads that sign-in from one of two places depending on how people reach the app, so turn last login sync on wherever the sign-ins actually live. Only organization admins can change these settings.

​

Access provisioned through your identity provider (linked groups)

When a role is provisioned with a linked group (for example, granting an app by adding the user to an Okta or Microsoft Entra ID group), people reach the app through your identity provider’s single sign-on, and the app itself never reports the sign-in. Your IdP does. Turn on Last Login Sync on the identity provider, not on the downstream app. For a downstream app’s sign-ins to count, that app must be connected in Serval and matched to its entry in the identity provider (Serval links the two during app ingestion). Until an app is matched, its sign-ins are held aside and don’t count toward reclamation, so connect the app before you rely on it.

​

Access provisioned directly on the app

When a role is provisioned directly on the app (its own API, a built-in workflow, or a manual task) rather than through an IdP group, the sign-in signal has to come from that app. Configure last login on the app instance itself. Repeat for every app or identity provider whose access you want to reclaim.

​

Step 2: Create and attach a reclamation policy

A reclamation policy sets when unused access is reclaimed and who (if anyone) reviews it first. You attach a policy to a role to turn reclamation on for that role. A role with no policy attached is never reclaimed.

​

Create a policy

You can create a policy from Settings → Reclamation Policies, or inline while attaching one to a role (both open the same dialog). On the Reclamation Policies page, click Create policy and fill in:

• Policy Name and Policy Description: a name and a short note about when to use this policy.
• Reclaim after (days of inactivity): the inactivity threshold. A grant becomes due for reclamation once its last login is older than this many days. Defaults to 90.
• Require a justification on each decision (Yes / No): whether a reviewer must add a justification with every decision.
• Allow users to review their own access (Yes / No): whether a reviewer can decide on their own grant.
• Reviewers: the reviewer steps that decide on candidates before access is revoked.

Click Create policy to save. You can edit or delete a policy later from the same page. A policy that’s still attached to one or more roles can’t be deleted until you detach it.

​

Attach a policy to a role

​

Step 3: Reclaim on the Reclamations page

Open Access → Reclamations to review candidates and act on them. The page has an Overview with candidate stats (candidates reclaimed, candidates dismissed, and your reclamation rate) and a Reclamation candidates table split into two tabs.

​

In review

The In review tab lists candidates awaiting your decision, one row per grant, with the User, the Role, and their Last login. For each row, choose:

• Reclaim: deprovision the access. Serval revokes the grant using the role’s provisioning method and opens a reclamation ticket.
• Dismiss: keep the access and close the candidate.

Select multiple rows to reclaim or dismiss them in bulk. Use the All integrations filter and the search box to narrow the list by app, resource, or role. If the policy requires a justification, you’ll be asked for one before your decision is recorded.

​

Completed

The Completed tab shows candidates that have been concluded, with a Status and who decided them under Reviewed by:

• Reclaiming: deprovisioning is in progress.
• Reclaimed: a reviewer reclaimed the access and deprovisioning finished.
• Auto-reclaimed: the policy had no reviewers, so Serval reclaimed the grant automatically after the inactivity threshold. Reviewed by shows System.
• Dismissed: a reviewer chose to keep the access.
• Failed: deprovisioning didn’t complete. Open the linked ticket to see what went wrong.

From a reclaimed, in-progress, or failed status, you can open the reclamation ticket to see the full deprovisioning timeline (flagged as unused, deprovisioning queued, deprovisioning, and access reclaimed or reclaim failed).

​

Related