Anonymising individuals while keeping the totals: a Section Access tip

Objectives

The goal of this approach is to reconcile business analysis with the protection of sensitive data. More specifically, it aims to:

• Keep all salespeople in the main table in order to calculate reliable totals and global indicators.
• Anonymise certain salespeople for users who are not authorised to view detailed data.
• Enable analyses such as:
  • “My sales compared to the total of the other salespeople”
  • “All salespeople except me”
  • “All salespeople anonymised”

How it works

The script is based on three main concepts.

The first consists of creating an anonymous copy of the salespeople.

Creating an anonymous copy of the salespeople

Each salesperson is duplicated in the data model under an anonymised identity:

• Salespeople are renamed with generic identifiers (Seller_1, Seller_2, etc.).
• Personal information (last name, first name, office, title) is replaced.
• Individual salary is replaced with the overall average salary of the salespeople, to ensure confidentiality.

The data remains complete and usable; only the identification of individuals is neutralised.

// LOAD THE SELLER TABLE AND DUPLICATE ANONYMOUS SELLERS

Sellers:
LOAD
    ID_Vendeur as ID_Seller,
    "Last Name",
    "First Name",
    "Last Name" & ' , ' & "First Name" as FullName,
    Vendeur as Seller,
    Title,
    "Hire Date",
    OFFICE,
    "Extension",
    "Reports To",
    "Year Salary",
    ID_Vendeur as SELLER_Key,
    0 as Anonymous_Flag
FROM [lib://Rep_Root_Data/SECTION_ACCESS/RAW/Vendeurs.QVD]
(qvd);

Temp_Sellers:
NoConcatenate LOAD
    ID_Seller,
    'Seller_' & Autonumber(ID_Seller) as "Last Name",
    'Seller_' & Autonumber(ID_Seller) as "First Name",
    'Other sellers' as FullName,
    'Seller_' & Autonumber(ID_Seller) as Seller,
    'Seller_' & Autonumber(ID_Seller) as Title,
    'Seller_' & Autonumber(ID_Seller) as "Hire Date",
    'Seller_' & Autonumber(ID_Seller) as OFFICE,
    'Seller_' & Autonumber(ID_Seller) as "Extension",
    'Seller_' & Autonumber(ID_Seller) as "Reports To",
    "Year Salary" as "Year Salary temp",
    ID_Seller & 'A' as SELLER_Key,
    1 as Anonymous_Flag
RESIDENT Sellers;


// Calculate the average salary for anonymous sellers
Outer Join (Temp_Sellers)
LOAD
    Avg("Year Salary temp") as "Year Salary"
RESIDENT Temp_Sellers;

Drop Field "Year Salary temp";

Building a “bridge” table for Section Access

This table defines access rights per salesperson. It contains all possible combinations:

• Access to all salespeople
• Access to all except the current salesperson
• Access only to the current salesperson

// CREATE THE BRIDGE TABLE

SellerBridge:
Load * Inline
[DummyField
];

For Each Value in FieldValueList('SELLER_Key')

Trace Processing: '$(Value)';

// Access: All except current seller (others anonymized)
Concatenate (SellerBridge)
Load
    SELLER_Key,
    'ALL EXCEPT $(Value)' as REDUCTION
Resident Sellers
WHERE
    SELLER_Key = '$(Value)'
    OR (
        NOT Match(SELLER_Key, '$(Value)A')
        AND WildMatch(SELLER_Key, '*A')
    );

// Access: All sellers
Concatenate (SellerBridge)
Load
    SELLER_Key,
    'ALL' as REDUCTION
Resident Sellers
WHERE
    NOT WildMatch(SELLER_Key, '*A');

// Access: Only current seller
Concatenate (SellerBridge)
Load
    SELLER_Key,
    SELLER_Key as REDUCTION
Resident Sellers
WHERE
    SELLER_Key = '$(Value)';

Next

Drop Field DummyField;

Defining the Section Access

Users are associated either with salesperson keys or with anonymised combinations.

The restriction rules are then applied automatically as soon as the application is loaded, ensuring consistent and transparent access control.

// LOAD SECTION ACCESS TABLE

Section Access;

SECTION_ACCESS_TABLE:
LOAD * Inline [
    ACCESS, USERID,                         REDUCTION,      OMIT
    ADMIN,  INTERNAL\SA_SCHEDULER,          ALL,
    ADMIN,  QLIK_SERVER\ADMIN,              ALL,
    USER,   QLIK_SERVER\MATT,               ALL EXCEPT 1,
    USER,   QLIK_SERVER\CHRISTOPHE,         ALL EXCEPT 1,
    USER,   QLIK_SERVER\CHRISTOPHE,         ALL EXCEPT 2,
    USER,   QLIK_SERVER\CLAIRED,            3,
    USER,   QLIK_SERVER\CLAIRED,            4,
];

Section Application;

Managing access rights with the bridge table

The script automatically generates all possible combinations for each salesperson:

• Full access (ALL)
• Access to everyone except oneself (ALL EXCEPT)
• Access only to oneself

This information is then used by the Section Access to control data access dynamically.

Here is a diagram of the modelling steps:

Benefits of this method

• Enables comparative analyses without exposing sensitive data.
• Keeps all salespeople in the table for totals and KPIs.
• Compatible with dynamic data: new salespeople can be added without modifying the script.

This method allows sales teams to compare their performance with that of the other salespeople, without ever accessing confidential individual data. Each user can see where they stand relative to the average or to overall trends, while respecting colleagues’ confidentiality.

Combining anonymisation with a dynamic Section Access offers an excellent compromise between security and analysis: sensitive data is protected, while Qlik’s analytical value is fully preserved.

Before / after anonymisation: understanding the impact of Section Access

To fully measure the value of this approach, it is essential to compare the same dashboard in two situations:

• before anonymisation;
• after Section Access has been applied.

The goal is not simply to hide names, but to ensure that analyses remain relevant, readable and usable despite the access restrictions.