Allocation Constraint Templates

<< Click to Display Table of Contents >>

Navigation:  Modules > Asset Management > Software License Management > Licenses > Software License Allocation >

Allocation Constraint Templates

Normal license allocation constraint behavior may be over-ridden using a constraint template.  Constraint templates are available from the Contracts left menu option as a fly-out.  The menu option is called "Entitlement Constraints".  

A constraint template defines various ways of constraining license allocation.  If any of the ways of constraining license allocation has selections assigned as part of the constraint template, then those ways that have selections assigned will be used to over-ride the MIE's default behavior for constraining allocation.  For any ways that do not have selections assigned, the MIE's default behavior will be used.

For an allocation constraint template to be used, an individual license record must contain a Contract Number that matches the Contract Number of a contract in the MIE.  That contract must be marked as Active and it must have an allocation constraint template assigned to it.  If any of those conditions are not met, default constraint behavior will be used.  Licenses being pushed by the ASN Processor must have valid contract numbers if their allocation is to be governed by a desired template.

Note that an allocation constraint template will not over-ride an asset number constraint.  If an asset number is contained in a license record, the license will be perpetually constrained to that asset.

There is one important scenario that the user has to keep in mind with regards to the complex constraint logic handled by the MIE, which has a very low probability of occurring in the real world:

IF a customer constrains licenses, at peer level, in more than one way (meaning, by way of example, constrained by org for some, constrained by cost center for some, constrained by dept for some)

 

AND

 

IF that same customer has one or more authorizations that match constraints from 2 or more differently constrained licenses

 

(Example:  Authorization matches the org constraint of one set of licenses and it also matches the cost center constraint of another batch of licenses)

 

THEN

 

The allocation engine may fail to optimally allocate licenses across those constraints.  It will honor the constraints correctly, but it may choose to cover an authorization that can be satisfied by several differently constrained license groups with licenses that result in a shortage of licenses under one constraint and an overage of licenses other another constraint.

 

This will only occur with different peer level constraints – and most likely when only one constraint is being applied.  The probability of occurrence diminishes greatly when two or more constraints are applied to a license.