Received a ticket to solve the missing authorization. I tried with SU53 to solve that and I got 20 similar roles regarding the missing authorization when I check with SUIM.
My question is which role I want to assign the end user from those 20 roles. FYI all 20 roles have that missing authorization identity.
Answer:
Your best bet is to understand what is the functionality of that missing authorization and what role would probably correspond to that functionality. something like looking at the roles of other user from the same department who has the same functionality as this user might help in further downsizing your list.
Bottom-line understand the roles that have been created, understand the transaction that is causing the error and understand the missing authorization object or values and then make a wise decision.
Even when looking at the other users of the same department
having same functionality, you might downsize the list further by checking
if some of the roles are used at all or not. Some might be obsolete roles
which are no longer assigned to users. But for final decision you can always
refer to the role owner.
Finding An Authorisation Failure
Running an SU53, finding an authorisation failure and then hunting for an additional role to assign isn't the answer really (well - there are no perfect answers - just different ways of doing things).
Say the user is running ME22N everyday and, when trying to change one particular purchase order one day they get a 'you are not authorised' message. They complain bitterly to their work colleagues who say 'well I can do it'. Then to their manager who looks at the screen, tuts, and tells the user to fire off an email or log a call with the help desk right away as it's stopping them doing their job.
That user may have been working perfectly well for many years, doing the same task until today, their colleagues (who can run the transaction) have joined recently, having moved positions in the business and can access the purchase order no problem.
The thing is - should they really be able to change this one purchase order or not? They've managed fine, processing perfectly as expected with no complaints from any other person in the procurement chain.
Having an authorisation failure and getting it fixed isn't always the thing to do, the user may actually have the correct access and all the other people may have too much access. In this example the user may have failed on doc type UB when all they should be accessing is doc type NB, the more recent joiners have access because of badly controlled access requests or legacy access..
You need to use logic (and hopefully some competent role owners) to make sure you aren't assigning any old role just to clear a logged ticket.
