Idle licenses lingered; Okta sign?ins and vendor usage with ServiceNow reclaimed seats via policy?based manager approvals

Overview

A consulting firm struggled to manage software licenses across regions and practices. Seats were assigned through ad hoc processes, inactivity wasn’t tracked consistently, and reclaiming licenses required manual audits and email approvals. Intelligex connected Okta sign?in data, vendor activity APIs, and the firm’s IT Asset Management (ITAM) system to detect inactive accounts and trigger reclaim workflows with manager approvals. Orphaned licenses declined, reallocation moved faster, and spend accountability became clearer—while Okta, the ITAM platform, and vendor tools stayed in place.

Client Profile

• Industry: Professional services and consulting
• Company size (range): Global practices with regional operations and a centralized IT/Platform team
• Stage: Okta for Single Sign?On (SSO); mix of SaaS tools across collaboration, CRM, analytics, and engineering; ITAM in place with partial application inventory; license assignment handled by request and local spreadsheets
• Department owner: IT & Infrastructure (Service Management and Platform Engineering)
• Other stakeholders: Practice Leads, Procurement, Finance/FP&A, Security, HR, Regional IT, Internal Audit

The Challenge

Seats were issued easily and rarely reclaimed. Project timelines fluctuated, teams changed tools, and contractors joined and left frequently. License assignments followed onboarding tickets or practice?level requests, but there was no system telling owners when a seat sat idle. Regional spreadsheets tried to track who had what, yet they fell out of date, and shadow allocations accumulated.

Visibility was fragmented. Okta knew who authenticated to an app, vendors knew who used features, and the ITAM tool held entitlements and costs. None of these sources were joined programmatically. When Finance requested a reduction, IT ran one?off audits and sent broad emails asking managers to confirm usage. Reclaims were slow and inconsistent, and some high?cost licenses remained assigned to inactive staff because decisions depended on who replied first.

Approvals and records were scattered. Managers approved reclaims in email, security exceptions lived in chats, and change history didn’t tie a reclaim to the activity data that justified it. During audits, teams stitched together logs and spreadsheets to show what was reclaimed, when, and under whose approval.

Why It Was Happening

Root causes were siloed data and manual lifecycle control. Okta’s sign?in events, vendor activity reports, and ITAM entitlements were managed separately. License tiers differed per tool, and inactivity meant different things across products. No shared policy translated these signals into reclaim candidates, and no workflow tied requests to managers with evidence and a consistent decision window. As a result, seats lingered after assignment, and reallocations lagged demand.

Ownership and timing were diffuse. Platform teams managed SSO, Procurement negotiated contracts, ITAM tracked entitlements, and managers drove approvals. Without a single, governed pipeline to correlate usage, trigger reclaim, and collect approvals with evidence, seat management defaulted to periodic campaigns rather than continuous hygiene.

The Solution

Intelligex implemented an automated license governance pipeline that unified activity and entitlement data, identified reclaim candidates by policy, and routed actions through a manager?approved workflow. Okta System Logs and vendor APIs supplied sign?in and feature?use signals; the ITAM source of record supplied entitlements and costs; and reclaim or downgrade tasks were raised with evidence, owners, and due dates. Approvals, exceptions, and outcomes were logged and visible in dashboards. The design leveraged Okta’s event APIs (Okta System Log API), vendor reporting endpoints such as Microsoft Graph Reports (Microsoft Graph Reports), and the firm’s ITAM capabilities (for example, ServiceNow Software Asset Management: ServiceNow SAM overview).

• Integrations: Okta System Log for app sign?in and group membership; vendor activity APIs for last use and feature consumption (for example, collaboration, CRM, analytics); ITAM entitlements and costs; HR and directory for manager and employment status; ITSM for approvals and tasking; SIEM for centralized logging.
• Canonical usage model: Normalized fields for user, app, license tier, last sign?in, last feature use, entitlement owner, cost center, and manager; cross?reference between Okta groups, vendor assignments, and ITAM contracts.
• Policy engine: App?specific inactivity windows, feature?use thresholds, and tier?downgrade rules; different paths for employees vs. contractors; effective?dated policy versions with rationale.
• Reclaim workflow: Evidence?backed tasks to downgrade or remove licenses; manager approvals with one?click accept/deny; user notifications with a self?confirm path; time?bound holds for upcoming project assignments.
• Exceptions and safeguards: Maker?checker for critical roles and high?sensitivity apps; seasonal and bench policies; grace periods during leave; auto?suspend rather than delete for designated classes.
• Dashboards and reporting: Reclaim candidates by app and practice, approval aging, reclaimed vs. denied trends, and allocation by tier; linkbacks to usage evidence and policy version.
• Security and privacy: Role?based access to usage details; minimal disclosure in notifications; immutable logs of evaluations, approvals, and changes.

Implementation

• Discovery: Mapped top SaaS applications, license tiers, and entitlements; reviewed Okta group models and assignment patterns; cataloged vendor activity endpoints and report cadence; inventoried ITAM contracts and cost centers; gathered manager approval flows and audit requirements.
• Design: Defined the canonical usage model and identity crosswalks; authored inactivity and downgrade policies per app; specified approval tiers and exception categories; designed the reclaim workflow with user notifications; planned dashboards, evidence exports, and data retention.
• Build: Implemented collectors for Okta System Logs and vendor activity reports; built normalization and policy evaluation services; integrated ITAM for entitlement and change recording; created ITSM tasks and approval forms with embedded evidence; wired notifications to managers and users; enabled audit logging and dashboards.
• Testing/QA: Ran in shadow mode: generated reclaim candidates without making changes; reconciled candidates with app owners and practice leads; tuned inactivity thresholds and downgrade rules; piloted end?to?end with a few apps using non?disruptive downgrades first.
• Rollout: Enabled automated reclaim for selected apps and tiers; expanded to additional products as accuracy and approvals stabilized; introduced downgrade?first policies before full removal; kept manual requests as a controlled fallback during early cycles.
• Training/hand?off: Delivered sessions for managers, requesters, and fulfillment teams on evidence review, approvals, and exceptions; provided playbooks for app owners on app?specific signals; updated SOPs for onboarding, offboarding, and role changes; transferred ownership of policies and dashboards to Service Management and Procurement under change control.
• Human?in?the?loop review: Established recurring governance to review denied reclaims, exception aging, and policy changes; decisions recorded with rationale and effective dates; improvements fed back into thresholds and workflows.

Results

Seats aligned more closely with usage. The pipeline surfaced inactive and over?tiered accounts with clear evidence, managers approved reclaims from a single task, and licenses flowed back into pools for reallocation. Downgrade paths addressed cases where basic access was still needed, and holds handled upcoming assignments without heavy back?and?forth.

Spend accountability improved. Dashboards showed allocations by tier, aging candidates, and approval trends by practice and region, making it easier to discuss renewals with Procurement using factual usage and entitlement data. Audits referenced the same evidence: policy versions, usage snapshots, approvals, and change records. Okta, vendor tools, and the ITAM platform remained in place; the change was a governance layer that connected signals to decisions and recorded outcomes.

What Changed for the Team

• Before: License audits ran as periodic campaigns. After: Continuous policy checks flagged reclaim candidates with evidence.
• Before: Approvals lived in inboxes and chats. After: Manager approvals happened in a single task with embedded usage context.
• Before: Seats stayed assigned through bench or leave. After: Grace rules held seats temporarily, then reclaimed or downgraded by policy.
• Before: Over?tiered users were hard to spot. After: Feature?use signals triggered tier downgrades before renewals.
• Before: Reclaims were risky and manual. After: Workflows handled notifications, holds, downgrades, and rollbacks with audit trails.
• Before: Finance debated which seats to cut. After: Dashboards showed allocations and inactivity by app, tier, and practice.

Key Takeaways

• Unify signals; combine SSO events, vendor activity, and ITAM entitlements to see real usage.
• Make policy explicit; encode inactivity windows, downgrade rules, and grace periods per app and role.
• Keep managers in the loop; route evidence?backed reclaim requests with clear accept/deny paths and holds.
• Start with downgrades; reduce risk by moving users to lower tiers before full removal.
• Run in shadow first; validate candidates with owners and tune thresholds before enforcement.
• Integrate, don’t replace; keep Okta, vendor tools, and ITAM—add a governance and automation layer across them.

FAQ

What tools did this integrate with? Okta supplied sign?in and group signals via the System Log API. Vendor activity came from product?specific endpoints, such as Microsoft Graph Reports for collaboration suites. Entitlements and contract data flowed from the firm’s ITAM platform (for example, ServiceNow SAM). Approvals and tasks ran through the existing ITSM, and logs were forwarded to the SIEM.

How did you handle quality control and governance? Inactivity and downgrade policies were versioned with owners and rationale. All evaluations attached evidence (last sign?in, last feature use, entitlement details) to the approval task. Sensitive roles used maker?checker approvals. Exceptions had expiration dates and reason codes. Every reclaim or downgrade recorded the policy version, approver, and outcome for audit.

How did you roll this out without disruption? The pipeline ran in shadow mode first, generating candidates without changes. App owners and practice leads reviewed lists and tuned thresholds. Rollout began with low?risk apps and tier downgrades, then progressed to removals. Manual requests remained a controlled fallback during early cycles, and user notifications provided a self?confirm path before reclaim.

How did you determine inactivity across different apps? A policy engine applied app?specific signals: last SSO sign?in from Okta, last feature use from vendor reports, and license tier. Windows and thresholds varied by product and role. For apps without granular activity data, sign?in recency and project assignment dates informed decisions, with longer grace periods.

What about contractors, seasonal staff, and leaves? Contractor and seasonal users followed tailored policies with shorter or longer grace as appropriate. HR signals paused reclaims during approved leave. Holds allowed managers to retain a seat for upcoming assignments, with automatic expiration.

How were errors or false positives handled? Managers could deny a reclaim with a reason, which fed back into policy tuning. Downgrade?first logic minimized impact, and rollback steps were available if removal affected active work. Governance reviews monitored denied cases and adjusted signals accordingly.

Did this cover multiple regions and currencies? Yes. ITAM provided contract and cost data by region, and dashboards grouped candidates and outcomes by practice and location. Policies could vary by region where vendor contracts or usage patterns differed, with versions tracked under change control.