Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Security Design for Sales group/office

Former Member
0 Kudos

Hi guys,

I need some clarifications on how to restrict or design roles for so many sales groups and so many sales repsu2019. If I would create one master role and it has for example va01 or va02 and I have to assign this access to 60 sales Reps and they all have a separate sales group assign to them and some of them are in different sales office as well. We also have 60 sales goups for each sales Rep's

My questions are:

1) Am I going to create 60 derived roles with each sales group (org value).

2) Or Should I ask my programmer to create customer exist if it is possible

3) Or is there any other way to accomplish this

I never have seen 60 derived roles for sales groups with same master role. What is the normal design approach to do this?

Can any body please give me the security design approach for this scenario?

Thanks in Advance

Faisal

4 REPLIES 4

Former Member
0 Kudos

Hi Faisal

60+ derived isn't unusual - release strategies can get way above that.

If sales group is an org level then derived would work but do you know if there are any related object level maintained values which also need to be different please? If there are (say cost centre) then adjusting the derived will give all the derived role the same object driven values so that wouldn't then, be a safe option. (I hate derived).

THere is the other even more hideous option of using task - value roles where you create one main task role (for VA02 & VA02) but it's org levels/objects that are to be different are left empty of the localisation values. This means you only have to maintain one role should you need to do if you are lucky.

The value roles contain all the objects with their individual localisation values, you assign one main task role and any number of value roles to the user to allow access.

This tends to confuse the hell out of the admin teams (especially if not familiar with the concept) and it can lead to authorisation failures which can lead to a S&A person new to the business adding the objects' values directly in the main role once they see all the 'reds'. You also have to watch out for new localisable objects brough in when adding a new tcode.

There's the structural auths option but I know bugger all about how that works unfortunately.

Cheers

David

Former Member
0 Kudos

I agree with David, this is exactly what derived roles are for. Stick to the standard concept as much as possible.

@David - structural auths are for the HR side of things so won't work in this context. It's fair to say that they are "an experience" to work with.

0 Kudos

Hi Alex

Did say I knew bugger all about structural auths - I'll stick to what I just about grasp

Many thanks

David

0 Kudos

Thannk you so much guys

I'll stick with Dereived roles