<< Click to Display Table of Contents >> Navigation:  Modules > Asset Management > Software License Management > Licenses > Additional Entitlements > Owned Entitlements > Allocating Entitlements to Licenses

An entitlement is an embellishment of a license - it extends the "rights" afforded by the license.  Therefore it is an entity that is associated with the license.  The MIE allocates entitlements out to cover licenses in a way similar to how it allocates licenses out to cover authorizations.

Allocation happens between an owned entitlement and a license - the two are tied together by the MIE's allocation logic.

Entitlements almost always have a period of performance - a start and an end date.  Therefore, it is possible to have allocated entitlements that have since expired, making the entitlement allocated, but no longer in force.

It is possible to have more than one entitlement allocated to a license.  However, the different entitlements must represent different Entitlement Definitions, or different start/end dates (for instance, you may have a renewed entitlement and the entitlement it replaced both still showing as allocated to a license)

The following conditions must be met for an owned entitlement to be allocated (or de-allocated):

 

 
Allocation is performed by simply maintaining a cross reference of owned position of entitlements to licenses.  The owned position maintains the date the entitlement ends, and the allocation logic does not consider any now-expired owned position that may have been previously allocated to now be allocated.  This means that if a license was covered with an entitlement allocation before, and that owned position that was allocated now expires, the license will be considered uncovered and will once again be eligible for entitlement allocation.  The record of the previous allocation of the now expired entitlement is preserved, however, ensuring the ability to maintain a full audit trail showing which licenses were covered by which entitlements during which time frames.

 
 

Priority Scheme

Allocation follows the following priority scheme:

1.  Any owned entitlement that has been given a serial number that matches the serial number of an existing license record group will be allocated first to license records matching the serial number.  If any matching license records had previously been allocated entitlements that do not match the serial number, those entitlements will be de-allocated in favor of the entitlement that does match the serial number.  The de-allocated entitlements will be available for further allocation.  If, after all available matching licenses are covered there are remaining entitlements in this owned record, the remaining entitlements will be attempted to be allocated via the next two steps of the priority (they will not be reserved and held back in case any new matching license records appear in the future).
 
2.  Any entitlements that were "purchased" through the MIE's Software Request Portal will be covered next.  Such entitlements were matched with an authorization when they were requested, so first the authorization must have been allocated a license.  As soon as the license is allocated, then entitlement allocation will attempt to cover the allocated license with an entitlement that closely matches what was initially ordered.  When allocating an entitlement to cover what was ordered through the Software Request Portal, the MIE's allocation logic will ensure the allocated entitlement has an end date that is at, or later, than the date promised when the entitlement was originally requested.
 
3.  All other entitlements.  These are considered unrestricted.  When allocating, the MIE will give priority to licenses that already have existing entitlements allocated to them.  This means the MIE gives priority to maintaining continuity of coverage for covered licenses.  When matching an owned position to a license that has existing coverage, the MIE will look for a start date of the yet-to-be allocated owned position that falls within a window of plus or minus the number of grace days (as defined in the overarching Entitlement Definition) of the approaching end date of the current coverage.  This is done to ensure continuity of coverage without “wasting” entitlement usefulness by creating a large overlap of periods of performance.  Once the list of licenses with existing coverage is exhausted, licenses that have not had coverage will be considered next.

 

Pre-processing

Prior to running through the priority allocation scheme, the MIE will see if it can match owned entitlements to specific license groups (this is useful, for instance, when entitlements are purchased after the license on a separate transaction, but specifically for previously purchased licenses).  The following criteria must be met:

1. The owned position of the entitlement must NOT have been assigned a serial number

2. The entitlement units must EXACTLY match the license units

3. The entitlement must have been purchased AFTER the license, but no more than N days after.  N is the "Maximum Number of Days After Authorization to Offer Entitlement Through to Portal" from the Entitlement Definition, or 30 (if that value is 0).

If those criteria are met, the MIE will assign the license serial number to the entitlement owned record, which will cause it to be processed by the first step in the priority scheme.

 

Returns

If entitlements are returned (signified by a count < 0 and/or a price < 0) then those entitlements will be spread across active owned position in order to process those returns.  If the assignment of returned units to an already allocated owned position causes it to now be over-allocated, the MIE will de-allocate entitlements on the next Consolidate in order to correct the over-allocation.

NOTE:  It is possible to go immediately from an over allocated position on an entitlement owned position to an under allocated position.  An example of how this can occur is if an owned position record carries a count of 2 units, and is allocated to a license that also has a count of 2 units, and a single unit is processed as a return.  Since the single existing allocation covers 2 units, it will still be de-allocated in order to correct the 1 unit over-allocation that resulted from the 1 unit return.  This will cause a swing to a 1 unit under-allocation as a result.  The now available unit will continue to be attempted to be allocated during each Consolidate run.