Qlikview Section Access - Unique use case for row level reduction (2 or more fields)

[siddharth_kulka]

Hi Qlikies,

Come across a unique use case which I am unsure if can be resolved with standard row level data reduction that comes out of the box with section access. Any guidance would be of great help as this is a blocker in terms of the client adopting Qlikview going forward.

For the sake of communicating the requirement, lets assume the data model has below 2 tables (linked by the field Client). 

Accounts:

Client	Income
A	10
B	20
C	25

Call Reports:

Client	Call Report ID	Type
A	1	In-Person
A	2	Face to Face
A	3	In-Person
B	4	Face to Face
B	5	Face to Face
B	6	Face to Face
B	7	In-Person

Requirement:  Reduction needs to happen at the Client level (straightforward). However,  'Call report ID's also need to be further restricted based on the user.

Example: 

a: User1 (John) should only have access to Client 'A' and Call Report ID '1' (If reduction field is set as client, John will see call report IDs - 1,2,3 which is why simply reducing by client won't work)

b. User2 (Steve) should only have access to Client 'B' and Call Report ID '4,5,6' (If reduction field is set as client, Steve will see call report IDs - 4,5,6,7 which is why simply reducing by client won't work)

Note: The data model has 10 other tables, the solution needs to be applied across the board. As some of you might have realized, we are attempting the inherit Sales force entitlements in Qlikview.

Is this feasible? Kindly share the working solution ASAP if you could.

Regards,

Sid

[Vegar]

I'm not sure if I get your problem correcty, but couldnt you just have two reduction fields in your section access, Client and Call Report ID? Like this:

Section Access;
LOAD ACCESS, USERID, PASSWORD, CLIENT, subfield([CALL REPORT ID], '|') as [CALL REPORT ID]
INLINE [
ACCESS, USERID, PASSWORD, CLIENT, CALL REPORT ID
ADMIN, ADMIN, 123, *
USER, USER, 123, A
USER, JOHN, 123, A, 1
USER, STEVE, 123, B, 2|5|6]
;
Section Application;
LOAD * INLINE [
CLIENT,Income
A,10
B,20
C,25
];
LOAD * INLINE [
CLIENT,CALL REPORT ID,Type
A,1,In-Person
A,2,Face to Face
A,3,In-Person
B,4,Face to Face
B,5,Face to Face
B,6,Face to Face
B,7,In-Person

];

[siddharth_kulka]

Thanks

Not sure if anything changed between versions, but my understanding was that section access does not support multiple reduction fields. Will try it out though.

[Vegar]

It supports multiple reduction fields, but it is inclusive, just as you
would make a selection in your application.

You can not create a rule that gives Steve the right to see the (Call
Report ID 1 for Company A) AND (Call Report ID 2 for Company B), but you
can give Steve the right to see Call Report ID 1 and 2 for Company A and B.

[siddharth_kulka]

Sorry, not sure I understand.

The requirement is that:

John should ONLY see Call Report ID 1 for Client A. Steve should ONLY see Call Report ID 4,5,6 for Client B

To add: John could also be required to ONLY see Call Report ID 4 for client B in addition to Call Report ID 1 for Client A.

Also, the analogy to the selection is unclear to me:

Off tangent - If a sample table is created as below with list boxes Name and ID on the UI, 1 is associated when John is selected, 1 ans 2 are not associated when you select John. It could be due my lack of understanding of what is being communicated, please clarify if possible.

Name, ID

John, 1

Steve, 2

[Vegar · Accepted solution]

You can not do this: "John could also be required to ONLY see Call Report ID 4 for client B in addition to Call Report ID 1 for Client A".

You should look at section access as if you make a selection in your data model.
If you use this section access table below then John will see Call report ID 1 AND 4 for both company A AND B.

Section Access:
LOAD * INLINE [
ACCESS, USERID, PASSWORD, CLIENT, CALL REPORT ID
USER, JOHN, 123, A, 1
USER, JOHN, 123, B, 4];

[rwunderlich]

You can either use generic keys 

https://community.qlik.com/t5/QlikView-Documents/Generic-keys/ta-p/1496560

or make composite keys

Client & '-' & [Call Report Id]

and make your reduction on the composite key. 

-Rob

[siddharth_kulka]

Hi Rob,

Using composite keys is less of an option as the fields to be used are in different fact tables tables and cannot be brought into one by joining or link table creation.

I can explore generic keys and revert back with findings.

Thanks for your input.

[siddharth_kulka]

Spoiler

@Vegar - I was able to meet the requirement by using multiple fields which would link to different tables in the data model. In all honesty, I did not know that section access supported multiple reduction fields. 

Your inputs saved the day, thanks a lot!

[Vegar]

I'm glad to hear that my input could be of help.

-Vegar