Concept of Value, Task & Template Roles

[Former Member]

Hello,

Can anyone explain the concept of value roles, task roles & Template roles in SAP? I have heard about single, composite, derived roles in sap.

Also, can there be a transaction in derived roles independent of the parent role? i mean that a transaction that i could add to derived role only in addition to the transaction that derived role with inherit from the master role. if yes, what will be its affect on auth. objects etc..

Kind Regards, Ben

[Former Member]

Hi Ben,

I don't think I have understood your first question right, so I will skip that.

Coming to the second part "Also, can there be a transaction in derived roles independent of the parent role? i mean that a transaction that i could add to derived role only in addition to the transaction that derived role with inherit from the master role"

No you cannot(should not) add a transaction code directly into the derived/child role of a parent. Derived roles are designed to have the same functional/transactional access as its Parent role; and it will differ from the parent only in terms of the org-level value accesses.

So except for org level values; all other access in a child/derived role should be inherited from its master role and hence should be exactly the same as the master role.

You should never maintain transaction/object level access directly in the child role, it should be added in master instead and 'adjusted' into the child role(s) of that master.

Let me know if you need more help with it...

Soumya

[Former Member]

Hello Soumya,

thanks very much for your input.

Kind Regards, Ben

[Former Member]

Hi

Single, composite & derived roles are technical role types. Value, task & template are descriptions of how roles can be used and can often have different meanings. The most common ones are:

Task: A single role (or could be a derived role) that represents a small piece of functionality such as create PO, display SO, create journal, change material etc.

Template: Is sometimes used to describe a parent role or if derived functionality is not used, the transactional template for variants to be created that have different org level and / or field level restrictions. It is also used for composite roles where you have the "shape" of the composite role defined with dummy roles and these are replaced with equivalents that represent the access required for the relevant org levels. There are probably a few other uses for the term template - like task and value, it is not a standardised term.

Value: There is a design concept that has transactional content in one role and org level content in another role. The org level/key restriction part is designed to reduce the number of variants created but this introduces complexity in other areas, e.g. it breaks SU24.

It also describes a concept where you have small pieces of authorisation (e.g. cost centre, access to posting periods) where you can supplement the role build with discrete authorisations.

Different transaction in a derived role: As Soumya said, this is not recommended. You could do it by manually adding an instance of S_TCODE and adding the transaction in there however it breaks the derived role concept and as soon as you push changes down from the parent, the change will be overwritten.

[Former Member]

Hello Alex,

thanks very much for your response.

is there any documentation available which could elaborate more about the value & task role concepts? can you please share some if you have it?

Regards, Ben

[Former Member]

Hi Ben,

There are quite a few posts on here which cover them (for value roles also search on term "enabler"). Personally I think they (both tasks and value roles) are (generally but not always) bad methods of role design that look good on paper but leave clients in a mess when the originators of the design depart.

The docs I have are related to client implementations that I have worked on so as you will appreciate, I am not in a position to divulge them.

A few of the concepts are (vigorously) debated here:

If you have any specific questions feel free to ask!

[Former Member]

If you avoid "value roles" at almost all costs you will only have the other smaller problems to deal with (eg. when you upgrade the roles).

For cost centers they are imaginable for example, but you should only do this when you have fealt the pain of maintaining them and experience with how to avoid the value role getting too large.

Please describe why you are asking this question and the objects which are problematic to fit into your current design.

Cheers,

Julius

[Former Member]

Hello Alex,

I understand your concern. Very much appreciated your responses here. Thanks!!

I was trying to understand these concepts so was looking for some guidance from someone who has had experience with them. Nothing specific i have right now.

kind regards, Ben

[Former Member]

Hi Julius,

thanks for your response. I was just trying to understand these concepts and have nothing specific at the moment.

Kind Regards, Ben

[Former Member]

I hope that you read the thread Alex linked to carefully and stick around for long enough to upgrade the roles - that way you can gain some very valuable experience.

If roles are well designed and built, then you do your customer a good favour.

If your goal is just to make it work, then you might as well copy the SAP standard roles for the "activity groups" because chances are good that you will end up with worse than that in the end if you build them manually as authorizations and bolt them together as little "task" roles in a myriad of composite combinations.

Try it for yourself and please keep us posted...

Cheers,

Julius