Learn how to implement structural authorizations for Nakisa. Understand the concepts and activities required to make structural authorizations work with Nakisa components.
Key Concept
The concept of structural authorization helps SAP ERP HCM users to define the population of the organizational structure that they can access. These kinds of authorizations use evaluation paths to determine all the objects under the root object in an organization structure. Because Nakisa components are mostly visualization tools, structural authorizations play a vital role in helping users by optimally visualizing data. Although the general concept of structural authorizations is well known by most SAP ERP HCM users, one relatively unexplored area is its use in Nakisa applications. I explain how to use SAP Talent Visualization applications by Nakisa (SAP Talent Visualization by Nakisa [STVN] and SAP Organizational Visualization by Nakisa [SOVN]) with structural authorizations.
Nakisa, one of SAP’s partnership products, is fully integrated with SAP ERP HCM back-end data. This integration ensures that all security-related (authorization) operations that are implemented on back-end data are also valid for visualization solutions in STVN and SOVN.
For some of Nakisa STVN’s components, such as succession planning, however, Nakisa uses TREX search indexes between the SAP ERP HCM data in the back end and its presentation layer. Therefore, restrictions for data searching for end users should first appear in these indexes for these components. For all other components (e.g., organizational charting and organizational modeling) structural authorizations are directly picked from the SAP ERP HCM back end.
Structural authorization plays a vital role in implementing STVN or SOVN functionality because it directly affects the possibility of displaying objects, such as organizational unit and position, to the user. In addition, the standard SAP ERP HCM system doesn’t provide STVN or SOVN functionality with specific authorization profiles in the SAP ERP HCM back end. This limitation complicates the process further because users implementing basic Nakisa functionality do not get any guidance about how to build structural authorization profiles or which objects to include.
System Prerequisites
To implement this functionality, your system must meet these basic requirements:
1. The ORGPD authorization switch in the AUTSW group of table T77S0 must have a value of between one and four. (For details on authorization switches see the article “Perform Authorizations Properly by Defining Authorization Main Switches.”)
2. Employees should have a valid user ID attachment in infotype 0105, subtype 0001 (communications).
3. An adjusted structural authorization profile, as per the business requirements, should be present in table T77PR (transaction code OOSP).
4. The user ID should be attached to the adjusted authorization profile in table T77UA (transaction code OOSB).
5. The connection string in various Nakisa components (e.g., organizational charting and succession planning) for relevant services (e.g., organizational charting, succession charting, and various listings) should not have a user ID and password (Figure 1).
Figure 1
A connection string without a user ID and password
Note
Connection strings connect STVN or SOVN’s presentation layer with SAP ERP HCM’s back end to pull the data based on the configurations available in the application layer (
Figure 2). While connecting, the presentation layer is capable of using the user ID and password from a connection string, if available (
Figure 3), or a cache of the user who is logged in.
This connection string also depends on the authentication mechanism (e.g., single sign-on [SSO] with log-on tickets) used in various components of the configuration.
The user ID and password variables are not used in a connection string to enable application of back-end authorizations (structural or general) for the user on STVN or SOVN applications.
Figure 2
Technical architecture and flow of authorization data based on a user ID
Figure 3
A full connection string with a user ID and password
6. The position of the user, whether it is the talent management specialist (TMS) or manager, should be attached to the related organization unit with relationship 741. Relationship 741 connects the position of the user with the organizational unit to show the user as the TMS of the respective organizational unit. This relationship is mandatory for STVN components such as succession planning because TREX is used for indexing, and, unfortunately TREX doesn’t recognize users who don’t have 741 relationships.
Note
In general, components such as succession planning are designed to be used by a TMS only; however, more managers are starting to use succession planning as well. For managers to execute succession planning for their area of responsibility, structural authorizations have to be in place.
The succession planning component of STVN uses indexes generated by TREX, rather than pulling authorized data directly from the SAP ERP HCM back end for the user. To generate indexes, manager positions should be attached with the organizational unit he or she manages with relationship 741.
Figure 4 shows this step in detail. Note that successors, my positions, and any other succession planning charts still pull data directly from the SAP ERP HCM back end and not from the indexes.
Figure 4
TREX usage for Nakisa components and relationship 741
7. Ensure that the TREX search connector report HRTMC_AUTHORITY_VIEW is active and working. To make it active the RPTMC_CREATE_CHANGEPOINT_AUTH and ESH_IX_PROCESS_CHANGE_POINTERS reports have to be scheduled to run at agreed timelines.
Note
The HRTMC_AUTHORITY_VIEW search connector indexes changes that are made to users’ authorizations (structural). Report ESH_IX_PROCESS_CHANGE_POINTERS helps make this indexing possible by passing delta changes to report RPTMC_CREATE_CHANGEPOINT_AUTH. Report RPTMC_CREATE_CHANGEPOINT_AUTH, in turn, generates indexes with relevant search connectors.
Adjusting the Structural Authorization Profile
It is very important that users who are implementing Nakisa STVN or SOVN functionality identify, create, or adjust structural profiles. These profiles are the key to creating structural security for users.
No standard structural profiles are available in the back end of the SAP ERP HCM system. Therefore, your best option is to copy a standard talent management structural profile into a customer space and modify it according to your requirements. Standard structural profiles, such as TMS_PROFILE, TMS_ALL, and TM_MAN_PROF (available with Talent Management enhancement package 4), can be customized to fit your requirements.
TMS Profiles
The standard talent management profile TMS_PROFILE can be easily modeled for TMS users accessing Nakisa (Figure 5).
Figure 5
Profile TMS_PROFILE
You can model the standard talent management profile TM_MAN_PROF for TMS managers accessing Nakisa (Figure 6).
Figure 6
Profile TM_MAN_PROF
Here are some of the most common scenarios to help you better understand the concept of adjusting the structural profile as it relates to Nakisa functionality.
Scenario 1
The company wants each user to see the entire organization and successor charts (organization units); however, users should be able to modify only objects (positions and employees) that fall under his or her own area of responsibility. This is true for visualizing charts as well as for searching objects. In scenario 1, the structural profile for TMS users is modified as shown in Figure 7.
Figure 7
Customize TMS users’ structural profiles
Comparing Figures 5 and 7, you see that some information has been deleted or changed. For example, in Figure 7, the record for number 90, object CP is deleted; in the record for number 80, the object S is replaced with the object QK; in the record for number 310, the field under the OT column has been added with the object VJ; and in the record for number 00 the all object identifier (*) has been replaced with O.
I made these changes because in Figure 5 line number 00 had an all objects identifier (*) which is valid for all plan versions (**). Also, I changed the object to O (for organizational unit) with a starting object ID number (12345678, in my example), and the evaluation path to ORGEH. Making this change in the EvalPath column in the profile ensures that it gives access to all the subordinate organizational units only, starting with the ID of the organizational unit mentioned.
Tip!
Always maintain the root organizational unit ID here (in the ObjectID column for record 00 shown in Figure 7). This ID should be similar to the root ID maintained in the Nakisa components (e.g., organizational charting and succession planning), configured through the administration console (Figure 8). If a profile has an entry that is different from the root organization unit ID stored in the administration console of the respective Nakisa component, it can lead to errors when visualizing. For example, Org. O1, O2, and O3 represent three organizational units. Organizational unit O3 reports to O2, and O2 reports to O1. If organizational unit O1 is included in the profile and organizational unit O2 is listed in the organizational chart configuration, the user is able to see the organization chart starting from organization unit O2. However, if organizational unit O2 is included in the profile and organizational unit O1 is listed in the organizational chart configuration, the result is an error message for the user. This tip is valid for managers as well.
Figure 8
The administration console to set the root organizational unit for Nakisa components
Nakisa components require the OrgChart Root ID to visualize the organizational chart starting from it. Only in cases where the dynamic OrgChart Root ID is used is this field left blank.
Line numbers 80 and 90 in Figure 5 provide display access to all positions (S) and employees (CP). These line numbers were removed from the adjusted profile in Figure 7, to restrict the TMS user from viewing the position and the employees outside of his or her area of responsibility.
Line number 310 provides access to maintain object VJ (organizational goals), as TMS users own this task (Figure 7). Line number 10 in Figure 7 gives change access to all the objects (e.g., O, S, and CP) under the TMS user’s area of responsibility.
Tip!
When SAP Talent Management and Nakisa functionality exist together, in addition to working on STVN and SOVN components, TMS users are responsible for many other tasks (e.g., talent review meetings, talent assessments, and creating organizational goals). In cases in which these functionalities exist together, TMS users sometimes are not part of the organizational unit for which they are responsible. For instance, Figure 9 illustrates a TMS user (position S5) who doesn’t fall under his or her own area of responsibility. In other words, position S5 is attached to organizational unit O2 through relationship 741, although it is attached to organizational unit O4 through relationship 003.
Figure 9
Position doesn’t fall under its own area of responsibility
In this case, the TMS user faces authorization-related problems when doing routine activities, as his or her own position does not fall the under an authorized hierarchy. For example, TMS users are unable to see their own responsible organizational units while attaching recipients during the creation of Talent Review Meetings (TRM).
This issue can be solved by modifying the newly added structural profile (line number 410 in Figure 10) shown in Figure 7 as line number 310.
Figure 10
Profile to include the user’s position outside of the area of responsibility
Figure 11
The evaluation path to include the user’s own position within the area of responsibility
In scenario 1, the structural profile for managers can be adjusted as shown in Figure 12.
Figure 12
Adjusted structural profile for managers
There are many modifications made to the screen in Figure 6, resulting in the screen displayed in Figure 12. These changes are done to accommodate the other routine activities of SAP ERP HCM managers (as related to SAP Enterprise Compensation Management [SAP ECM], manager self-services, and Performance Management and Talent Management modules).
For example, in Figure 12, line number 00 provides display access to all organization units of an organizational structure starting from the root ID (12345678). Line number 10 provides maintenance access to objects under the manager’s area of responsibility that were determined by evaluation path O_O_S_SU, starting from the organizational unit that he or she (the manager) manages.
Scenario 2
In the second scenario, the company wants users to be able to view charts starting from their own responsible organizational unit only. In other words, users should be able to view and modify objects (e.g., positions and employees) falling only in their own areas of responsibility. This restriction is true for visualizing charts as well as for searching objects. (Note that TMS users are attached to the responsible organizational unit with relationship 741, and managers are attached to the responsible organizational unit with relationship 012.)
In scenario 2, structural profiles for TMS users and managers can be modified in a variety of ways. This process involves two steps for implementation:
- Remove line number 00 from the profiles shown in Figures 7 and 12. This action ensures that users have the authority to be restricted for objects under their areas of responsibility only. This restricted set of data is used for visualizing charts and searching objects in various STVN and SOVN components.
- Under General Settings, keep the OrgChart Root field blank for each of the STVN and SOVN components showing charts. Enter User in the Default OrgChart Root field (Figure 13). This step is required for visualizing charts in various STVN and SOVN components.
Figure 13
The administration console (in which the organizational chart or position hierarchy starts from the user’s position or organizational unit)
Tip!
A dynamic root can be set only for the organizational structure or the position hierarchy organizational charts; both organizational charts (i.e., organizational structure and position hierarchy) cannot have a dynamic root. Also, in this case, the users (the TMS or manager) should be part of their own areas of responsibility, unlike the example in Figure 9. Dynamic organizational charting requires core XML file changes for each component (SP1). Refer to the Administrator’s Guide for more information.
Scenario 3
In the third scenario, the company does not want users to be able view the entire organizational chart — only the chart that falls in the same line of hierarchy as the responsible organizational unit (Figure 14). Users can modify only objects (e.g., positions and employees) falling under their own areas of responsibility. This restriction is true for visualizing charts as well as for searching objects.
Figure 14
An organizational chart that falls in the same line of hierarchy as the responsible organizational unit for the user
Note
Although the user (either the TMS or manager) is responsible for organizational unit O5, he or she is able to see organizational units O2 and O1 as well because the organizational chart always starts with the root organizational unit (O1 as shown in Figure 8). When dynamic organizational charting is not used and, therefore, you want to restrict the user’s view to organizational units O3 and O4, provide the user with minimum access to organizational units O2 and O1 to complete the relationship path. This step is just a workaround and can be used with other variants depending on the requirements.
In scenario 3, the structural profile for TMS users can be modified as shown in Figure 15, and the structural profile for managers can be modified as shown in Figure 16.
Figure 15
The structural profile for a TMS user when access is restricted to objects falling in the line of hierarchy starting from a responsible organizational unit
Figure 16
The structural profile for a manager when access is restricted to objects falling in the line of hierarchy starting from a responsible organizational unit
Evaluation path ZORGEH (Figure 17) starts from the responsible organizational unit for users and then moves upward in the line of hierarchy; therefore, the authorizations do not include other organizational units in their authority. Note that function modules RH_GET_MANAGER_ASSIGNMENT and HRTMC_GET_ALL_RESP_ORGUNITS find the responsible organizational unit for managers and TMS users, respectively.
Figure 17
The evaluation path to find the line of hierarchy (bottom to top)
Note
These profiles help the system to determine the users’ authority only in terms of objects included. Authorized objects then are consumed by charts or searches (listing).
System Tips
Here are four more tips to help you when implementing structural authorizations with Nakisa:
- Regularly schedule reports RHBAUS00 and RHBAUS02 to increase the performance of the system when structural authorizations are used.
- Carefully draft structural profiles. Follow this draft with thorough testing not only for Nakisa but also for Talent Management, Performance Management, SAP ECM, and manager self-service (MSS). This step is recommended because Nakisa users often are also TMS users and managers of talent management, performance, SAP ECM, and MSS.
- To troubleshoot, always check for included objects in user authority by using the Display Objects link icon (Figure 18) in table T77UA (transaction code OOSB).
- Finally, note that context-sensitive authorizations also work with Nakisa STVN and SOVN functionality.
Figure 18
Table T77UA
Prashant Rastogi
Prashant Rastogi works at Accenture as an SAP HCM associate manager. He has been working in SAP ERP HCM for the past seven years in various assignments. Prashant has experience in implementing ESS, MSS, SAP ECM, Performance Management, Succession Planning, Talent Management, OM, PA, and Nakisa. Prashant has an MBA (HR) along with a master’s in law and labor welfare. He is also an engineer in IT.
You may contact the author at prashant.rastogi@accenture.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
Premium
