This post isn’t necessarily made to teach you what Section Access is, but rather to help you better understand it and provide you some tools to help troubleshoot it.


Admittedly this took me 6-7 years of using Section Access to fully understand what the keywords Section Access and Section Application did. Essentially, you can think of a Qlik Sense (or QlikView) load script to be defined in two parts. First your application part, which defines everything on your Qlik application. Second is your security part, which defines the security portion, meaning it isn’t defining your application but the security on it. 

Section Access basically signifies to the Qlik interpreter that we are now defining our access portion. Who can access What? Section Application then tells is that we are resuming defining our application.

This helped me better understand what each of the keywords did and when to use them.

Security Table

The security table is there to define the… well security. The easiest way to think about it is that the table defines a pre-selection for the user. The data associated with that selection is what they have access to. 


    • ADMIN – Does not apply Section Access to user
    • USER – Applies Section Access to user
    • DOMAIN\USER of user access Qlik dashboard

Tip: Use “=OSUser()” in a KPI chart or the Users page in QMC to see

    • User directory Group attribute to use to define rule.
  • OMIT
    • Field to omit from user’s model.
  • %FIELD%
    • Name of field to link to a data table to apply row level security, or key to omit table, which contains OMIT field.


There’s nothing worse than releasing an application into the wild and receiving a bunch of emails saying that they can’t access the dashboard, or worse that their colleagues are seeing data they aren’t allowed to see. 

Since Section Access acts as a selection it is very simple to test. What I suggest you do is comment out the keywords and create a simple sheet and test the user’s access. You can filter on USERID to limit the data to what they will see when Section Access is applied.


User – Test

User – BardessGroup

Limit Table

I have over the years grown to always create a bridge table between my security table and my data table. This is because I want my security table to be one row per user. The limit table will then define the association and therefor security. Similarly, if you are using OMIT, I will create an omit table which contains the fields to omit and the group which is tied to those. This is to keep the relationship 1 to many and my security table one row per user.





I truly wonder how much time collectively the Qlik Community has spent troubleshooting Section Access and the culprit was that the data wasn’t upper case. Make your field names and value UPPER CASE. It will solve so much headache in your future to remember this. 

Tasks Fail

If your reload succeeds when ran by you in the hub but fails as a task, this is because the Qlik service account doesn’t have access. In Qlik Sense this is INTERNAL\SA_SCHEDULER. Make sure to add it to your Section Access security table as an admin. 

Access Denied

If a user cannot open the application from the hub, then they are not in the Section Access security table. 

OMIT Experience

If you omit a field for a user and a chart uses that field as a dimension, it will cause an error. To account for this you will need to make sure there is a calculation condition on the dimension/measure so that it is hidden for the users that do not have access to it. That or leverage a Hide/Show mechanic in a container to replace the chart with something else that would be useful. 

What I typically do is add an expression in the calculation condition:

Example – Omit field pii


I make sure I am using the set of 1 {1} so the user’s that do have access to the field aren’t affect by the condition because of their filters. Additionally, I am checking the MaxString value so it works for both text and numeric fields. If the field doesn’t exist, it will return NULL which Qlik will return -, hence the condition of Len() > 1.

User With Access

User Without Access

Hopefully this helps. I know I could use back the day or three I’ve spent banging my head against the wall working with Section Access.