The Default Rule Set

The shipped rule set is what runs out of the box. Every customer starts here, and most stay here. This page documents every rule and its weight.

Calculated Fields

The shipped calculated fields derive boolean flags used by the per-server-vs-per-core affinity rules below.

Set Consumption.PrefersServerLicense = IIF(Consumption.CPUCores >= 16, 1, 0)
Set Consumption.PrefersCoreLicense   = IIF(Consumption.CPUCores <= 8,  1, 0)
Set License.IsServerLicense          = IIF(License.IsCoreLicense = 0,  1, 0)
Set License.IsCoreLicense            = IIF(License.IsCoreLicense = 1,  1, 0)

A consumption "prefers server" if its core count is high (a per-server license is more economical for big boxes); a consumption "prefers core" if its core count is low (a per-core license is more economical for small boxes). Licenses are tagged as either server-style or core-style.

The 9–15 core gap. A consumption with 9–15 cores matches neither preference — neither flag is set, neither bonus fires. This is intentional: very-small and very-large boxes have a clear best-fit; mid-range boxes are left to be picked on the other affinity dimensions (department, location, custodian). If you have many 9–15 core machines and want them to nudge one way or the other, lower the >= 16 threshold or raise the <= 8 threshold.

Why the IsCoreLicense self-reference. The fourth Set looks tautological — it just copies License.IsCoreLicense to itself. It exists to force the field to be present and integer-typed on every license row before the affinity rule evaluates it. The engine throws if a referenced field is missing, and licenses where the underlying flag is null would otherwise break the comparison. Leave it in unless you replace the source field.

Requirements

The shipped requirement enforces location scoping:

Requirement Consumption.LocationID within License.LocationID

A license set to "London" can only cover consumptions whose asset is in London (or in a child of London — Floor 1, Floor 2, etc.). A license with no location set has no restriction.

Affinity Rules

The shipped affinity rules and their weights, in roughly the order they contribute to total score:

How the Weights Stack

The weights are deliberately spaced so that the most important matches dominate, but lower-priority matches still influence ties.

A license that matches department, custodian, location exact, and cost centre exact ends up at 5800 versus a license matching only department exact at 3000. Both are eligible (assuming no requirement excludes them); the higher-scoring one is allocated first.

Tie-Breaking

When two licenses end up with identical affinity scores, the lower AssetID wins. In practice this means whichever license was created first. This is deterministic — recalculations produce the same result every time.

When To Adjust Weights

Adjust a weight when the default is producing allocations that consistently surprise you. Examples:

• Custodian should outrank department for your environment (e.g., named-user policies dominate org structure) → boost custodian to 4000, leave department at 3000
• Location should outrank department (e.g., regional purchasing) → boost location exact to 4000
• Cost centre is the primary financial dimension → boost cost centre exact to 2000

Keep adjustments proportional. Doubling one weight is a meaningful change; multiplying by 100 produces a rule that dominates everything else and effectively converts an affinity into a near-requirement (high weight does not actually exclude — only Requirement does that).

When To Add a New Affinity Rule

Add a rule when you have a new dimension that should influence allocation. Examples:

• A custom Project or BusinessUnit field on assets and licenses
• A LicensePool flag where pool A's licenses prefer pool A's machines
• A criticality scoring where production licenses prefer production assets

Adding requires both data and rule:

1. Ensure the field exists on both consumption and license records (via the data source queries — may need transformation editing)
2. Add the affinity rule referencing both fields
3. Pick a weight that fits the priority you want it to have

When To Add a New Requirement

Adding a requirement is more dangerous than adding affinity. A bad requirement excludes valid candidates and produces phantom deficits. Add requirements when:

• You have a regulatory or contractual constraint that must be enforced (Adobe-by-department; restricted-jurisdiction software)
• You can express the constraint as an exact-match comparison
• You have tested it in a non-production environment

For per-product requirements (e.g., "Adobe must stay within department"), use the scoping pattern in Per-Product Scoping — do not add unconditional requirements.

Related Reading

• How Rules Are Evaluated
• Per-Product Scoping — the standard pattern for conditional requirements
• Hierarchy Fields and the Within Comparator — how within works
• Concepts: Affinity vs Requirements