Zoomed Image
USA
800 691 9120
UK
01225 704844

Common Rule Recipes

Software Asset Management Guide
Customizing the Calculation

Common Rule Recipes

Worked examples of the most common customizations. Each recipe is self-contained — read the relevant deeper-reference page first if you need the full context.

Recipe 1: Adobe Licensed by Department

Goal. Adobe licenses purchased by Marketing should only cover Marketing users; Adobe licenses purchased by Engineering should only cover Engineering users. Other publishers continue to behave normally.

Approach. Use the built-in Default Allocation Rule on the Software Catalog entry. No rule editing, no custom fields.

Steps:

  1. Open Licensing → Licensing Position and find each Adobe product (Creative Cloud, Acrobat, etc.).
  2. On each catalog entry, set Default Allocation Rule to Allocate by Department.
  3. Save.
  4. Recalculate.

All existing Adobe licenses inherit the catalog default automatically — their per-license Allocation Rule stays at "Inherit from catalog" but the engine now enforces Department for them.

Test:

  1. Pick an Adobe product with at least two licenses, one in each of two departments.
  2. Confirm consumptions exist in both departments.
  3. Verify Marketing-department consumptions allocate from Marketing-department Adobe licenses, and vice versa. Cross-department allocations no longer occur.

One-off exception. If a single Adobe license needs different treatment (e.g., a global enterprise license that should cover any department), open that License record and set its Allocation Rule explicitly — anything other than "Inherit from catalog" overrides the catalog default for that license alone.

For more on how the catalog/license inheritance works, see Per-Product Scoping.

Recipe 2: Custodian Outranks Department

Goal. When a license has a specific custodian assigned, that should outrank department matching for affinity purposes. Useful when named-user policies dominate organizational structure.

Default behavior: Custodian = 1000 points; Department exact = 3000 points. Department wins.

Change to make: Increase the custodian weight from 1000 to 4000.

Find this line:

Affinity License.CustodianID = Consumption.CustodianID, 1000

Change to:

Affinity License.CustodianID = Consumption.CustodianID, 4000

Test:

  1. Find a consumption that today is allocated to a license matching by department.
  2. Create a second license with capacity, the same product, the consumption's custodian assigned, but a different department.
  3. Recalculate.
  4. The grant should switch to the second license (custodian 4000 + nothing else > department exact 3000).

Recipe 3: VIP License Pool Bound to Specific Users

Goal. A small pool of premium licenses should be reserved for specific named individuals. Other users should not get this pool's licenses even if normal affinity would allocate from it.

Approach: Direct assignment. See Allocation: Direct Assignment.

Why not a rule? Rules apply to every license of the product. To restrict only specific licenses, the lever is at the license level via direct assignment.

If you really want a rule-based version (e.g., a IsVIPLicense flag on the license, paired with a IsVIPUser flag on assets), the scoping pattern works:

Set Consumption.VIPGate = IIF(License.IsVIPLicense = 1, Consumption.IsVIPUser, -1)
Set License.VIPGate     = IIF(License.IsVIPLicense = 1, 1, -1)
Requirement Consumption.VIPGate = License.VIPGate

But this is more complex than direct assignment for the typical case. Use direct assignment unless you have many licenses to gate.

Recipe 4: Cost Centre as a Hard Requirement for Specific Products

Goal. Some products are billed at the cost-centre level and must not bleed across cost centres.

Approach. Set Default Allocation Rule to Allocate by Cost Centre on the catalog entries for those products. Same shape as Recipe 1 but using the cost-centre option of the dropdown.

Steps:

  1. Open each affected catalog entry.
  2. Set Default Allocation Rule to Allocate by Cost Centre.
  3. Save.
  4. Recalculate.

If a product needs both Cost Centre and Department enforced together (e.g., charge-back AND publisher-by-org-unit), pick Allocate by Department + Cost Centre instead — the dropdown carries every two- and three-dimensional combination.

Why not just boost the existing affinity weight? Affinity is a preference. A high cost-centre affinity weight will prefer the right cost centre but will still allocate cross-cost-centre when the right one is at capacity. The Allocation Rule makes it a hard exclusion.

Recipe 5: Make a Product Mandatorily Per-User

Goal. A product with the wrong License Type on its catalog entry is consuming wrongly. You want to fix it without re-importing.

Approach: This is not a rules change — it is a catalog change.

  1. Open Licensing → Licensing Position.
  2. Find and open the product.
  3. Change the License Type to USER (or whatever the correct type is — see License Metrics).
  4. Save.
  5. Recalculate.

The metric used by all consumptions for this product changes immediately. If you also have license records of the wrong type for the same product, fix them too — the position does not become consistent until both consumption metric and license metric are right.

Recipe 6: Add a "BusinessUnit" Affinity Dimension

Goal. Your organization tracks business units as a custom dimension that should influence allocation. Licenses owned by Business Unit A should prefer Business Unit A assets.

Prerequisites. A BusinessUnitID field on both Asset and (the licenses' representation in) Software License. Feeder queries surfacing both.

Rule to add:

Affinity Consumption.BusinessUnitID = License.BusinessUnitID, 600

The weight 600 places business unit between cost centre exact (300) and location exact (800) — pick a weight that reflects its priority in your environment.

No requirement is added — this is preference only. Cross-business-unit allocation is still possible when the same-BU license is at capacity.

If you want it as a hard requirement, follow the scoping pattern with LicenseByBusinessUnit flag.

Recipe 7: Reduce Custodian Weight to Zero

Goal. Your organization does not use the custodian field consistently and the custodian affinity rule is producing odd allocations. Disable it.

Find the line:

Affinity License.CustodianID = Consumption.CustodianID, 1000

Either delete it, or set the weight to zero:

Affinity License.CustodianID = Consumption.CustodianID, 0

A zero-weight rule still runs but contributes nothing — no faster than deleting, but safer to revert (just put 1000 back).

Recipe 8: Tighter Location Requirement

Goal. Default location requirement is within (allows hierarchy match). You want exact location only.

Find the line:

Requirement Consumption.LocationID within License.LocationID

Change to:

Requirement Consumption.LocationID = License.LocationID

Warning: This is a strict change. A "London"-tagged license will no longer cover "London Floor 2" assets. Every asset and every license must be at the same hierarchy level for allocation to work. Test thoroughly.