With a token-based Qlik Sense license, you buy tokens and allocate and reallocate the tokens to adapt to changing usage needs over time. You allocate tokens to either named individuals who need frequent access to the system, or to groups of users who use the system less frequently.
Allocating tokens
There are two alternatives for token allocation: user access or login access.
| Token allocation | Access pass description |
|---|---|
|
1 token = 1 user access pass
|
Assigned to a unique and identified named user with unlimited use of Qlik Sense as authorized by your organization’s security policies and rules. |
|
1 token = 10 login access passes
|
Used for infrequent or anonymous access. The login access pass provides full access to Qlik Sense but for a limited time. |
Login access passes
User access passes are straightforward: one token is used for a dedicated user. Login access passes can be shared between different users, and therefore there are more possible scenarios that may require explanation. The following example shows how login access passes are consumed and later returned to the pool for new consumption.
| Day # | Login access pass consumption | Description |
|---|---|---|
| Day 0 |
|
Let's assume that you allocate one token to a group. This gives the group 10 available login access passes. |
| Day 1 |
|
A user assigned to that group logs into Qlik Sense, which immediately consumes one login access pass. |
| Day 1 |
|
When the user remains active after the first 60 minutes, a second login access pass is consumed. This hourly process continues until the session ends, which can happen in three different ways:
|
| Day 15 |
|
A couple of weeks later, the user logs in again and this time uses Qlik Sense for under an hour to do a presentation using both a tablet and a laptop connected to a presentation screen. Because she is an identified user (that is, not anonymous), this only uses one login access pass. In fact, an identified user can access Qlik Sense on up to five concurrent devices during their session with no additional login access passes being consumed. This does not apply in the case of anonymous users as, by their very nature, the sessions cannot be linked together. |
| Day 25 |
|
More than a week later, the user logs in again, using a fourth pass. However, this time she logs out after 30 minutes and then logs in and out again a few minutes later to quickly verify some information. Since the connection to the server occurs within the same hour, only one login access pass is consumed. |
In this example, it is clear that a login access suits the user best, rather than a user access. Nearly a month has gone by and only four login access passes have been consumed. Therefore, two users with this profile could be supported at the cost of one token.
Returning login access passes to the session pool
This section explains how login access passes are returned to the pool. Each login access pass becomes available again 28 days after it was first used.
| Day # | Login access pass consumption | Description |
|---|---|---|
| Day 29 |
|
When 28 days have passed since the start of the scenario above, the first two login access passes become available for use again. |
| Day 43 |
|
When 28 days have passed from the time of the user’s second login, that login access pass becomes available for use again. |
| Day 54 |
|
Finally, when 28 days have passed from the last login, all login access passes are available. |
Estimating the number of tokens you need
To estimate the appropriate number of tokens, you need to identify the needs of different users. Front line managers, business analysts, executives, data engineers, and general knowledge workers all have different needs.
For the sake of simplicity, assume that the users in this example on average consume four login access passes per month. In addition, you need a buffer, because you do not know the exact number of times a user will actually log in each month. In this example, the buffer is 20%.
As mentioned earlier, 1 token equals 10 login access passes. The number of tokens needed could then be calculated as follows:
[The number of people] * [Estimated number of login access passes per person] * [buffer] /10 = Tokens needed
Assume that there are 103 users. The calculation would then be as follows:
103 * 4 * 1,2 /10 = 49.4
You cannot buy a fraction of a token, so round this up to 50 tokens.