Section Access and different levels of data

[Anonymous]

Hello to all,

I've been consulting this forum for quite some time now, thank you all for sharing your insights! 

So far I've been able to overcome all issues with the help of this Forum, now I've reached a dead end.

I need to create a unified reporting document for different user groups.

I want to provide three sheets (groups of sheets actually):

- per Country (sheet 1)

- per Branch (sheet 2)

- per Salesperson (sheet 3)

Managers should be able to see just their country in sheet 1, just their branch(es) in sheet 2 and their salespersons in sheet 3.

Salespersons should be able only to see their own data in sheet 3 (sheet 1 and 2 have been disabled for them).

I’m using section access to reduce data on the country level (sheet 1) which is working out fine.

Now I need to further reduce date (or limit the filtering options) for sheets 2 (branches) and 3 (salespersons).

I don’t think I’ll be able to do that using section access (again) as I need more data on sheet 1 so if I reduced it via section access data would be missing on sheet 1.

I’ve been looking through the forums for quite some time, unfortunately no luck so far – any suggestions on this?

Thanks in advance!

Norbert

[adityaakshaya]

Hi Norbert,

Can I request you to share the the datamodel, so that I can suggest you the solution.

Regards,

Akshaya

[Anonymous]

Hi Akshaya,

I'll certainly try - can you let me know how to export?

BR

Norbert

[marcus_sommer]

If your data aren't really confidential or if you could ensure that no user could create or change objects you could consider to extend your access control per osuser() which could be used as condition in dimensions, expressions or visibility-conditions. Here an example what is meant: Re: Combining Summary and Detailed Data within Pivot Table.

If this isn't feasible you won't have an alternatively to section access. As far as your access control followed a strict hierarchy you just need to grant access on the lowest level - and user which should get access to multiple levels need also multiple entries within the section access table.

If there are any overlaps between the access rights the above mentioned won't work and you will need some adjustements within the datamodel - mainly in adding extra data for them. In easier cases it might be enough to duplicate some fields and mask the data: Mask or de-identify data for certain users using Section Access and by more complex scenarios it could lead to multiple parallel datamodels within a single application.

But far more easier that that would it be to use just three separate applications ... Many more useful information could you find here: Section Access.

- Marcus

[adityaakshaya]

Hi Norbert,

You can open the application and press Ctrl+T and datamodel schema will come up on the header, you will get option to export. You can export as image and share with me.

Regards,

Akshaya

[Anonymous]

Hi Akshaya,

attached the requested image.

As there are quite some tables, I'm not 100% sure if this is helpful, but I'll try to give an overview:

"Belege" is the table containing all vouchers that are available in the database.

I use "Key_Country" to limit access per user (table "Zugriff") to certain countries via Section Access/Section Application.

Starting from there I want to further reduce the shown vouchers to certain branches or salespersons (depending on who logged on).

I hope the image is helpful - please let me know if I can provide additional infos/details.

BR

Norbert

[marcus_sommer]

I think you should forget section access for a while to develop a working datamodel. For me it looked that a whole database or at least a big part of it is loaded into QlikView without considering which tables and fields are needed and which relation those tables have together and it missed an appropriate naming of the fields - nearly all tables are qualified and the others are creating a lot of synthetic keys.

Therefore I suggest to start here: Get started with developing qlik datamodels.

- Marcus

[Anonymous]

Hi Marcus,

I was afraid a suggestion like this would pop up.

QV has been introduced some years ago as more or less out-of-the-box reporting/analysis tool tailored to our ERP, loading the better part of the DB.

I think this out-of-the-box solution has led to what you see on the model. I've been able to close some of the gaps that came with this approach (and maybe created some new ones), nevertheless I don't want to start a major clean-up operation if not absolutely necessary.

I think there must be a solution to what I need without optimizing the base data at the moment - don't you think?

BR

Norbert

[marcus_sommer]

I know what sales people say (not only within the Qlik environment - nearly all companies in all branches do the same) and which impression they try to convey and how easily the management on the other side believe how successful they will be with nearly no efforts - they just want to see the great potential without any thought about how it worked and which preparing on systems, processes and the knowledge of the people and so on is necessary.

Both sides have often no idea what they are doing and mostly they don't even know that they do not know ... But they are all happy ...

I personally wouldn't trust the results which such a datamodel will produce and at least within the mid-term I suggest to change it into a "real" datamodel.

If you want to keep it at the moment and to implement an access-control on this stage I suggest to read my first answer here again: Re: Section Access and different levels of data.

- Marcus

[Peter_Cammaert]

As a small suggestion in case you decide to redesign your data model as suggested before, consider this:

At the one end: If your Country-Branch-Salesperson hierarchy is organised in a strict way, meaning that the lower levels only occur in a single instance of a higher level (e.g. one Salesperson is reponsible for sales in a single branch in a single country), then your Section Access table only needs to assign Salespersons to SA User IDs. The higher the management level of a User, the more Salespersons this user will have access to. The use of a wildcard for the ceo would avoid an endless listing of Salesperson, but you may have to handle wildcards yourself as the Section Access star is restricted to all values that appear in the SA table, not all that appear in your data model.

At the other end: If your Country-Branch-Salesperson hierarchy is actually not a tree-type hierarchy and any country can occur in combination with any Branch and any Salesperson (the most flexible sales setup), then you will need to include all levels in your specifications to link User IDs to your data model. For example, the ceo must be linked to all existing combinations of Country+Branch+Salesperson (or using wildcards, the ceo is linked to *|*|*) and at the other end a single Salesperson may be linked to two different branches in two different countries. Like US|Toys|Bob and UK|Boats|Bob so that by way of reduction Bob will only have access to those branches in those countries.

Your optimal solution may lie inbetween those two extremes and the required script code to get a working system will correspond to the complexity of your Country-Branch-Salesperson hierarchy. Wildcards may reduce the required list of specifications for high-level management and will be easier to maintain, but will require more complex script code.

I shouldn't worry too much about Sheets1, 2 & 3. They will fill themselves automatically with the data that remains after proper reduction. As a result, a Salesperson will only see his/her sales data in his country on sheet 1, in his/her branch(es) on sheet 2 etc. Sales executives will see their own data and data for all Salespersons for which they are responsible. Thestandard QlikView selection tools will enable them to focus on a particular Country, Branch or Salesperson if they chose to do so.