A growing tendency of HR departments around the world has been to decentralize the maintenance of HR data. So instead of one major services department handling the data for the entire organisation, we are moving towards a situation where each department has its own HR representative who owns the data for the department’s employees. Even for organisations using a shared services model for HR, the trend is to simplify data entry procedures so that even HR analysts with limited exposure to SAP transactions can get their jobs done efficiently. It was from this need to simplify the user interface for users that SAP came up with the concept of HR processes and forms. The technology is based on Adobe forms and as such more intuitive for a beginning user than SAP transaction. To a large extent, a process maps to a HR action like hire, transfer, retire. Each process in turn is tied to one or more forms which the HR administrator fills up with data. There is provision to do data validation during the submission of the forms to ensure that data entered make sense. Workflows can be configured so that on submission of the forms, the process is routed to one or more level of approvals before the action actually comes into effect. Most processes are exposed to end users through portal links. Before looking at the security aspects of a process, lets first look at how a process would look like to a HR Administrator.

Before an administrator can start a process, he first needs to choose a start object. The start object can be an employee (like in the example below) or an OM object (like a position or org unit).

After choosing the start object, the administrator would need to select the actual process for the start employee. On selection, a Adobe form opens up where data can be entered. The fields and validations in the form are part of the configuration done by HCM functional consultants.

Security around HR forms and processes is highly customizable by config settings for each process. SAP has used a new authorization object P_ASRCONT (Authorization for Process Content) to restrict access to processes and forms. Further, configuration in SPRO allows us to use just this object, the standard HR objects for securing personnel data (P_ORGIN, P_ORGXX) or both for securing process contents. The details for this object are given below

The activities field value allows HR administrators to read, process, approve or submit forms or processes. The authorization scope values of 1 or 2 allows them to access a process when only they are the target object or for for all target objects except their own. This is important as ideally we wouldn’t want an administrator to give themselves a raise. The Content Type field takes two values, P for Processes and F for Forms. Finally we also have the Content Group field which is similar in use to a table or program authorization group. This free form text field allows us to group access for similar processes/forms to a select group of users. This same text value needs to be maintained in the process groups for each form and process that we would like to secure. This portion of the work is performed by the functional consultant and out of scope of the job of the security administrator.

In the example given earlier and the one right below, we have used two authorizations. We have used the content group ZEMPLOYEE to group processes that an employee should be able to start for his own pernr and this is maintained as part of the Employee Self Service access. The HR Administrator access on the other hand (given below) allows them to start gany HR processes.  The HR Admins however are prevented from startting these processes for their own pernrs