This article outlines the process which needs to be followed when managing a request for transaction access, missing access and additional access (eg. Plant, Sales Org, etc.) in the PI1 and SI1 system.
Information
PI1 is the Production Environment and the SI1 is the Pre Production Environment.
Identifying the Tickets :
When the users mentions that he / she needs access to a Transaction, Plant, Sales org, etc. or if the user has added a screenshot of an error or the SU53, then it can be identified as a Missing Access. If the user needs access to a Transaction, then it can be identified as ticket for Transaction Access. The users generally exist in the system. These tickets may have the accompanying information like the Name of the User / ID, Reference User Name / ID, Systems, etc. Below is an example of how the ticket may look like.
Approvals :
Before proceeding with these kind of tickets, we need to always check the approvals. The approvals for the PI1 and SI1 system are managed by the L0 Teams depending on the region. If there are approvals are missing in the ticket then the ticket has to be transferred to the respective L0 Team (Bangkok, Lisbon or Curitiba) asking them to get the approvals. Also, we need to ask for a Reference User ID if there is a confusion in obtaining the accurate role.
The request is approved if an agent from the L0 Team mentions that the it is approved or if the one requesting the access is the User's Manager. An example can be seen below :
Providing the Access :
Important
It is very important to understand that we need to start the SU53 analysis or the transaction access analysis directly in the child system PI1 and SI1 rather than the PQ1_001 CUA system. This is because the actual roles exist in the child systems and not in the Central system. PQ1_001 system is only used to assign the role after analysis.
- When we receive a Missing Access request, after we check the approvals, we always need the SU53 screenshot or text file in order to obtain the Object and the Object Values. In the case of a transaction access, the object for the transaction code is generally s_tcode and the object value is the transaction code itself. The SU53 file looks like the below. (Please note... The analysis is to be done in the same way as the PF1 system and hence, the below example is of the PF1 system. There is no change in the analysis and only change in the assignment.)
- In the above screenshot, V_LIKP_VST is the Object and the Object Values are ACTVT - 02 and VSTEL - 1031.
- The corresponding role for the transaction or the missing access has to be found out through the transaction SUIM (User Information System → Roles → Roles by Complex Selection Criteria) based on the users Existing roles, Country, GBU, Function, etc.
- Once the role is found out, the same is assigned to the user in the IDM and ticket is Resolved.
Important
If a user asks to add the role (or in case of a User Creation) in the PI1 system then the same roles has to added in the SI1 system too. But the vice-versa should not be done, i.e. if the user needs access in the SI1 system then the same has to provided only in the SI1 system. Also, if required, we can ask for the Reference User too.
We have now finished the request for the Missing Access for the user in the PI1 and SI1 system.