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: 

HR security among HR team members

manish_mohan3
Participant
0 Kudos

Dear friends,

I am re-submitting this post as it was cancelled by moderators stating this was a fundamental question.

My apologies to include that I had done the research prior to posting this message.

I understand this would be a combination of structural authorizations and role authorization but I am not sure how this would work for my requirement. I also looked at BAdi HRPAD00AUTH_CHECK but this does not work with standard reports and SQ01.

Kindly request to review and provide suggestions.

The requirement is that a group of HR team members from the larger HR team should be able to access information of all employees in the company. But other HR team members that are not part of the above list should have access to company wide information but not of the special HR team members.

Also this authorization should work with standard HR reports, PAAH, SQ01 queries.

Any guidance in this matter would be really helpful.

Thank you.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hello,

A few possible solutions that come to mind, in order of suggested approach:

  • Any standard Personnel Structure (PERSA/G/K) attribute that can be used to separate this special group
  • VDSK1 (so you can stay with P_ORGIN if you're not already using P_ORGXX)
  • P_ORGXX (In case you're already using VDSK1)
  • Structural authorizations (exclusion profile with a function module pointing to a z-table or with any other lookup mechanism to retrieve that group)
  • ...

Plenty of options...

Brent

7 REPLIES 7

Former Member
0 Kudos

Hello,

A few possible solutions that come to mind, in order of suggested approach:

  • Any standard Personnel Structure (PERSA/G/K) attribute that can be used to separate this special group
  • VDSK1 (so you can stay with P_ORGIN if you're not already using P_ORGXX)
  • P_ORGXX (In case you're already using VDSK1)
  • Structural authorizations (exclusion profile with a function module pointing to a z-table or with any other lookup mechanism to retrieve that group)
  • ...

Plenty of options...

Brent

0 Kudos

Thank you Brent for responding. Actually I did go through these options. I am new to this area and the knowledge I have so far is by reading blogs and posts from other experts. So kindly pardon my ignorance is this is simple.

The challenge I am facing is not with the special group. The issue is with other users that are part of HR team. They should be able to access information of everyone in the company ( Executives, Accounting, Sales, IT etc.. ) but should follow structural authorization for HR group.

I hope it is not a silly question.

Kindly advise.

Thank you,

Manish

0 Kudos

Hi Manish,

Just to make sure we're on the same page, can I summarize your requirement like this:

- Role A: Access to the entire company

- Role B: Access to the entire company except the "Special HR team"

You said you already looked into the options I mentioned in the first post. If this recap is correct, can you please specify why neither of those options can be used to solve this requirement? Is there any other requirement we're missing here?

You also specifically mention that "Role B" should follow structural authorizations for the HR group. Is there a reason why it cannot be solved with standard authorizations?

Thanks for clarifying,

Brent

manish_mohan3
Participant
0 Kudos

Yes Brent.

Role A - The special HR team members who would have access to entire company.

Role B - HR team members with access to entire company except "Special HR Team". Also these members should follow HR heirarchy while accessing data. That is, if this non-special member is a manager, he should be able to access his employees data even if the employee is a special member.

I was looking at the function module option but not sure if that would be efficient as I would need to scan through all positions and exclude the positions for special members. Also all other positions in the company need to be passed out of the function module.

Kindly advise if this approach is correct or if there is an alternat option.

Thank you.

0 Kudos

Hi Manish,

In that case I wouldn't recommend using structural authorizations to solve this requirement. You're probably better off using the organizational key if it's not already in use.

Populate VDSK1 for the special group with a value (eg: "SPECIAL") then set up the roles as such:

Role A should have full authorization for P_ORGIN(CON).VDSK1

Role B should have authorization to all values except "SPECIAL" for P_ORGIN(CON).VDSK1 (use a range to exclude it)

Your Manager role should also have full authorization for VDSK1 to make sure they can access people in that group.

If the org key is already in use, use P_ORGXX(CON) instead.

Kind regards,

Brent

0 Kudos

Hi Brent,

If we do it this way, wouldn't it allow non-special teambers under different managers in HR to access each others data.

To summarize my requirement again, please find an example below:

In the above picture, let's assume Comp manager and HR Emp 1 are special HR team members:

So they would have access to the data of everyone in the company including each others.

HR Emp4 would have access to the data of everyone except employees/managers under HR org unit.

HR Emp3 would have access to the data of everyone except employees/managers under HR org unit.

Benefits Mgr would have acess to the data of HR Emp4, CEO and employees/mgrs under IT and Accounting but not the ones in HR Org Unit ( except of HR Emp4 as he is under him ).

Same with Recruitment Mgr, he would have access to HR Emp3, CEO and employees/mgrs under IT and Accounting but not the ones in the HR Org Unit ( except of HR Emp4 as he is under him ).

Thank you again for providing guidance in this matter.

Thank you.

0 Kudos

Hi Manish,

In previous posts the requirement was to avoid "non-special" employees to access "special" employees. With your latest post this has been extended to "non-special" employees shouldn't access employees within a certain department.

I'm afraid this doesn't change anything with regards to the solution. I would still propose to solve this with either VDSK1 or P_ORGXX (now for the entire department rather than only the "special" employees). Solving this with structural authorizations would just put unnecessary strain on your system performance-wise.

Can you please explain why you thing this solution would cause "non-special" employees to be able to access "special employees" data?

Thanks & kind regards,

Brent