There are a number of different licensing options with QlikView. Most people are aware of Document and Full User CALs, in this post however we look at the pros and cons of Session CALs.
QlikView Licensing 101
Many people first experience of QlikView is through the free personal Desktop version. This can be given extra functionality by purchasing a Desktop licence. When multiple users have Desktop licences they can exchange and collaborate on documents, but management and distribution is cumbersome at best.
To get apps out to more users, via a web portal, a Server licence is required. These come in two main flavours: Small Business and Enterprise, with the later allowing more users and a few extra features. There is also an Extranet Server, for distribution beyond employees of the licenced organisation. The Server licence is purely for the hosting services, and User CALs are required to give users access to apps – more on these in a moment.
If you need to scale up into multiple machines (or large numbers of users) then Enterprise Server is required and additional licences are needed for load sharing, and a Publisher licence allows distribution to multiple locations (along with a number of other features).
The two common user CALs available are; Full User, which allows one user access to unlimited apps via the server and the ability to ‘lease’ a licence to their QlikView Desktop to create apps, and Document CALs; which allows one user access to one QlikView app via the web portal only. With a Full User CAL costing approximately four times a Document CAL if a user only needs to consume three or fewer apps they should be given a number of Document CALs, if they require more apps then the Full CAL makes more sense.
This is where most organisations leave it, buying more user CALs as usage increases. There is a point though where Session CALs become a cost effective alternative.
What Are QlikView Session CALs?
Whilst both Full User and Document CALs are assigned to a user and remain with that user until they are cleared down; QlikView Session CALs are only attached to a user whilst they are in use. When a user comes to a document that they don’t have a licence for, and there is a Session CAL available, the Session CAL is allocated to them. This licence is held by that user for the duration of their session and is freed up after fifteen minutes of inactivity.
Another difference between Document CALs and Session CALs is that even when Document CALs are set to auto allocate they have to be associated with a document (as the name suggests). You can have many free Document CALs available on one document but if a user without a licence tried to open a different document, which has no free CALs, they will be denied access. Session CALs conversely are tied to the server, so this situation does not arise, if a Session CAL is available it can be used to access any document.
A quick side note on a common misuse of licences; these should never be used for security. Whilst technically a user can be denied access to a document by not having a licence, security should be left to Active Directory or Section Access (or both). A user you are keeping out of an app by not giving them a Document CAL may at a future point get this access by virtue of being given a Full CAL, for instance.
Session CALs come into their own when you have a very high number of users that use the system sporadically and in short bursts. Companies with users in many different timezones could certainly benefit. You simply need to have enough Session CALs available for the highest number of non Full CAL users that may use QlikView in any given fifteen minute period. If a user is locked out due to no CAL being available they can simply try again a bit later and may then be able to get in. By giving your high usage individuals Full CALs the number of Session CALs required is reduced.
System logs track how many licences are being used concurrently, so you can tell when you may need to add another Session CAL into the licence mix or move some users onto Full CALs.
Session CALs allow your system to flex to the usage with a minimal amount of administration time spent. Brilliant!
The Downside To Session CALs
If that all sounds too good to be true then it is probably because I have yet to mention the flip side.
Firstly, Session CALs can only be used on Enterprise Server. This is quite a price hike from SBE, so if you can work within twenty five Full CALs and a hundred Document CALs then that may work out best for you.
Session CALs themselves are also relatively expensive. About the same as ten Full CALs. If your usage patterns are as I described above (lots of users, using many apps in short bursts) then this may not be an issue as you could have many more than ten users using one CAL throughout each day.
By their nature Session CALs are not ring-fenced for certain users or applications. This means you have less control over how they are used. What this means is that it is possible that even with the best planning someone could be presented with a message advising them that there are not enough licences available. You need to weigh up whether that is a scenario you can tolerate happening. What often happens is that the execs get Full CALs, even if they are not big users of the system, just so they never have to see this message. For one of our Session CAL using clients we have set up an alert (using QlikView) to notify when the last Session CAL is taken, users can then be asked to close their session if they have finished using it.
Getting The Right Mix
It is possible to blend Named CALs, Document CALs, Session CALs and Usage CALs all on the same server. Assigning Document CALs to some documents is one way of ensuring that the documents that are most critical are less likely to be inaccessible by users. Another way of having a backup when all Session CALs have been consumed is the Usage CAL. These are the least expensive licences, you can get about fourteen of these for the cost of a Full CAL, and they allow one user access to one document for one hour every 28 days. If a user is in a document for longer than an hour then two CALs will be consumed and the CALs will not be available again for the next 28 days. Usage CALs are therefore a relatively low cost buffer for when all other CALs have been consumed, but given the limited time each CAL gives and the length of time they take to renew they are not suited for every day use..
Conclusion
In short, the biggest downside to Session CALs is the cost. Conversely though, this is also their biggest advantage. In environments with particular usage patterns they can offer a significant saving over Document and Full User CALs.
To work out if they are the right approach for your business you need to look at your server logs and usage patterns and weigh up the alternative licence mixes. As you may not get this right first time it is good to know that Qlik do offer the opportunity to swap one kind of licence for another.
If you are unsure, speak to someone who can advise you of the best licence mix. As Qlik Partners in the UK we will be happy to discuss licencing and advise on the best value licence mix with those looking to move to QlikView or Qlik Sense (or existing Qlik users) in the UK.
Session CALs can be mixed with Document CALs!
Usage CALs are an ideal option to handle spikes in Session CAL usage.
Hi Stephen – thanks for your comments. That is a new one on me about mixing Document and Session CALs – one of my clients was advised they would need to swap all of their Document CALs for Session ones. I can see that a mix of these would be very useful. This way the apps that need to be ring fenced and be always available could have document CALs assigned to them.
I’ve never really considered Usage CALs, as you have the risk of a user not being aware of the hour long slots consuming all of the usage CALs before the month is up and they can be reset. I should probably go back and add a note about these to the above…
We use a combination of Named, Doc, and Usage CALs. Qlik really needs to rethink (out of the box) its licensing model. They should borrow the methods used by the Cloud Services (e.g. AWS) paid for what you use instead of trying to “guess” and leave customer (users) hanging.
great post, Steve, and just in time for me! we recently converted some of our user CALs to session CALs and I am a bit on a fence about it. The thing is I have dynamic CAL allocation enabled on a server so before conversion it was pretty easy to manage – security is implemented using AD groups and then users who have access would get CAL assigned dynamically. Once a month, I would remove CALs for users who have not used QV in the past 30 days using User managers tool from Power Tools – I loved this and everyone was happy.
Now once we converted, things became more complicated – what I did not realize that Session CALs kick in ONLY AFTER all the user CALs are depleted which happens pretty fast in my case. Once they are depleted, session CALs kick in but only for normal users – developers cannot lease a license anymore from a server, because all user CALs are taken. So i am forced now to clean up the CALs manually.
Qlik is telling me now that I should disable dynamic allocation of CALs and manage them manually which is I do not really want to do – we have over 400 users and I am quite a busy guy :)
Is your experience similar? do not you think that Qlik should improve this process and use Session CAL as a priority?
I would say that Session CALs should not be the primary and that the way it is currently implemented is correct.
It begs the question – if you converted to Session CALs because you wanted to not have to manage dynamic allocation of named CALs, why still have the dynamic allocation?
Hi Stephen, we kinda wanted both – to have dynamic allocation for QV developers so when can lease a license without manually assigning a CAL to them. But at the same time Session CALs were recommended by Qlik to handle users who are not using QlikView frequently.
What I did not expect is what i need to manager now User CALs manually or clean them up to let developers lease a license.
I don’t think that your use-case is the norm, and very probably not what Qlik would want – licenses shouldn’t be really dynamically re-allocated. You could, of course, do something with the power tools or QMS API to automatically allocate/de-allocate users (that haven’t used the system for XX days) via some kind of self-service portal.
QVS will check for users based on a hierarchy of license types – Named, Document, Session and Usage. This is as designed and isn’t going to change any time soon.
I appreciate your comment, but I tend to disagree respectfully with QlikView’s guru like yourself (thanks for all your blog posts!).
Based on conversations I had with Qlik, a lot of customers complained about very confusing licensing model and the license management specifically especially in enterprise setting. Some told me that this is why Qlik created totally different concept for Sense :)
As for dynamic de-allocation – this is a totally valid approach. Actually the 30 days number came from license lease duration which happens to be also 30 days :) Power tools just helps to ensure the CALs are removed.
What I do not want to do is to manually assign licenses to all 400 users, I have enough on my plate :)
Boris / Stephen,
Thanks for all your comments. I know where I have sites with a mix of Full and Document or Session CALs the Full CALs are not set to auto allocate and are managed manually. Generally those that need to lease a licence or consume many apps do not change that often. This way you can ensure that the most expensive licences are reserved for those that really need them. I’ve added some tables to Ops Monitor (based on an extract using QV Server CAL Manager) to show which Full CAL users are using them least and should have them manually revoked and which Document/Session CAL users consume most and should be given Full CALs.
This tends to work, with the usage patterns I’ve come across, but appreciate that your experience may be different Boris.
Personally I agree that the way that licences are allocated with the most costly available being given out first (i.e. Full CAL before Session or Document) serves Qlik better than their customers. I would have thought that in most cases users would want Document CALs consumed first, with full CALs reserved for manual assignment for Developers and high volume users – unless all Document CALs are already taken.
I have a client with almost 5000 named cals and no other license types. I am thinking this is cost prohibitive and they should convert some to Session Cals as there appears to be many users who are on for short bursts. They have the governance dashboard to analyze the usage. Would be nice if there was a “calculator” of sorts to determine the best combination of licenses. Hmm… maybe that would be a great addition to the governance dashboard. Who has the algorithm for this? :-)
Hi Debbie, I would say that a number of Session CALs would definitely be the way ahead here. The question is all about concurrency, and whether usage is spread out or if it comes in clumps – which could cause a problem for Session CALs. The good thing with Session CALs is that they only get used when other CALs are not available – so if you get your top n% of users Named CALs and converted most of the rest to Session CALs then the Session CALs would only get used for occasional users – so would stretch a long way. A good smattering of Usage CALs as well would provide a bit of a buffer, if the number of Session CALs you go for it not quite right.
Hi Steve,
We have a situation where we are having users in US,UK locations not able to properly load the dashboard whose server is placed in India.
We are thinking of setting up an extra-net server in US and then assigning session cal for users. Is that the correct approach or should we upgrade to EE server from SBE and use clustering servers in US and UK.
Our India user population is around 15 , UK 15 and US 20. Kindly advise if session cal with QES will work
Hi Siddarth,
The extranet server will not in itself improve the situation. The tech behind each of the different server types is exactly the same, similarly with the licencing nothing will change by changing licence type. Your best bet will be to place a Small Business Server in both the UK and US locations you can then copy QVW files to each of those locations to be run locally. If you have QlikView Publisher you can configure this to push apps to different servers. If you do not you can use a separate scheduler to do the copy – but you will need to be careful of conflicts (i.e. copying before a file is fully updated).
If you want the UK arm to purchase their licences independently then please put them in touch with us, as we will be happy to supply. We can also recommend a partner in the US to assist there. This will in both cases also mean that they will have local support.
Hope that helps. Steve.
great post, how did you “set up an alert (using QlikView) to notify when the last Session CAL is taken”?
thank you
Hi Daniele,
I have a QlikView app that parses the Events log table. When any CAL is used the type of CAL is written to the event log. When it is a Session CAL the number of CALs in use is written also. The total number of Session CALs is in a config file, and when one value matches the other then there are no Session CALs left. I use a simple QlikView Alert to then send an email notifying people of this.
Hope that helps.
Hi All,
Had a quick question regarding Session CAL’s. Can access be restricted to only a particular dashboard on using Session CAL’s? I have heard frequently that Session CAL’s cannot be ring fenced to a single project/dashboard. What does that mean exactly?
Hi Erwin, with a Document CAL you assign these to a particular QlikView app, and they will only be consumed by users of that app. With a Session CAL it will always give access to any app. If you have one application that you don’t care whether users get locked out of it and another you always want to use your Session CAL on then you are a little stuck. Probably the most important thing is to limit access to applications by Active Directory (or other security) so that users can not get into the apps that you are not intending them to use – and will therefore not consume licences.