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).

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. 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.

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

• Concepts: License Metrics — choosing per-user license types
• Subscription Licenses
• Direct Assignment — the per-device equivalent