Policy Overage Strategy Options

[nCubed]

We are currently working on a multi-user licensing model and are thinking about applying an overage strategy

Current overage options:

• ALWAYS_ALLOW_OVERAGE
• ALLOW_1_5X_OVERAGE
• ALLOW_2X_OVERAGE
• NO_OVERAGE

After some internal discussions, we were wondering if a slightly lower overage strategy could be used: ALLOW_1_25X_OVERAGE

In other words, we're thinking a 50% overage is a bit high and would like to use a 25% overage. Can you provide some insight as to why the overage strategy is limited to just 50% and 100%?

[ezekg]

What is your max machine limit that warrants a 1.25x overage? We limited to 1.5x because it's non-zero divisible when limit > 1.

[nCubed]

Our software will be used by universities in lab settings. Where a lab may have around 20 machines. If the university purchases a 20 user multi-seat license, we feel an acceptable overage would be around 25%; whereas 50% is bit too much in the team's discussion.

[ezekg]

That makes sense. I'll get a 1.25x overage added. I'll ping you.

[ezekg]

Added. Limits on the policy must be divisible by 4, of course.

[nCubed]

Thanks Zeke.

What happens if a customer purchases 22 licenses? Will the overage return TOO_MANY_xxx at 25 or 26 machines in use? Or will the overage not be enforced and fallback to one of the other options?

We don't really have a way to enforce customers to purchase licenses in blocks of 4.

[ezekg]

Given a limit of 20 machines on the policy, once the license exceeds 20 machines, it will start receiving a TOO_MANY_MACHINES validation code across all validations. But the validation will still be { valid: true }. So technically valid, but flagged as exceeding their policy's limits. They will not be able to exceed 25 machines, or 1.25x their limit, and any attempts to do so when activating a machine will fail with a machine limit exceeded error.

[nCubed]

Thanks for the clarification. The notes in the docs and here about resources must be divisible by x was a bit vague as to what would occur if they were not divisible. Appreciate your assistance.

[ezekg]

That's for policy creation. Attempting to create a policy that doesn't follow the division requirements will fail.

Nothing to do with creating licenses or machines. Just making sure the policy is configured correctly.

[nCubed]

To be clear, if we have a customer who wants 20 licenses and another who wants 33 licenses, then we must create a new policy for each group of floating licenses?

If the requirement for using 1.25x overage is the max machines must be divisible by 4, then the first customer's policy (20 licenses) will be created w/o error. However, the second policy (33 licenses) will fail to be created b/c of the divisible by 4 requirement?

Assuming that's correct, what are you recommendations for creating a policy for the second customer?

[ezekg]

That's correct. I would recommend creating policies for predefined tiers that are divisible by 4, or assert customized seat numbers are divisible by 4. Otherwise, use a different overage strategy for policies with incompatible seat counts.

The 1.5x overage option has a similar requirement, where it must be divisible by 2.