How often do you really implement Section Access in an organisation? What lessons have you learned?

[mwallman]

Hi,

From speaking to some developers it seems like while Section Access is a good thing in doing data reduction and ´hiding´ field information, it seems to cause a lot of problems down the line in showing data that may be universally wanted by users while also hiding other information.

How often do you really implement Section Access in an organisation?

What lessons have you learned from using Section Access?

I know other approaches can be to do loop and reduce or build specific apps but sometimes customers want everything in one thing and it becomes complex.

[Miguel_Angel_Baeyens]

TL;DR: Always use section access

After working with Qlik from quite some time, I would not expect to create a "serious" application without applying section access all the times. Obviously, you must have the need, but nowadays I cannot think a real use case where you wouldn't want to use it, other than a proof of concept with demo data.

That does not mean that each and every application should have it, although in large deployments, I would strongly advise to use it in non-user facing apps as well.

For one, section access makes more difficult for people to download the app, even if they have access to the servers, and open it. The reduction of the data keeping one single application and one single data model is also quite convenient.

Loop and reduce could be a good solution if the number of types of users is small (e.g.: managers, employees) and if data can be "lost" without concerns (e.g.: I email my application to another user, who is not supposed to see the same I can see and that's OK).

After all, it all comes to what do you want to achieve, how big is your deployment and user base, how your security policies must be applied, how sensitive is the data, and how much maintenance do you expect for your applications.

[marcus_sommer]

Section access is only one measure to control the access on data and needs to be embedded within a sensible security-strategy. I'm not sure that many companies have one because it needs beside the IT part a capable management which is able and willing to understand the effects of their actions. Their concepts are often unclear and with (many) gaps on one side and too restricted on the other.

For example, we have a few different section access scripts implemented (mostly within the apps for the standard-user) and it's quite normal that users with more rights print/export and mailing the data to those with lesser rights. Also most of the users could just go into our ERP and access the data there - ok. it's not so easy like in QlikView but from a security point of view the whole concept fails.

It's a quite long introduction to my main-point that I doubt that it makes much sense to restrict user to their detail-level-access and giving them at the same time access to aggregated data on a highler level. If they should be able to compare their data with a higher level why not giving them also the details - what do you want to compare if you don't know the details, from where and how they are created ...

Of course you could do it if you creates more or less expensive double-structures (extra tables with aggregated data) and/or using a masking-approach but it leads to more complex applications without much added value - at least in my opinion.

- Marcus

[Peter_Cammaert]

Usage of Section Access in

• Larger enterprises: all the time
• Small to medium-sized companies: depends

I wouldn't call Section Access particularly complex. It has its limitations and quirks, but they are fairly easy to learn and manage. Section Access is not a magical solution for solving any kind of issue with for example complex data models, licenses or user roles (for that it would be good if QV could be synced with Qlik Sense some time in the future) and it doesn't offer you any kind of management assistance. On the other hand, Section Access is a very simple  (and I would almost say *elegant*, but I don't think many would agree) technique for building all sorts of custom access and security mechanisms, purely based on the common Qlik rules and technologies.

What I have learned from using SA for some time: KIS(S) (as with everything QlikView)