Identifying shelfware is the easy part. Recovering it is the part that fails. Most Salesforce customers we work with have at one point or another stood up a license-utilization report, identified a meaningful population of dormant users, and circulated a remediation plan—only to discover six months later that the plan stalled, the dormant population grew, and the renewal commercial outcome reflected the same shelfware exposure that the report had previously surfaced. The failure mode is not analytical; the failure mode is operational. Reclamation requires sustained workflow execution against dozens or hundreds of dormancy events per month, across multiple manager populations, with exception handling for every edge case, and that workflow does not survive on quarterly manual review. It survives on automation.
This article defines the automated license reclamation workflow—the dormancy detection logic, the manager-confirmation gate, the lifecycle transition mechanics, the exception handling, and the operational governance that keeps the workflow running quarter after quarter. The framing is vendor-neutral and buyer-side, drawing on the operational patterns that recur across enterprise Salesforce footprints. The workflow is technically implementable in native Salesforce (Flow, Approval Processes, scheduled Apex) or in an external orchestration layer (the IT service management system, the identity governance platform, or a custom automation built against the Salesforce APIs); the workflow logic is platform-agnostic.
The five workflow stages
The automated reclamation workflow consists of five sequential stages, each with explicit entry criteria, processing logic, and exit conditions. The stages are designed to be triggered by dormancy events surfaced through the [[shelfware-dashboard-template]] reporting, with the workflow handling each event from detection through reclamation or exception resolution.
Stage 1: Dormancy detection
The dormancy detection stage runs on a weekly cadence, querying the Salesforce LoginHistory and EventLogFile objects against the entitled user inventory. A user enters the dormancy detection stage when one of three dormancy conditions is satisfied: zero logins in the trailing 60 days (deep dormancy); fewer than 4 logins per month across the trailing 90 days (active-but-dormant against the Sales Cloud threshold); or zero meaningful feature utilization for entitled add-ons across the trailing 90 days (add-on dormancy). Each dormancy event is captured as a workflow record with the user identity, the dormancy condition, the entitled license, the manager, the business unit, and the dormancy duration.
Stage 2: Manager confirmation
The manager confirmation stage routes the dormancy event to the user's direct manager with a structured confirmation request. The request specifies the user, the entitled license, the dormancy condition, the proposed reclamation action (deactivate, downgrade edition, or remove add-on), and the response options (confirm reclamation, defer with operational justification, escalate to business unit leadership). The confirmation request includes a response deadline (typically 10 business days) and an automated escalation if the deadline lapses without response. The default behavior on lapsed escalation is reclamation, with documented escalation history—the default-to-reclaim posture is the single most important operational design decision in the workflow.
Stage 3: Reclamation execution
The reclamation execution stage applies the confirmed reclamation action against the Salesforce user record. The action varies by reclamation type: deactivation sets the User record to Inactive and releases the assigned license to the pool; edition downgrade reassigns the user to a lower-tier license and releases the higher-tier license to the pool; add-on removal removes the PermissionSet or PermissionSetGroup that grants the add-on capability and releases the add-on license to the pool. The execution stage captures the reclamation event in the workflow log, with the before-and-after license state, the operational justification, and the reclamation timestamp.
Stage 4: Lifecycle transition
The lifecycle transition stage handles the operational handoff that follows the reclamation action. For deactivation, the lifecycle transition includes the ownership-reassignment workflow (opportunities, accounts, cases, tasks) and the related-record cleanup. For edition downgrade, the lifecycle transition includes the permission-set verification and the operational notification to the user. For add-on removal, the lifecycle transition includes the user notification and the operational handoff documentation. The lifecycle transition stage prevents the operational disruption that would otherwise accompany the reclamation action.
Stage 5: Exception handling
The exception handling stage manages the dormancy events that resist the standard reclamation workflow. Common exception types include: legitimate dormancy (the user is on extended leave, sabbatical, or seasonal off-period); pending lifecycle event (the user is in active offboarding or organizational transition); operationally-protected license (the license is reserved for a specific operational scenario that requires retention); and confirmation-stalled (the manager has not responded and the escalation has reached business unit leadership). Each exception type has a defined resolution path with explicit ownership, timeline, and operational disposition.
| Workflow stage | Cadence | Primary owner |
|---|---|---|
| Dormancy detection | Weekly automated | System |
| Manager confirmation | 10-business-day window | Direct manager |
| Reclamation execution | Triggered on confirmation | System |
| Lifecycle transition | Triggered post-reclamation | System + ops |
| Exception handling | Escalated path | License governance |
The default-to-reclaim posture
The single most consequential operational design decision in the automated reclamation workflow is the default-to-reclaim posture on lapsed manager confirmation. The default posture determines what happens when the manager confirmation step does not receive a response within the defined response window. Two postures are available: default-to-retain (the license remains entitled until explicit manager confirmation) or default-to-reclaim (the license is reclaimed after escalation if the manager has not confirmed retention).
The default-to-retain posture has the operational comfort of preventing inadvertent reclamation but produces the reclamation-stalled failure mode that defeats manual reclamation programs. The default-to-reclaim posture forces the operational confirmation conversation by aligning the operational incentive with the reclamation timeline. The default-to-reclaim posture should be paired with explicit escalation mechanics (the escalation reaches business unit leadership before the reclamation executes), explicit time windows (typically 10 business days for manager confirmation, with an additional 5 business days for business unit leadership escalation), and explicit reinstatement mechanics (the reclaimed license can be re-entitled within the assigned pool if the operational requirement is documented post-reclamation).
The integration with the broader identity governance
The automated reclamation workflow should integrate with the broader identity governance lifecycle—the hire, role-change, leave, and offboarding events that should automatically trigger Salesforce license reclamation. The integration captures the dormancy events at the source (the offboarded user is reclaimed immediately at offboarding, not 60 days after the dormancy detection surfaces the event) and prevents the dormancy backlog that accumulates without integrated lifecycle automation. The integration is typically implemented through the identity provider (Okta, Azure AD, Google Workspace) or the HRIS platform (Workday, BambooHR, SuccessFactors), with the lifecycle events triggering the Salesforce reclamation workflow through API integration.
The exception handling deep dive
The exception handling stage is where the workflow earns its operational credibility. Five exception types recur frequently. Extended leave—the user is on parental leave, sabbatical, medical leave, or seasonal off-period—warrants license retention with explicit re-evaluation at the leave's expected end. Active offboarding—the user is in formal offboarding workflow—warrants accelerated reclamation through the offboarding lifecycle rather than the dormancy lifecycle. Operationally-protected license—the license is reserved for break-glass, emergency response, executive escalation, or specific operational scenarios—warrants retention with explicit operational justification documented. Confirmation-stalled—the manager has not responded and the escalation has reached business unit leadership—warrants reclamation with documented escalation history. License-pool reassignment—the reclaimed license is immediately reassigned to a different user in the pool—warrants the reclamation execution with the operational handoff to the receiving user.
The reporting and governance overlay
The automated reclamation workflow generates a continuous reporting stream that supports the operational governance of the program. The key reporting metrics include: the dormancy detection rate (events per week, by license type, by business unit); the manager confirmation rate (response rate, average response time, disposition); the reclamation execution rate (events per week, by reclamation type); the exception rate (events per week, by exception type); the annualized value of reclaimed licenses (capturing the commercial outcome of the program); and the lifecycle-event integration rate (the proportion of dormancy events that originate from integrated lifecycle automation versus from dormancy detection). The reporting overlay is reviewed monthly at the license governance level and quarterly at the leadership level.
Benchmark outcomes by deployment scale
For a mid-market customer with a 1,000-5,000 user Salesforce footprint, the automated reclamation workflow typically recovers $200K-$1.4M in annualized license value within the first 18 months of operation. For a large-enterprise customer with a 10,000-50,000 user Salesforce footprint, the workflow typically recovers $4M-$28M in annualized license value within the first 18 months. The proportional outcomes scale consistently with the broader footprint and the underlying shelfware concentration, with the marginal automation cost typically below 15% of the recovered annual license value across both deployment scales.
Where to begin
The most useful first step is the workflow design exercise: define the dormancy detection conditions, the manager confirmation mechanics, the reclamation execution actions, the lifecycle transition handoffs, and the exception handling paths against the operational reality of your Salesforce footprint and broader identity governance. The workflow design exercise establishes the operational blueprint against which the technical implementation can be planned. The technical implementation follows the design, with the platform selection (native Salesforce versus external orchestration) driven by the broader operational governance landscape rather than by the workflow logic itself.
The strategic frame
License reclamation automation is the operational discipline that converts the shelfware reporting into recovered seats. The workflow design—dormancy detection, manager confirmation with default-to-reclaim, reclamation execution, lifecycle transition, exception handling—is what makes the discipline survive past the first quarter and produce the sustained reclamation outcomes that capture meaningful commercial outcomes at the next renewal moment. Customers who treat license reclamation as an automated operational workflow—with the default-to-reclaim posture, the lifecycle-event integration, and the operational governance overlay—consistently capture 60-80% more dormant licenses per quarter than customers running manual reclamation programs, and arrive at the renewal moment with the operational evidence that supports the disciplined commercial commitment.