KPI isolated from section access

[cedfoning]

hello, i have an issue. 

i've implemented section access in my Qlik sense app.

Before the implementation of the section access, we had a KPI like this : count(distinct siren) = 2500

For a given user after implementation of section access, we have : count(distinct siren) = 400

The users want to have the ratio 400/2500 with section access. 

Can i have some tips please  ?

Thanks

[kaushiknsolanki]

You will have to create a new logical table in data model which will contain overall values for each user. 

For example

Country,ActualValue,TotalValue

india,500,1000

USA,300,1000

UK,200,1000

Now assuming User 1 has access to india he will see both values 500 and 1000, then you can use it in your KPI.

[cedfoning]

Hello, 

I've tried to do that, but not working. 
can you please help ? 

[edwin]

i would aggregate the metrics you want to share with everyone.  you wouldnt want to expose the whole set to everyone as it will defeat the purpose of section access.  leave the aggregated table as an island table - dont associate it with any of your tables that has section access.

i say this as connecting the aggregated table to other tables require knowlege of your DM, this way it is the safest way.  this table may just be a single row which will have the aggregated data such as aggr_siren so you can just add it into your calculation as only(aggr_siren) etc..

[marcus_sommer]

You need to add these total-information as extra data within your data-model. This means you need these data on a granular level on which the section access is applied and a total level which is either not touched from the section access or is excluded from the data-reduction. It's not possible to use only a single data-level to get both views.

Such a second total level could be implemented in various ways, for example like already suggested from @kaushiknsolanki and @edwin  with an aggregation on the total level which might be added as:

1. extra column within the fact-table
2. as a dimension-table
3. as island-table
4. directly concatenated to the fact-table (facts with mixed granularity)

By 1. has each record beside the granular value also the total value. By 2. - 3. the new total field is not directly touched from the section access and runs in parallel and by 4. it's directly included within the section access - whereby here it needs a further adjustments by declaring them as total and adding this total for each user also within the section access table.

4. is also possible without an aggregation - just loading the data twice by declaring them as total and if there are other fields  on a granular level to set these information to null().

An alternatively to the above might be to split the application into two apps - one on a granular level and one with total views. Like the above approaches it creates some redundancy in the overall data and needs also an administrative overhead but it's logically more simple and may (of course it will depend) therefore improve also the usability. 

- Marcus