Expand +



Sven Ringling on customizing SAP ERP HCM authorizations: Q&A transcript

by Amy Thistle

May 24, 2013

Amy Thistle, conference producer | HR 2013 |

When standard SAP ERP HCM authorizations don't meet your business requirements, how can you minimize customization and still ensure the right level of access to your HR systems? 

Consultant, author, and HR 2013 speaker Sven Ringling of iProCon took questions recently from our audience on this topic -- enhancing & customizing HCM authorizations – also the topic of one of his sessions for SAPinsider's upcoming Amsterdam conference.

Topics Sven covered in this Q&A include reducing overhead in managing authorizations, excluding cost centers in authorizations, setting up read-only rights for sensitive information,  custom relationships in OM, how P_ABAP authorizations objects can help performance, and other topics.

You can read the entire thread in our Q&A archives, or our edited transcript here:

Amy Thistle, Moderater: Welcome to today’s Forum!

Today’s forum with SAP HCM expert Sven Ringling of iProCon.

Sven is an SAPexpert author and featured HR 2013 speaker, and he’ll be presenting a session on this topic at HR 2013 Amsterdam in just a few weeks. 

Today, Sven will take questions on HR authorizations – something that we know is an issue every SAP ERP HCM system deals with – and a big issue for anyone concerned about the compliance of the HR system.

Sven, welcome, and thank you for joining us today!

Sven Ringling: Hi Amy! Welcome to all users of the Insider Learning Network!

Thanks a lot for the introduction and for the opportunity to interact with SAP HCM users from all over the world :-)

Starting with the questions already posted, I'll do my very best to answer as comprehensively as possible and as succinctly as necessary given the format. I'm sure there will be points I can't answer in all detail from the top of my head, but I hope I will at least be able to point you into the right direction.

So, let the questions roll in...

kenrodych: We are on ECC 6 with Portal v7.3, using WDA. We use the Chiefs (Red Hat) in our OM. We will be implementing the full ECM and want to use the Chiefs for access to compensation management. However, we have some 'Team Leads' who are currently set up as Chiefs but will not have access to ECM.

Can we use a custom authorization to allow these Team Leads to continue to do Time Approval in the same manner as they currently do with their Chief role in MSS but do not provide them with access to ECM?  Or is there a way to remove their 'Red Hat' but continue to allow them to do Time Approval for the same org unit that they currently do? 

Thank you.

Sven Ringling: Dear Kenrodych,

This is a common type of problem occurring, when organisations use SAP HCM to cover ever more processes. The "Chief" relationship (represented by the red hat) is not enough to differentiate between the various roles line managers / supervisors or decentralised admin staff can take. The short answer: yes, there's always a way to deal with this kind of situations and it usually starts with context sensitive structural authorizations.

For the long answer, you have to distinguish between two aspects: a) the pure authorization aspect: this is about which data a user is allowed see and change for a certain group of people. If a user doesn't have the rights to see, say, planned compensation for a certain employee, then this information will be hidden, even if the configuration in MSS and ECM tries to show it. b) the configuration of the application, which is responsible for, e.g., which employees are listed on a screen in MSS.

Even if a user has the rights to see a particular employee, this doesn't help, if the evaluation path used in configuration doesn't put this employee on the list.

Many organisations leave authorizations quite open and rely solely on configuration to make sure the right people come up in MSS. Whether this could be done in ECM customization in your context, I don't know. However, I consider this worst practice anyway: even if this works for the majority of users, there will always be some who will have access to other transaction via other roles they have.

So, which tools would you need to use to make this work? If some supervisors should have access to time data, but not to ECM data, you need to be able to identify them in your structure. The standard way to do this is by using a different (probably custom) relationship type to indicate ECM responsibility (or use standard for this and a custom one for time responsibilities which would be the "removal of their red hat whilst continuing to allow them to do time approval" you are referring to above).

This can be built into an evaluation path used in structural authorization. However, pure structural authorization can't differentiate between different sets of employee data to be accessible, so you would need to implement context sensitive authorizations.

Not knowing your context in all detail, you may also have to consider some custom coding in the BAdIs of HR authorizations, to amend or replace standard context sensitive authorizations. In any case, you'll need to use this different relationships type to indicate in which role a user is 'superior' of an employee.

Kir Chern: Hello Sven,

My questions:

1. With EHP5 and beyond, can you explain how pfcg roles can be "fitted" to be used with NWBC and Portal (there's capability to upload backend roles to SAP NW Portal), any pre-requisite settings and how these are managed or keep in sync. between the back-end role and front-end being NWBC/SAP Portal (eg. delta changes in the pfcg roles etc) ?

2. Can you share how one can possibly tune the performance and overhead in dealing with authorization? (any avenue to tune and look out for performance related issues)

Thank you and regards,

Kir Chern, Loh

Sven Ringling: Hi, nice to meet you on the Q&A again :-)

To your first question:
I haven't used this feature yet in portal, but I'm not too excited about it - those I asked about it all said, they couldn't see how it would be useful in a real workd scenario. It is not a mere upload, but conversion and I don't think there's a synchronisation process in place. So, changes in PFCG would have to be followed up manually.

The technical context is described here: and here:

To your second question - this is a big one

The easy answer is: keep it simple. I know, it sounds like a smartass answer, but I cannot emphasize it enough that authorization concepts are prone to reach a complexity overkill making us consultants rich with redesign project.

Some points to reduce overhead:

- Use custom organizational levels and derived roles, so you only need to change master roles, if, say, you have the same role for several personnel areas - make good use of composite roles

- Don't go too narrow in roles scope - leaving some overlap will reduce number of roles and spares you re-assignments for roles of absence cover

- Make structural profiles dynamic using the function modules in T77PR

- Exploit opportunities to make "normal" profiles dynamic with custom coding in the P_NNNNN object or the BAdIs (e.g. rather than have same role for each cost centre, use one role automatically using the user's own const centre - Use good naming conventions and descriptions for roles

- Using dynamic assignment of roles through orgmanagement reduces admin effort, but it may not match your process requirements

To your second question: some points on performance:

- Badly programmed BAdI coding can kill performance

- Use P_ABAP authorizations object whenever possible to make the system use the simplified checks. (But read the documentation twice. It can be confusing)

- Use the buffer table for structural authorizations

Dave Hannon: Sven,

Thanks for taking our questions.

I'm sure you'll cover a lot of the technical options for customizing authorizations but I'm wondering if you have any organizational suggestions to help limit or even avoid some of the customizations required? 



Sven Ringling: A good question, Dave.

Typically making for a fun one day workshop :-) I touched the aspect slightly already in my answer to Kir's second question.

My most generic advice: don't give up to easily, if the business asks for very bespoke authorizations.

I'd always challenge the practicality of it. Asking, "What happens, if this person is off sick?" often makes them think about setting up more open roles. Some requirements are as they are only because this was what the old system had done, and some requirements come from auditors, who don't understand the system beyond what they read in an outdated textbook. Auditors can be challenged, too.

When holding sessions on this topic as in Amsterdam, I always feel a bit bad, because I know it might inspire some users to make things more complicated than they need to be. But then, many of these requirements are real and can't be discussed away, so I think, the better people are informed about options, the better the outcome. Also, some of the options involving custom coding can actually make admin processes easier.

There's also an option to replace hard access checks by monitoring.

I've actually seen this working even in a key union negotiation for a SAP HR implementation: the Union originally wanted the system to rule out scores of reporting options in a very complex way, because they assumed HR and line managers would abuse the tools they have (most notably SAP Query) to play Big Brother. Eventually they agreed to leave Query reporting quite open, as long as the union rep could report on what's been reported on and ask questions, if she felt there were dubious reports going on.

So: if a certain action is not going to break the bank, monitoring it after the event may be a better option. This is particularly true for approval processes: Rather than setting up annoying workflows with complex authorization rules and delegation rules behind them, just assume that employees won't, e.g., book trainings without discussing it with their boss or project manager - and then give managers the option to analyse what trainings their team booked and respond to any funny things going on.

S R: Hi Sven,

My question is with regards to authorization object P_ORGIN.

We are trying to create a role for our team by excluding employee sitting in various cost centers.

P_ORGIN has the following sub objects:

Authorization leave
Personnel Area
Employee Group
Employee Subgroup
Organizational Key

Is it possible to explicitly exclude cost centres with this object?

Currently we use Organizational Key object associated with the employees sitting in specific cost centres and exclude these specific organizational key values. However, there are several ranges we have to exclude so this is a very tedious task.

Is there a better way to approach this task of excluding certain cost centres with the P_Orgin object?


Sven Ringling: Hi S R (nice - you have my initials :-)  ) 

As a rule, you can't exclude in the HR Authorization objects with exception of P_PERNR, which is special (you can, to some extent) in structural.

So, the way you are doing it is the standard way, although cumbersome and high maintenance, if new cost centres are added.

So, here is where custom enhancements com in as an option, which might make your admin effort easier and roles less error prone:
You could use the so-called P_NNNNN object and add custom code after the generation. This custom code would need to do the cost centre checking - and you wouldn't even have to use VDSK1 (Org key), because you can include the cost centre in P_NNNNN:
Two options: your custom code interprets all cost centres entered as excluded or you'll have the excluded ones in a custom table.

Well, it's an approach - detailed design would still need to be done looking at the requirements very closely.

Ken Murphy: Hi Sven, with all the issues around HR security, there are scenarios where users can change their own address, bank details and dependent data, but only view (not change) other infotypes.

Can this be done using standard authorizations, or does it require enhancements?


Sven Ringling: Hi Ken,

From an authorizations perspective, this is no problem. It's standard use of authorization object P_PERNR or P_PERCON without enhancements.

Depending on which web dynpro etc are used in the Portal / NWBC and for which infotypes, they might need to be amended.

One comment: Watch out for fields you may not want to be changed by employees. E.g.: some employers are happy for employees to change their address, but not the field "distance from workplace," as it is used to calculate tax on company cars in a few countries like Germany. Authorizations in standard never go to field level. This would need to be dealt with in the user interface.

 _andy_: Hi Sven,

If it is practically mandatory to use a standard infotype that contains a field that is deemed sensitive, what is the best way to create authorizations that affect only one field within an infotype?

- Andy

Sven Ringling: Hi Andy,

This is a very common problem. Most notably in infotype 0002, where Social Security number and sometimes other fields like DoB or religious affiliation are a problem.

Unfortunately SAP HR standard authorizations are not set up at all do deal with this issue - not even if you use BAdIs etc.

The only case where you could deal with it in authorizations is, if you have a report or any other transaction, where the relevant, but not the critical, fields of the respective infotypes are shown. Then you could use the authorization object P_ABAP to make sure this report can be viewed, even though the user doesn't have access rights for the infotype and therefore cannot access it in transaction PA20 or so.

All other options (some also requiring P_ABAP) involve more or less custom programming -- e.g. a custom transaction or WebDynpro to show the required data save the critical fields. These transactions could ignore standard authorizations completely, if required, and your developer can implement whatever checks you want them to.

A trick used sometimes in this case, particularly if it is about reading rights only.

Create a new subtype for this infotype. Transfer the content of the original subtype into this one (e.g. in a batch job every night), but do not transfer the critical fields. Then give those users rights for this new subtype, but not for the original one.

Not very elegant as double data keeping, but it works in PA20, XSS and reports, as the subtype field is a standard authorization-check field

Amy Thistle: Sven, I know you’ll be covering authorizations in much more detail in your Amsterdam session. But can you just give a quick overview of the value of using context-sensitive authorizations vs. typical structural authorizations? 

Sven Ringling: Hi Amy,

At this point I usually ask for a piece flipchart paper and pens in 3 colours - but let's try..

Context sensitive auth is basically the old structural authorization developed further in how it works for PA-Data (employee master data).

The structural authorization can decide, which employees a user can see, but not which data in particular. This has to be dealt with with the "normal" authorization objects (P_ORGIN etc).

So, this doesn't allow for a scenario, where a user is allowed to see, say, infotypes 2000-2012 for one set of people and infotypes 0000-0016+0019 for another set of people. Even with two different structural profiles there is no connection between them and the infotype rights, so you end up with this user seeing all those infotypes for both sets of people.

Context authorization does solve this problem: a new field in the "normal" authorization object (e.g. nos P_ORGINCON rather than P_ORGIN) connects the structural profile with the infotype related object.

Jeremy Masters: Hi Sven, 

Could you share some common misconceptions and/or misunderstandings that customers have with standard and structural authorizations? (I am sure there are a few for the latter )

Looking forward to see you in Amsterdam next month.  I will be checking out your sessions

See you soon!

Jeremy @jeremymasters

Sven Ringling: Hi Jeremy,

Well, there are certainly enough misconceptions to fill a few pages (noooo - this doesn't mean authorizations are complicated  )

Here are just some of them:
- If you don't have access to an employee according to your structural authorization, "standard" authorization can't change this and If you don't have access to an employee according to your "standard" authorization, structural can't change it either. Users often assume that structural and standard authorization checks are connected with each others a logical "OR", when they would find it convenient to be that way, but it's always an "AND". It's like two consecutive doors and you need a key to both of them.

- There is no context authorization for objects or "PD" (e.g. Orgmanagement). teh object PLOG_CON exists, but it doesn't do anything. It's an empty shell and nobode knows whether SAP will ever do anything with it. So far, they only added a documentation, which says "this doesn't do anything". Unfortunately, I've seen clients designing a concept on the assumption that it does work...

- Structural authorization doesn't work for employees not integrated into OM according to feature PLOG

- The authorization object P_ABAP is NOT required for a user to run a certain ABAP program. If authorization check in transaction SU53 asks you to add P_ABAP, always be careful. In most cases, the problem will go away, but you may have opened up more employee data than you intended to. P_ABAP basically can simplify or completely switch of checks for HR master data for particular reports. This can help with reporting performance amongst other things

Some more misconceptions:

- You can switch structural authorizations on and off for PA data only. For PD data (orgmanagement etc.), it's always switched on.

- If a user doesn't have an entry in T77UA, this does NOT mean he doesn't have any access. He's got the access given to user SAP* and this is often ALL. So, forgetting to add a user in structural authorization can have the opposite effect of forgetting to add him on the normal role. That's why many change the T77UA entry for SAP*.

- Possibly the most fundamental one:
It is often assumed that in order to perform a certain action, a user needs all rights required for this in one role. However, it doesn't matter which roles the rights are in. All the rights from all roles a user is assigned to at the given point in time are added up to decide, whether the user has access or not.

For example, if a user has access to infotype 0002, but in that particular role doesn't have transaction PA20, he can still access infotype 0002 through transaction PA20, if PA20 is assigned in object S_TCODE through a different role. This makes role testing so difficult: they may do what they are supposed to individually, but unexpected combination of roles may open up more actions than you expect

Amy Thistle: While we are wrapping up our forum today I'd like to thank you all for joining us and thank you again to Sven Ringling of  iProCon for answering these questions today!

Sven will also be presenting a few sessions at HR 2013. In addition to a detailed session on today’s topic, HR authorizations, Sven will also presenting sessions on global HR implementations, HR project implementation, and HR cost forecasting. 

If you are joining us in Amsterdam, be sure to introduce yourself to Sven and his colleagues and peers from SAP, SuccessFactors and organizations across Europe.

sheaMatt: Hi Sven,

Let's say an organization uses structural authorizations for line managers' access. Now they want to add PAs and time administrators, who require similar -- but not the same- access to different groups of people. Does this require programming and/or structural authorizations?  


Sven Ringling: Hi Matt,

In most cases this would require structural authorizations (you could possibly use fields from infotype 0001 to decide wh has access to which employees, but this would require a huge number or roles, while structural authorization could be dynamic in deciding the sets on employees accessed).

If the decision "whom can I access" can be made based on the line manager relationship or which orgunit a user sits in, no custom coding is required.

However, you often would have to work with a custom relationship type in OM and a custom evaluation path to assign, say, time admins to the right orgunits. In this case a wee bit of programming would be required, as you would need to copy the standard function modules to be captured in T77PR and replace the SAP evaluation paths by your own. You wouldn't even need real ABAP skills for this.

Otherwise: it's easy as long as the 3 groups of people are mutually exclusive.

If not (e.g. one user performs line manager duties for one group of people, but time admin duties with different access rights for another group of people), then you would look at context sensitive authorizations. Becaus ethey make everything a level more complex, I'd try to work around this, if it just affects a few individuals (e.g. just the supervisor of the time admin team, who is their line manager and also works as a time admin for a different group).

In any way: apart from the tiny bit, no programming would be required fron what I know about your requirements (adding this deliberately, as this often changes, when the special cases and exceptions come up  )

Kevin A. Clarke: Hi, Sven.

Is there any methodology (e.g. Tasks) to mitigate the proliferation of multiple roles in order to facilitate specially empowered employees? This would be employees who are assigned special functions along with the ordinary duties that they share with their peers.

This becomes especially important when one of these special employees goes on leave, since we don't want to be dependent on people's memories to tell us to manually assign the requisite role for the employee's replacement. It's always best to have things handled automatically from the org structure.

We are currently on R/3 Enterprise 4.7, upgrading to ECC 6 in Dec/Jan.


Sven Ringling: Hi Kevin,

I hope I understand your issue correctly: It seems to me that you currently assign roles through jobs in OM, but for some individuals you assign it manually to users and you want to avoid this.
The easiest way to do this, would be to assign the special roles to the positions those special roles are performed on.

However, if the special duties are not necessarily to be assigned to the next person holding this position, then this would not work. of course, you could use tasks, but either those would need to be assigned to the position (same problem), or you would have to remember assigning the task - same problem as directly assigning the role to the user.

So, unless using the position works for your process, I don't see an easy answer to this.

As a rule, I found that using OM to assign roles always requires some manual adjustments, because the real world is less well structured than OM.

E.g., someone might not yet be assigned to the new position, but already perform some of the tasks, because the old holder has gone already or it's part of the handover process, etc.

Sven Ringling: Thanks a lot everybody for your participation and sorry for the types - and thanks to Amy and Kristin from SAP Insider for organising this. I enjoyed this and hope it wasn't the last time.
I can be contacted via email: or Twitter @svenringling
Or even better: meet me at HR2013 in Amsterdam

Amy Thistle: Thanks to all who posted questions and followed the discussion!

A full summary of all the questions will be available here in the HR Forum. I encourage you to review our Forum posts and join the HR Group for ongoing information and additional resources.

I also invite you to join Sven in person, June 11-13 in Amsterdam for this year’s HR 2013 Europe conference.

And again, Sven, thank you for joining us and I’m looking forward to your sessions in Amsterdam!

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!