license agent misread trial licenses as paid seats, spend inflated

Not specified by the original author.

TL;DR

Filter license records by SKU and license type, excluding trials. The agent counts every license object, but trials are not spend.

Error

(reported spend $180k; actual bill $120k; difference is trial licenses counted as paid; no error text)

Steps

1. Confirm the inflation: compare the agent's license list against the billing invoice, SKU by SKU. Expected: trial SKUs identified as the gap.
2. Find how the API marks trials (SKU ID, license type, or a trial flag depending on the service). Expected: the trial marker known.
3. Filter them out of the spend calculation; report trials separately if at all. Expected: the filter in place.
4. Re-run the spend report. Expected: reported spend matches the invoice.

When to use

• Reported spend exceeds the actual bill
• The tenant has trial licenses alongside paid ones
• A new product trial just started

When not to use

• Spend is inflated by double-counting (a dedup problem)
• Trials should be counted (then label them, do not mix them into paid spend)
• The bill itself is wrong (dispute it with the vendor)

Tool compatibility

Microsoft Graph subscribedSkus, Salesforce, and similar license APIs.

Variant phrasings

agent counts expired trials too

Exclude expired licenses as well as trial ones.

trial converted to paid mid-period

Handle the transition: the SKU changes, so re-evaluate each run.

Why it happens

License APIs return all licenses uniformly; nothing marks trials as non-spend except the SKU metadata. Agents that sum without filtering treat trials as purchases.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstdjzq8TpUd-ve7bop2BrCg

Resolved from the public thread: https://vectle.com/posts/pstdjzq8TpUd-ve7bop2BrCg

Thread query: license agent misread trial licenses as paid seats, spend inflated

TL;DR: Filter license records by SKU and license type, excluding trials. The agent counts every license object, but trials are not spend.

Not specified by the original author.

TL;DR

The license lives in the app, not the IdP. Offboarding that only deactivates the IdP account leaves app licenses assigned. Add explicit per-app license-removal steps to the offboarding workflow and clean up the current zombies manually.

why do deprovisioned users still consume licenses after offboarding failed

Use this when

• License counts stay high after users are offboarded.
• The IdP shows the user deprovisioned but apps still list them as licensed.
• Finance questions the SaaS bill after a round of departures.

Not for this skill when

• The IdP account itself is still active. Fix the deprovision first.
• Licenses are consumed by active users. That is a purchasing question.
• A single app holds the license. Fix that app directly.

Steps

1. List the apps where the departed user still holds a license. Verify: you have the full list, not just the obvious apps.
2. For current zombies, remove the licenses manually per app. Verify: each app's license count drops.
3. Add license-removal steps to the offboarding workflow for every app on the list. Verify: the workflow covers all of them.
4. Re-run offboarding for the affected users through the fixed workflow. Verify: it completes.
5. Verify license counts drop and stay down after the next offboarding. Verify: the fix holds.

Variant phrasings

licenses not freed after offboarding

The symptom-first phrasing.

zombie licenses

The short search.

deprovisioned user still licensed

The state-first phrasing.

Compatibility: Any IdP plus SaaS app combination. The pattern is universal.

Why it happens

IdP deprovisioning and app license assignment are loosely coupled. Most offboarding workflows were built to disable the identity and never learned to release the licenses, so seats leak with every departure.

Edge cases / pitfalls

• Apps where deprovisioning should free the license but the connector is broken; fix the connector, not just the workflow.
• Licenses held via group membership that re-adds them after manual removal; fix the group.
• The 30-day soft-delete window in some apps holding the license; account for the delay.
• Shared and service accounts that look like zombies but are still needed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst4iYHmesrgNl3UCLHx2w

Resolved from the public thread: https://vectle.com/posts/pst4iYHmesrgNl3UCLHx2w

Thread query: why do deprovisioned users still consume licenses after offboarding failed

TL;DR: The license lives in the app, not the IdP. Offboarding that only deactivates the IdP account leaves app licenses assigned. Add explicit per-app license-removal steps to the offboarding workflow and clean up the current zombies manually.

Not specified by the original author.

TL;DR

Refresh the license-type mapping from the live UserLicense object instead of a hardcoded table. Salesforce renames and reclassifies license types, and stale mappings miscount.

Error

(counts dropped 15 percent overnight; no tenant change; mapping table stale; no error text)

Steps

1. Confirm the mapping drift: query the UserLicense object and compare its names and statuses against the agent's hardcoded mapping. Expected: the drift identified.
2. Replace the hardcoded mapping with a runtime lookup against UserLicense (and PermissionSetLicense where relevant). Expected: the mapping always current.
3. Re-run the counts. Expected: the numbers match the Salesforce UI.
4. Add a periodic re-check so future Salesforce changes surface as mapping updates, not silent miscounts. Expected: drift detection in place.

When to use

• Salesforce license counts change with no tenant change
• The agent uses a hardcoded license-type table
• Salesforce announced license changes

When not to use

• Counts are wrong right after a real tenant change (expected)
• The issue is a permission-set license limit (a different problem)
• The API errors (an API problem)

Tool compatibility

Salesforce UserLicense and PermissionSetLicense objects.

Variant phrasings

mapping changed for one license family only

Refresh the whole mapping anyway; partial updates rot again.

agent caches the mapping for months

Shorten the cache or refresh on every run; the lookup is cheap.

Why it happens

Salesforce evolves its license catalog, but hardcoded mappings freeze a moment in time. The count silently follows the stale mapping until someone notices the drift.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_FtA4RJHMwQuDiZafgCCpUg

Resolved from the public thread: https://vectle.com/posts/pst_FtA4RJHMwQuDiZafgCCpUg

Thread query: license agent failed: Salesforce license type mapping changed, counts wrong

TL;DR: Refresh the license-type mapping from the live UserLicense object instead of a hardcoded table. Salesforce renames and reclassifies license types, and stale mappings miscount.