Section Access is Qlik’s native way of implementing row-level security. It decides who the user is, which values they are allowed to see, and in which field the restriction applies.
What makes Section Access so powerful is when it operates. It is applied before the app is opened, meaning any data that a user is not allowed to see is never loaded into their session in the first place.
That’s why Section Access is the correct mechanism for scenarios such as country-based access, customer-level data separation, cost center security, or controlled access for external partners.
From a security perspective, this is exactly what you want.
The problem is the process of managing it.
Most Section Access issues stem from very human mistakes: mismatches (US vs USA), case sensitivity, renamed fields, outdated Excel files, or overwritten or deleted sources. When something goes wrong, the impact is immediate and often dramatic. Users suddenly can’t access the app, and see no data at all.
Or in the worst case, people gain access to data they shouldn’t see. That’s why Section Access sometimes has a reputation for being “dangerous”.
There are two classic ways to implement Section Access in Qlik
Inline tables are clean and controlled, but every change requires a script edit. What’s more, changes are not easily delegated and don’t scale well when access rules change often.
Excel, on the other hand, feels more flexible—it’s easy to edit (no script changes needed), and it’s familiar to non-developers. But, as we’ve said before, that flexibility usually comes at a cost.
Ironically, a security feature designed to reduce risk often depends on the least controlled tool in the stack.
Inline tables remove Excel from the equation, which helps, but they introduce a different problem: operational friction. For static environments, this may be fine. But in real-world Qlik Cloud environments with many apps and users, the likelihood that it quickly becomes a bottleneck is too high.
“It gets harder as you scale.”
In Section Access Qlik Cloud environments, complexity increases quickly as the number of apps, users, reduction fields, and exceptions grows. What starts as a simple configuration soon turns into access management across multiple apps and spaces, per user and per field. At that point, Section Access stops being a one-time setup and becomes an ongoing operational task.
If you’re a part of a team that manages multiple Qlik apps, you probably deal with frequent access changes in Section Access. How great would it be if rules didn’t have to live in Excel or in the load script? That’s what Inphinity Forms brings you: Section Access becomes an editable, structured table directly inside Qlik. Inphinity is a Qlik-native extension that enables secure data editing and write-back directly inside Qlik apps, without exporting data to Excel.
Just to keep things clear, in terms of system integrity, you still rely on native Qlik Section Access for enforcing row-level security; you just change how the rules are maintained and managed.
Inphinity Forms enables dynamic Section Access in Qlik Sense without manual Excel uploads. The logic stays native to Qlik, and allows Section Access rules to be defined by:
Instead of maintaining multiple spreadsheets or script fragments, access is managed in one place. Example: which user has access to which app → based on which reduction field → which values are allowed.
This video explains how to manage Section Access in Qlik Sense without relying on Excel, using a safer and more scalable approach.
You will learn:
Section Access is the right tool for implementing row-level security in Qlik, but Excel is not the right place to manage it. Why? Because if you (or someone else 🙂) do it wrongly, you can mess up the whole application. Therefore, to remove spreadsheets from the process (= to manage permissions more safely and with greater control) while keeping Section Access native, you can use Inphinity Forms. If you’d like to know more, feel free to talk directly to our tech lead, Guilherme.
