While in B2C scenarios a named user license typically provisions a single user, B2B scenarios require the provisioning of multiple users.
If all users of a named user license need to have the same entitlements, the process is as straightforward as described here. However, there are scenarios in which not all users should have the same entitlements within a license (and obviously you do not want to create a license per user). This page explains how and to which extent this is possible.
COMMON VS. USER SPECIFIC PROPERTIES
All properties of a named user license (such as expiration date, features, variables) are shared by all users, except for one: limitations with User Provisioning reset mode.
Such limitations are an extension of the consumption based limitations, but with the following fundamental differences:
- A named user can only consume 1 of the allowed value/quota. Effectively, only the first consumption heartbeat is relevant, any subsequent consumption heartbeats are practically ignored and do not have any influence on the consumption balance.
- If a named user is deleted, the consumption heartbeats are deleted and the remaining balance is recalculated again (rollback).
- If the limitation is reset, all consumption heartbeats are deleted.
The license on the following example provisions 3 users. The limitation "API Functionality" has a value of 3, meaning that all 3 users can consume one, but the limitation "Cloud Backup Functionality" has a value of 2, meaning that no more than 2 users can consume one.
In order for a user to be provisioned for such a limitation, a consumption heartbeat has to be sent.
When a user logs into a B2B application, typically the following method needs to be called:
This method searches for consumption heartbeats in the background for each such limitation. In case there is one, the current_user_transaction_id is populated with the relevant transaction_id.
The current_user_transaction_id does not only indicate an existing provisioning, but can also be used to revoke (rollback) it.