User Allocation

For per-user license types (USER, NAMEDUSER, CAL, UAL), the allocation target is the person who uses the machine. This page covers how user allocation works and the workflow for binding licenses to specific custodians.

Per-User Licenses

A per-user license consumes one seat per named individual who uses the product. The engine treats consumption as "this user has this product" rather than "this device has this product".

User allocation is relevant for:

• Per-user SaaS subscriptions (M365, Adobe CC, Salesforce)
• Microsoft Client Access Licenses (CAL)
• User Access Licenses (UAL)
• Named-user perpetual licenses (some Adobe legacy SKUs)

For per-device license types, the allocation target is the asset and the workflow in Direct Assignment applies. For user-based, the workflow is similar but targets users.

Allocate a License to a User

Method 1: Set Custodian on the License

The simplest workflow:

1. Open the license from Licensing → Licenses.
2. Set the Custodian field to the named user.
3. Save.

The custodian assignment is picked up by affinity scoring (custodian-match adds +1000 to affinity for matching consumptions) and by direct-assignment if you also link the user as a related asset.

Method 2: Allocate to All Users of the Product

The menu action Allocate this License to All Users of the Software Product does what it says: takes a license and direct-assigns it to every user who has consumption for the product.

Useful when you have a fresh per-user license and want to allocate immediately without waiting for the next calculation pass.

Method 3: Allocate to Specific Users

The menu action Allocate this License to Users opens a user picker, letting you select specific individuals to assign.

Useful for VIP-style allocations or when only some of the consumption-having users should be on this license (the rest going to a different license).

Assigned Users

Per-user licences also carry an Assigned Users list — the people currently holding a seat. This is a separate idea from allocation: assignment is who you have given a seat to, allocation is who the calculation decided the licence covers. The list lives under Relationships → Assigned Users on the licence, and is covered in full in Assigning Licenses to Users.

Each entry records when the assignment was first seen, when it was last confirmed, and whether it was made by hand rather than by an import.

For licences imported from Microsoft 365 these are maintained automatically — see Azure License Import. Assignments you add by hand are stamped when you create them and are never removed by an import; only assignments the import created are tidied up by it.

Stale entries are what the License Allocations Needing Review report surfaces: seats held by people who have left, and manual assignments nobody has reconfirmed within the AllocationStaleDays threshold (180 days by default).

Custodian vs Direct Assignment

For per-user licenses, "custodian" and "direct assignment to user" can both express the same idea. The distinction:

For most cases, setting Custodian is sufficient. Use direct assignment when you need a guaranteed allocation regardless of affinity changes.

How User Consumption Is Counted

For a per-user license to allocate, there must be a user-side consumption to allocate to. There are two ways one arises.

From devices. The engine derives user consumption from the asset records:

• Each asset has a Custodian (the user it is assigned to)
• For per-user products, consumption is grouped by Custodian
• A user with three machines all running M365 generates one user-consumption (one per custodian, not one per machine)

If your discovery does not populate the Custodian field on assets, per-user license counts will be wrong. Make sure the Active Directory or Intune integration is bringing in user assignments.

From the licence itself. A cloud subscription can be assigned to someone who has no discovered machine at all — a new joiner, a phone-only user, a contractor on unmanaged hardware. Those seats are consumed and paid for, so an allocation on the licence's Assigned Users generates user consumption in its own right, with no device involved.

This matters when reconciling against a vendor portal. If your seat count is short of Microsoft's, the gap is often people who hold a licence but own nothing your discovery can see.

Direct Assignments and User Tracking

When a per-user license is direct-assigned to a specific machine, the engine records that the machine's custodian has been covered, and prevents other machines owned by the same custodian from consuming additional seats from the same license.

Example: Paul Smith has Microsoft 365 installed on both SQL4 and EMAIL. A 2-seat per-user M365 license is direct-assigned to SQL4.

The license's two seats serve two distinct users (Paul and Donna). This matches the per-user licensing model: the seat is for the person, and follows them across whatever devices they use.

This behavior applies whether the direct assignment is the source of coverage or affinity-based allocation is. Once the engine has recorded a custodian as covered by a license, additional machines owned by that custodian do not consume additional seats from that license.

When User Allocation Goes Wrong

Related Reading

• Assigning Licenses to Users — the Assigned Users list, and assignment vs allocation
• Concepts: License Metrics — choosing per-user license types
• Subscription Licenses
• Direct Assignment — the per-device equivalent