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.
Prerequisites. Per-Product Scoping. A custom field LicenseByDepartment (integer) on the Software Catalog. Both feeder queries surfacing the field.
Rules to add (in Configure):
Set Consumption.DeptScope = IIF(Consumption.LicenseByDepartment = 1, Consumption.DepartmentID, -1)
Set License.DeptScope = IIF(License.LicenseByDepartment = 1, License.DepartmentID, -1)
Requirement Consumption.DeptScope = License.DeptScope
Catalog work: Open every Adobe product in Licensing → Licensing Position and tick LicenseByDepartment. Save.
Test:
- Pick an Adobe product with at least two licenses, one in each of two departments.
- Confirm consumptions exist in both departments.
- Recalculate.
- Verify Marketing-department consumptions allocate from Marketing-department Adobe licenses, and vice versa. Cross-department allocations should not occur.
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:
- Find a consumption that today is allocated to a license matching by department.
- Create a second license with capacity, the same product, the consumption's custodian assigned, but a different department.
- Recalculate.
- 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. Same shape as Adobe-by-department but using cost centre.
Prerequisites. Custom field LicenseByCostCentre on Software Catalog. Both feeder queries surfacing it.
Rules to add:
Set Consumption.CCScope = IIF(Consumption.LicenseByCostCentre = 1, Consumption.CostCentreID, -1)
Set License.CCScope = IIF(License.LicenseByCostCentre = 1, License.CostCentreID, -1)
Requirement Consumption.CCScope = License.CCScope
Catalog work: Tick LicenseByCostCentre on the affected products.
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 scoping pattern 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.
- Open Licensing → Licensing Position.
- Find and open the product.
- Change the License Type to
USER(or whatever the correct type is — see License Metrics). - Save.
- 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.
Related Reading
- Per-Product Scoping — the pattern recipes 1, 4, and 6 are based on
- Default Rules — the rules these recipes modify
- Testing Rule Changes Safely — for every recipe
- Concepts: Affinity vs Requirements