"Advanced" section access, low granularity, administration and real life applications?

[Peccus]

Hi,

First post here so bear with me.

We have a qlikview-solution currently in place. The Section Access-rules are defined in a excel-sheet that is maintained by IT. Now, we are looking to move to cloud and I would like to see if there is any way to apply a better row-access-model, and also limit/remove admin from IT for new users.

The requirement is such:

We have a organizational-hierarchy within the business, it has several levels and lowest level is salesman. Different salesmen have different security-access, some gets to see its own figures only, some gets to see others, their managers get to see whatever branch they are in charge of, sometimes a salesman has a bigger responsibility and his security should be equal to the managers. So basically we need some kind of tool to help us pinpoint individual access down on row level.

Technically I have got this working using a concatenated row-key in the fact-table and a access-table that holds all fact-dim-keys relevant. But, how do I manage the administration of this solution?

I was thinking of some kind of self-service portal where the manager gets to approve every request, this would split up all admin to a more manageable workload, but then there will always be the issue with ppl changing positions or quitting their job.

So its more of a administration-question than a actual qlik questions... How do you ppl admin the "section access"-excel sheet (or equivalent) in your prod environments? Pros/Cons? I am a firm believer of not making solutions in IT that also builds on every-day admin for said department.

[marcus_sommer]

I believe that anything in the direction of self-service isn't helpful. Each manager of the various manager-level needs to get the appropriate access rights for this source which isn't reliable possible in Excel else would need any kind of data-base and they would need to maintain it constantly. Such approach would of course divide the maintaining work but IMO it creates an extra layer by adding more complexity without an added value.

Saying this it means that I do prefer a centralized logic (which would enable an Excel solution) whereby this mustn't be done by the IT else more suitable would be that the Sales or the HR department does the job which have the origin information without an extra communication between the departments.

Beside this I suggest not to apply access rights to single users else to (nested) user-groups and ideally to transfer the access rights of the report-data from other system-data (active directory) and/or CRM and/or HR (salary-assignments) and/or similar information. Further helpful would be implement a quite straight access logic without (much) exceptions maybe with one or two extra manager-level if there is really a need for super-user or mentor roles who should see more as their direct level but don't getting the next higher level.

Further you may consider to split the application for different access requirements to simplify not only the section access else the entire user-experience. We have done it for some of our sales reporting which is separated in reports with employees (each manager could see only their own staff) and without employees in which the manager could access one or sometimes two higher level.

[Peccus]

Thanks for your response Marcus.

I like your thinking with regards to the AD-groups, but seeing as we have need to control the data access down to each salesman, that would mean one group for each salesman? Going to be a LOT of AD groups in our case.

I did look through having the access-rights being "inherited" from other systems, but so far I have failed in finding something appropriate to get it from. The idea of a "straight access right" driven from the organizational hierarchy is something I am pushing as well, but we are a large organization with many different ideas of what is good to share and not... Its a mind set that will take a lot of time and politics to alter. Meaning I have the need of a solution that can cover all angles and exceptions. Its a bit of a mixed wish-list so I feel a bit stumped.

The last part is probably the one closest to what I want to achieve, to build not one application but several (from the same data source), each one directed to to a specific user group. 

Why do you feel hesitant towards the self-service style of approach? If I could manage to get some type of "request and get the request evaluated from your boss"- workflow going, in theory it would be a self-playing piano. (not sure that is a valid expression in english) In theory. 🙂

[marcus_sommer · Accepted solution]

In my experience is self-service far more a nightmare as a stable and practically approach. Even centralized maintaining tasks are causing often much trouble with not or not correct maintained entries. And by multiple users and especially the sales-manager levels who would really hate to get responsibility of administration tasks - it would be even worse.

We have section access only implemented because of compliance and legal requirements as part of a general access-control and it's working like needed but the users bypass many of them by printing, exporting and sharing it quite carelessly.

If the company isn't really willing to simplify and standardize the business processes it's a not solvable task else it will further cause more or less manually efforts and errors. But you may be able to move the task to another department to minimize the above mentioned communication and to reduce the costs because the other departments are probably cheaper as the IT guys.

[Peccus]

Many thanks for your thoughts Marcus.