Software and licenses overview
The software section tracks every subscription and license your organization pays for — how many seats you bought, who actually holds them, what they cost, and when they renew. It answers the questions IT and finance keep colliding over: are we over-licensed, who's sitting on a seat they never use, and what's about to auto-renew. This page explains the model; the how-to guides linked throughout cover the steps.
You reach it at Admin → Software, which opens on the Licenses list. A shared sub-nav at the top of every software page switches between three views: Catalog, Licenses, and Utilization.
The three building blocks
Software is modelled as three connected things. Keeping them separate is what lets one product carry several contracts, and one contract serve many people, without the records contradicting each other.
| Concept | What it is | Where it lives |
|---|---|---|
| Catalog entry | A product — the application itself (e.g. Microsoft 365, Slack), with its publisher, category, and security grade. Reusable across many licenses. | Software → Catalog |
| License | A commercial agreement for that product — a pool of seats with a cost, a billing cycle, and renewal dates. One catalog entry can have many licenses. | Software → Licenses |
| Assignment | One seat of a license issued to one user. Assignments are what consume seats. | A license's detail page |
A useful way to read it: the catalog says what the software is, a license says how much of it you bought and for how much, and an assignment says who is using it.
The catalog: products, not purchases
The catalog is the shared list of applications your organization knows about. Each entry
is a product, defined independently of any contract, so the same Slack entry backs your
annual Slack license this year and the renewal next year.
A catalog entry carries the product's identity and, optionally, an AI-generated security and compliance grade:
| Field | Notes |
|---|---|
| Name | The product name, e.g. Adobe Creative Cloud. |
| Publisher | The vendor behind it, e.g. Adobe. Drives the brand icon shown in lists. |
| Category | Groups the catalog and filters it. |
| Security grade | An optional letter grade and risk level from an AI evaluation of the product's data-handling and compliance posture. Shown as a coloured pill on the catalog, the licenses list, and each license page. |
The security grade is a property of the product, not of any one license — so every license for that product shows the same grade. Generating and interpreting it is covered in Software catalog.
Adding a product to the catalog doesn't create a license or cost anything. The catalog is a reference list; licenses are where seats and money live.
Licenses: seats, cost, and renewal
A license is the unit you spend money on and renew. Each one points at a catalog entry and holds a pool of seats plus its commercial terms.
| Field | Required | Default | Notes |
|---|---|---|---|
| Software | Yes | — | The catalog entry this license is for. |
| License name | No | — | A label for this specific agreement, useful when one product has several licenses (e.g. M365 E3 — Sales). |
| Seats total | Yes | 1 | How many seats the agreement covers. |
| Seat type | Yes | user | What a seat is measured against — see seat types. |
| Cost per seat / Total cost | No | — | The price, in the chosen currency. Either or both can be recorded. |
| Currency | No | EUR | Three-letter currency code. |
| Billing cycle | Yes | annual | How often the cost recurs — see billing cycles. |
| Purchase / start / expiry / renewal dates | No | — | The agreement's timeline. Expiry drives the renewal warnings. |
| Auto-renew | No | false | Whether the agreement renews on its own. |
| Renewal notice days | No | 30 | How many days before expiry this license flags itself as expiring — the amber countdown on its row. Per-license, separate from the fixed-window Renewing soon filter below. |
| Business owner | No | — | The internal person responsible for the license. |
| License key / Purchase order / Invoice number | No | — | Procurement references. The license key is masked on the detail page. |
| Status | Yes | active | The license's commercial state — see statuses. |
Seat types
The seat type records what one seat is counted against. It's descriptive — it documents how the vendor licenses the product — and the unlimited type also tells the utilization report to skip the seat-fill calculation.
| Seat type | A seat is tied to |
|---|---|
user | A named person. |
device | A specific machine. |
concurrent | A simultaneous-use slot, shared across people. |
unlimited | No fixed count — utilization is not computed. |
Billing cycles
| Billing cycle | Cost recurs |
|---|---|
monthly | Every month. |
quarterly | Every three months. |
annual | Once a year. |
biennial | Every two years. |
one_time | A single perpetual purchase. |
custom | An irregular schedule you track manually. |
Statuses
A license's status is its commercial state, set on the create or edit form. It's separate
from whether the agreement has technically expired by date — a license can sit at active
past its expiry until someone updates it, which is exactly what the Expired filter is
for.
| Status | Meaning |
|---|---|
active | In force and in use. |
pending_renewal | Up for renewal, decision outstanding. |
trial | Evaluation period, not yet a paid commitment. |
expired | The agreement has lapsed. |
cancelled | Ended deliberately. |
The status chips above the list double as filters with live counts. Alongside them, four saved filters surface the records that usually need attention:
| Filter | Shows |
|---|---|
| Renewing soon | Licenses expiring within the next 60 days. |
| Expired | Licenses whose expiry date is in the past. |
| Fully seated | Licenses with no seats left (used ≥ total). |
| Underutilized | Licenses using less than half their seats (and more than one seat). |
Deleting a license archives it (a soft delete) rather than erasing it, so its assignment and audit history stay intact for finance and compliance. The list confirms with License archived.
Assignments: issuing a seat
Assigning a license seat to a user is what links the contract to a person. Each active assignment consumes one seat, so the seats used count is always the number of people currently holding the software, and seats available is what's left to issue.
Two rules keep the seat math honest, enforced at the moment you assign:
- No overcommit. If a license has no seats left, the assignment is refused with No seats remaining on this license. The check runs under a row lock, so two admins assigning the last seat at the same time can't both succeed.
- No duplicates. A user can't hold two active seats of the same license; a repeat attempt returns This user already has an active assignment for this license.
Revoking a seat frees it back into the pool and records who revoked it and when. Both sides of the action — assign and revoke — are detailed in Assign and revoke licenses.
For licenses with many seats — a 100-seat Microsoft 365 or Slack agreement — review the holders on the dedicated View all users page rather than the summary card on the license. It's searchable, sortable, filterable to inactive seats, and exports to CSV.
Usage audits: confirming who really uses it
Buying seats and using them drift apart over time. A users audit is a periodic, deliberate review of a license's holders — you clean up accounts on the vendor's own platform, then come back and record the result.
The flow is intentionally manual, because the actual cleanup happens outside the platform in the vendor's admin console:
- Start the audit from the license page. This snapshots the current seat count as the "before" figure and flags the license with an in-progress banner.
- Clean up externally — remove inactive users, downgrade over-provisioned ones — on the software's own platform.
- Complete the audit: record the new seat count, note what you changed, and optionally schedule the next audit (1, 2, 3, 4, 6, 9, or 12 months out).
Completing an audit overwrites the license's seat-used count with the figure you recorded and saves a permanent history entry showing the before/after delta and your notes. If you schedule a next audit, every admin gets a notification when it falls due. The mechanics and the cadence guidance live in Audits and utilization.
Only one audit can be in progress per license at a time. Starting a second is refused until the first is completed.
Utilization and reclamation
The Utilization view is the fleet-wide companion to per-license audits. Instead of one license at a time, it ranks all active licenses by how fully their seats are used and surfaces dormant seats — assignments where the holder hasn't actually touched the software — so you can reclaim them and stop paying for shelfware.
Dormancy is judged against a configurable window (default 90 days) using the best signal available for each seat:
| Signal | Source | Used when |
|---|---|---|
| Real usage | The endpoint agent reports per-application activity. | The agent has reported usage for that seat. |
| Login proxy | The user's last sign-in to the platform. | No agent telemetry exists for the seat yet — a weaker fallback. |
| User status | The holder's account is inactive or offboarded. | Always flags the seat as reclaimable. |
The report estimates the money tied up in dormant seats and lets you bulk-reclaim them in one pass — each reclaim revokes the assignment, frees the seat, and notifies the affected user. See Audits and utilization.
How software connects to the rest of the platform
A license record is a hub that ties into several other parts of the platform.
People
Every assignment links a seat to a user, both ways: the license shows who holds its seats, and a person's profile shows the software they hold. This is what makes offboarding tractable — when someone leaves, you can see every paid seat to reclaim before their last day, and the offboarding flow can revoke them in one move.
The agent
The endpoint agent reports the applications actually installed and used on each machine. That telemetry feeds two things here: the last-used timestamp on assignments that powers the dormancy signal above, and a reconciliation between what you've licensed and what's installed — paid seats no one runs, and installed apps with no license behind them.
Finance
License costs roll up into the platform's spend reporting, so a renewal is visible on the spend dashboard and on the expiries calendar. The utilization report's "potential savings" figure is the bridge between usage data and the finance view — it puts a number on the seats you could stop paying for.
Documents
Contracts, order forms, and renewal quotes attach to a license. Uploading one kicks off AI extraction that can pull terms, seat counts, and expiry dates straight from the document, which is also how a catalog entry can be created from a contract.
Limitations and trade-offs
| Boundary | What it means |
|---|---|
| Seat counts are figures you maintain | The platform tracks the seats you record and the assignments you make; it doesn't sync seat totals live from the vendor. Usage audits exist precisely to reconcile your recorded count with reality on a cadence. |
| Dormancy is a signal, not proof | Without the agent, dormancy falls back to platform login time — a weak proxy. Treat reclaim suggestions as a prompt to check, especially for software used by people whose machines don't run the agent. |
| Status reflects what you set | A license stays at the status you last chose even after its expiry date passes. The Expired and Renewing soon filters use the dates to catch licenses whose status hasn't caught up. |