Recruiters need relevant, timely, actionable information about their daily work, and information dashboards are an essential tool for meeting this need. Up until now, SAP E-Recruiting provided dashboards via a Business Server Page (BSP)-based user interface. The type of information available in these dashboards was quite limited, however. More importantly, the BSP-based dashboards had minimal configuration capabilities, could not be personalized by the user, and were not extensible.

With SAP enhancement package 4, Support Pack 4, SAP E-Recruiting dashboards are part of the work center delivered with SAP NetWeaver Portal. Using the Personal Object Worklist (POWL) included with SAP NetWeaver Portal, SAP E-Recruiting provides flexible, customizable dashboards that can be personalized for a variety of users, as well as the ability to easily develop custom dashboards to meet specific needs. Only some simple back-end ABAP coding is required to describe how the custom dashboard should work. The rendering is handled by the delivered POWL application, which is based on Web Dynpro for ABAP.

While, in our opinion, POWL is one of the most exciting and useful user interface frameworks that SAP has delivered, documentation on its configuration and development is limited, particularly in the area of SAP E-Recruiting. We aim to fill that gap by showing HR IT professionals how to personalize, configure, and extend SAP E-Recruiting dashboards for users using the POWL framework. We will explain:

• What dashboards are, and what users can do with them
• How to configure predelivered dashboards for users
• How to extend SAP standard-delivered dashboards with custom code to support custom information and behavior

Recruiters will also benefit from this article by learning what personalization options are available to them. Although the provided examples and screenprints are specific to SAP E-Recruiting (Enhancement Package 4, Support Pack 4), much of the information in this article can be applied to other solutions that use the same POWL framework, such as the operational reporting functionality available with SAP enhancement package 4 and SAP Learning Solution.

What Are SAP E-Recruiting Dashboards?

SAP E-Recruiting dashboards offer a real-time snapshot of recruiters’ work, with the ability to quickly perform common activities such as dispositioning of candidates with a minimum number of clicks. Dashboards are also designed to be tailored by recruiters to match their own information needs. The dashboards can be found in the work center for the Recruiter user role delivered with SAP enhancement package 4 and later.

SAP E-Recruiting dashboards are based on the POWL functionality included with SAP NetWeaver Portal. Users will likely already be familiar with the Universal Worklist (UWL) functionality within SAP NetWeaver Portal, which is widely used to send notifications to users that an event has occurred or a task must be completed. In SAP E-Recruiting, UWL is used for requisition request approvals. POWL serves a completely different purpose. Whereas UWL is used to simply push tasks to users, POWL provides content that is:

• Informational: Some line items in a dashboard contain useful information, but may not lead to action
• Role-specific: The IT organization determines which dashboards are available to which users
• User-driven: Users can personalize the type of dashboard shown as well as its appearance
• Actionable: If the system presents users with information, what will they need to do with it? For example, a recruiter viewing new applications may need to quickly reject some, or a recruiter may need to quickly navigate to applications at a certain stage of the recruitment process

Figure 1 shows an example SAP E-Recruiting dashboard. The upper portion of the dashboard lists the user’s relevant queries, which contain the selection criteria for generating the needed information, organized into categories. The lower portion contains the results of the selected query, any actions that can be taken, and options for personalizing the query or the display. As you can see in the example, we’ve selected the My Open Requisitions query, which shows all requisitions for the lead recruiter that have the status Released. The queries and categories that users initially see when they view the SAP E-Recruiting work center are determined by their SAP E-Recruiting back-end roles. The queries and categories are preconfigured and assigned to certain roles, usually by an HR analyst or business process specialist in the Human Resource Information Services (HRIS) group when the dashboards are implemented and possibly again as business needs change or SAP delivers new functionality. Figure 1 shows the queries and categories associated with the Recruiter back-end user role, which is the focus of this article.

Figure 1

The standard Recruiter dashboard

Users can personalize their dashboards by changing the delivered queries, creating new queries, changing which queries are visible, and changing which query is shown when initially viewing the dashboard. For instance, suppose a colleague on your requisition support team is going on vacation and, as her backup, you want to see a separate listing of requisitions where she is the lead recruiter. Using the Open Team Requisitions query as a base, you can simply modify the selection criteria to show only your colleague’s requisitions and save it as a new query.

Users can also personalize how the query results are displayed in the table view using the Filter and Settings links. This enables the user to display the query results in many different ways and store multiple personal views of the data. For example, say that when you are looking at your requisitions you want to see the average days since release, but sometimes you want to quickly switch to see the maximum days since release. Having two views to select from avoids having to change table settings each time. The table view is delivered in a Web Dynpro-based SAP List Viewer (ALV) grid form. As such, settings and filters for the table are the same as those you would use to personalize any other table based on a Web Dynpro ALV grid.

Configuring Predelivered Dashboards for Users

Predelivering default dashboards to users through predefined POWL queries makes it easier for users to get started. Without predefined queries, users would see a blank dashboard when they view their SAP E-Recruiting work center and would have to create queries from scratch. This can be a frustrating and inefficient use of time, especially when 90 percent of the time recruiters with the same role in an organization need the same dashboard queries. Configuring dashboards for your users is a step-by-step process that starts with the ABAP code that defines what’s possible – either the code provided by SAP or your custom code – and ends with a personalized user dashboard.

From ABAP Code to User Experience: How It Fits Together

Figure 2 shows the process of using configuration to deliver default queries to users that they can personalize to their needs. Each step in this process depends on the preceding steps.

Figure 2

Tying ABAP code to user experience through configuration

The important thing to note is that the ABAP feeder class defines the mechanics of everything that can be done with a query. The POWL type ties the feeder class to the configuration and acts as a template for queries. Queries then refine the behavior defined by the feeder class to what the business user needs. For example, My New Applications is a POWL type that is based on an Applications feeder class. The technical definition of this feeder class includes the filter criteria Application Source, Lead Recruiter, Hiring Manager, and Candidate Type. Say you want to deliver a query to users that lists only applications that come from an employee referral. You simply define a query called New Employee Referrals based on the My New Applications POWL type and set the Application Source filter criteria to Employee Referral. To deliver the query, you tie it to the role assigned to those users, which drives the default look of their dashboard. Users assigned to that role can in turn view and modify the query, or define their own, within the limits of their role and authorizations.

Let’s take a closer look at each of the elements of this configuration process. Table 1 lists some important transaction codes that are used during the configuration. POWL configuration functions are also located in the IMG under Cross-Application Components > General Application Functions > Generic SAP Business Suite Functions > Personal Object Worklist.

Table 1

Useful transaction codes for configuring queries

POWL Type

The POWL type is a thematic grouping of data objects and actions that serve as the template for a query. The behavior of the POWL type is defined by the logic of its associated ABAP feeder class. The feeder class determines which data to retrieve and display for the query, which columns should be available, and which actions the user can perform. Tying the POWL type to a feeder class enables you to reference the type of dashboard you need without having to refer to the ABAP feeder class each time.

SAP delivers standard POWL types and feeder classes for SAP E-Recruiting. You can view the standard POWL types using transaction POWL_TYPE. SAP E-Recruiting POWL types start with ERC_WORKCENTER_. You can view the standard feeder classes in the Class Builder (transaction SE24). SAP E-Recruiting feeder classes are all named CL_HRRCF_M_*_POWL_UI, where * is the specific type of SAP E-Recruiting data (for example, CL_HRRCF_M_POSTING_POWL_UI). The standard POWL types and feeder classes are used to define a set of standard queries. You can also use them to configure your own queries, either as is or you can modify them to fit your needs (more on this when we look at how to extend dashboards with custom code). You can also create your own POWL types and feeder classes, but it’s much better to start by copying the delivered ones from SAP. Any custom SAP E-Recruiting dashboards still rely on standard SAP E-Recruiting data, even if you have created a lot of custom data structures that need to be read.

The POWL type is defined and tied to feeder classes using transaction POWL_TYPE, or in the IMG under Cross-Application Components > General Application Functions > Generic SAP Business Suite Functions > Personal Object Worklist > Configure Worklist Type Repository. Figure 3 shows the detailed view of a POWL type within transaction POWL_TYPE.

Query

The query definition determines the dashboard content and appearance. The content is determined by the selection criteria (filtering criteria such as Application Source or Candidate Type that defines which data should appear). The appearance is determined by the table layout (display parameters such as visible table columns and layout style). Queries are also assigned to a category – either a standard category or a custom-defined one – to organize the content of the recruiter’s screen. You can deliver predefined, categorized POWL queries with preset selection criteria and ALV grid views that users can then tailor to their own needs.

The query is always a subset of what is allowed by the POWL type. The POWL type defines everything that is possible, such as the available selection criteria and the total list of columns that can be shown. The query configuration defines how you want the default queries to appear to the user. SAP delivers standard queries and query categories for SAP E-Recruiting roles. Table 2 lists the standard queries available for the Recruiter role, which you can view in transaction POWL_QUERY, along with the standard POWL types on which they are based. (In addition to the queries listed in the table, there is a delivered Requisitions To Be Deleted query, but this is for the Recruiting Administrator role, not the Recruiter role that is the focus of this article.) Similar to the standard POWL types, standard queries for recruiters in SAP E-Recruiting start with ERC_WORKCENTER_. You can use the delivered queries and categories as is, you can modify them as needed, or you can create your own from scratch.

Table 2

SAP-delivered queries and POWL types for the Recruiter role

Figure 4 shows how you define POWL queries in transaction POWL_QUERY. You can also access this screen in the IMG under Cross-Application Components > General Application Functions > Generic SAP Business Suite Functions > Personal Object Worklist > Define Default Queries. This example shows the SAP standard-delivered My Draft Requisitions query, based on the standard POWL type ERC_WORKCENTER_DRAFT_REQ. 

Figure 4

Definition of a POWL query

You can change the selection criteria by using the Query Parameters options. You can use Query Settings to change how users are able to use the selection criteria (e.g., you can set certain criteria to be read only or hidden). The Layout variant settings are a browser-based way of defining the default columns and layout of the table view, similar to how the end user would customize the layout. Calculated Dates are used to specify relative rather than absolute dates, or ranges such as “Current date plus 7” meaning “The next week.” This is especially useful for a My Planned Activities query, if you want to show upcoming interviews.

Role

A role defines which default queries and categories are presented to users when they view their SAP E-Recruiting work center. The back-end user role, such as Recruiter, is assigned in transaction SU01 (User Maintenance). You can assign default queries to certain roles using transaction POWL_QUERYR.

Normally a role is assigned multiple queries – for example, the standard Recruiter role is assigned the queries My Open Requisitions, Open Team Requisitions, and My New Applications, among others. Often queries are assigned to multiple roles (if both a Shared Service Center role and a Recruiter role need the same new applications query, for instance).

Figure 5 shows the assignment of queries to roles in transaction POWL_QUERYR. The Application column shows the relevant application for the query (for SAP E-Recruiting, application ERC-WORKCENTER, which is the application that calls the POWL dashboard). Note that the Role column is blank in this example, which indicates that the query is valid for all users of this application.

Figure 5

Assignment of queries to roles

Authorization Objects

Sometimes there are groups of users that you don’t want changing things such as table layouts because it can be a support burden. For example, if you have a custom POWL query to serve the needs of headhunters submitting candidates, you might want to remove the ability to delete queries because they will be very infrequent users of the system.

Authorization objects are a means of controlling access to data and functions within SAP software, and they enable you to specify who is able to make changes to queries. You can view available authorization objects tied to SAP user profiles and roles in transaction PFCG, as shown in Figure 6. The authorization object CA_POWL has useful authorization values, such as disabling changes to table settings. To disable ALV grid changes by the user, for example, set field value POWL_TABLE to Disallowed in transaction PFCG for authorization object CA_POWL.

Figure 6

Authorization object for POWL table personalization

Now that you’re familiar with all the elements of this process, let’s take a look at a simple example query configuration.

Example: Configuring a Query

In this example, we will create a new query that shows only internal applications for our requisitions. We will base the new query ZERC_WORKCENTER_QRY_NEW_INTAPPL (My New Internal Applications) upon the existing standard query ERC_WORKCENTER_QRY_NEW_APPL (My New Applications).

Step 1. First you define the new query in transaction POWL_QUERY by changing the query ID to ZERC_WORKCENTER_QRY_NEW_INTAPPL and the query description to My New Internal Applications, as shown in Figure 7. Keep the original query’s standard POWL type (ERC_WORKCENTER_TYPE_NEW_APPL) as is.

Figure 7

Create a new query in transaction POWL_QUERY

Step 2. Next, set the selection criteria for the query by changing the query parameters so that the candidate type is set to I (Internal), as shown in Figure 8. Leave the default layout as is.

Figure 8

Add selection criteria to the query

Step 3. Use transaction POWL_QUERYR to assign the new query to a role, so that it is visible to the user. In the example (Figure 9), we left the role blank so that it’s available to all roles that can access the ERC-WORKCENTER application (the application that calls the POWL dashboard for SAP E-Recruiting). Leave the category assignment as is.

Figure 9

Assign the query to a role using transaction POWL_QUERYR

Step 4. Figure 10 shows the finished result. The new query (My New Internal Applications) appears under the same category (Applications) as the standard query on which it is based (My New Applications).

Figure 10

Dashboard showing the My New Internal Applications query

Extend Dashboards with Custom Code

Organizations often have custom data and applications that the SAP-delivered queries cannot access from the dashboard. You can easily add this capability to your queries by adding custom code to the ABAP feeder class that describes the POWL behavior.

Before we jump into the coding, let’s first take a high-level look at turning user needs into powerful dashboard user experiences. Mapping out a process for gathering and consolidating requirements is especially useful when a lot of new data and business logic is required beyond what is provided by the SAP-delivered code. Adding one custom column to an existing ABAP feeder class doesn’t require much effort, but when dealing with significantly enhanced or new dashboards, it’s best to have a methodical approach to set accurate expectations, to make sure nothing falls through the cracks, and to avoid a scenario in which, for example, you expend resources on creating two different ABAP feeder classes that are 90 percent the same.

Working with Business Users to Determine Requirements

The ABAP code needed to generate a POWL type is quite simple. As with any custom development, the crucial part is ensuring the needs of the user are correctly translated into dashboards. Figure 11 summarizes a proposed process.

Figure 11

Turn requirements into dashboards

• Define data needs for all users. For each role, gather input on what data is needed for which dashboards, and which actions need to be allowed for against the data. You can do this using examples – spreadsheet templates of data, columns, and actions – and interview sessions.
• Create a low-fidelity dashboard mockup for each role. It’s useful for a mockup to have the basic look of SAP E-Recruiting, but not look too realistic. Low-fidelity mockups help users visualize solutions without being hampered by thinking it’s an already-built solution. Using paper and pen, Microsoft PowerPoint mockups, or low-fidelity mockup software such as Balsamiq Mockups (there are many different inexpensive packages) means that users think, “We could change this to that” rather than “Why doesn’t it do this” or “I hate that color.”
• Validate the mock-up dashboards. Gather feedback and incorporate it into dashboard refinements.
• Create the feeder classes and the POWL types. Using the information you have gathered, create the ABAP feeder classes and the POWL types that will define the behavior of the dashboard. (See the sidebar, “How the ABAP Feeder Class Determines POWL Type Behavior.”) It makes sense to group requirements that belong together into areas such as Postings or Requisitions as it is done in the standard SAP E-Recruiting POWL types. Remember that the POWL types are tied to the feeder classes and drive everything that can be done in the dashboard. You later refine them into individual queries using query configuration.

Create and Configure POWL Queries from Scratch

The following is a high-level summary of the steps required to create and deploy custom dashboards. As with many SAP areas, the steps are hierarchical, so the previous step must be completed before moving on to the next step.

Step 1. Create a feeder class in the Class Builder (transaction SE24) that implements interface IF_POWL_FEEDER. It’s best to find an existing SAP E-Recruiting feeder class and copy it – the class method and returned attributes contain all of the business logic responsible for querying the database, and provide instructions to the POWL type on how to present the data.

Step 2. Register your POWL type in the POWL repository using transaction POWL_TYPE.

Step 3. Assign the POWL type to a role.

Step 4. Create queries in transaction POWL_QUERY and assign them to the appropriate role using POWL_QUERYR.

Step 5. Assign categories to the query in transaction POWL_QUERY.

Let’s take a look at a specific example that illustrates these steps in more detail. Note that while the example generally follows the high-level summary of the steps just described, there are some deviations that make the process flow better when working with a copy of an SAP standard object.

Example: Create a New POWL Query

In this example scenario, the business users would like existing employees that have applied for a job to appear in a separate list. The business policy at MyCorp calls for the employee’s existing manager to acknowledge the employee’s application. To facilitate this process, we need to create a worklist to identify the employee’s manager and send a confirmation request using a confirmation activity in SAP E-Recruiting.

Step 1. Because we will be working with a specialized version of the application worklist, the SAP-standard POWL feeder class for application worklists (CL_HRRCF_M_APPLICATION_POWL_UI) is the most logical starting point. Make a copy to the customer namespace (ZCL_EE_CAND_POWL) in the Class Builder, as shown in Figure 12.

Figure 12

Copy the standard feeder class to the customer namespace

Step 2. After creating the class copy, follow the configuration steps necessary to make the query visible in the recruiter dashboard:

• In transaction POWL_TYPE, create type Z_MGR_INTERNAL_CAND and assign ZCL_EE_CAND_POWL as the feeder class (Figure 13).

Figure 13

Assign the copied feeder class to the POWL type

• In transaction POWL_TYPER, assign the type to the application ERC-WORKCENTER (the application that calls the POWL dashboard for SAP E-Recruiting).
• In POWL_QUERY, create a new query Z_MGR_INTERNAL_CAND and assign it the type you created with the same name (Z_MGR_INTERNAL_CAND), as shown in Figure 14.

Figure 14

Create the query and assign the type

• In POWL_QUERYR, assign the query to the SAP standard Applications category, ERC_WORKCENTER_APPL_CAT (Figure 15). Leave the role assignment empty, so that the query is available to all users.

Figure 15

Assign the query to a role and category

Step 3. Test your configuration by making sure the new query appears in the dashboard. The results should be identical to the standard My New Applications query.

Step 4. Now it’s time for some ABAP coding. Because the requirements call for including some new information that is not part of the SAP class, you need to use a different return structure that can handle the new values. To continue the theme of “start with something from SAP,” use the Data Dictionary (transaction SE11) to make a copy of the return structure used by the standard class (CL_HRRCF_M_APPLICATION_POWL_UI), which is RCF_S_WC_APPL_UI, and its corresponding table type RCF_T_WC_APPL_UI. We’ve named the return structure copy ZRCF_MGR_ACK_S and the table type copy ZRCF_MGR_ACK_T.

Step 5. In the Data Dictionary add the new fields to ZRCF_MGR_ACK_S (Figure 16):

• ZCURR_MGR (current manager)
• ZCURR_MGR_POS (manager’s position)
• ZCURR_MGR_EML (current manager’s email)
• ZCURR_MGR_PHN (current manager’s phone number)

Because these fields are simply for display, we supplied a generic text data element, BU_NAME1TX.

Figure 16

Add fields to display to users

Step 6. Now is a good time to check and see if you need to update any of the attributes in the copied class. One of the gotchas that we found during testing was that the class we copied from, CL_HRRCF_M_APPLICATION_POWL_UI, had an attribute GT_WC_APPL that was defined to use the type RCF_T_WC_APPL_UI. Since the standard structure does not have those new fields, we needed to update the attribute definition in our class using the Class Builder (SE24), as shown in Figure 17.

Figure 17

The attribute we had to adjust within the Class Builder

Step 7. You are now ready to begin the work of adjusting the class methods in the Class Builder to include the required business logic. Since you are starting from the SAP-delivered class, what follows is a description of the changes made to each of these methods:

• GET_ACTIONS: We removed the checks for all of the SAP query types and instead supplied our type, Z_MGR_INTERNAL_CAND. Because our query only calls for one dashboard, we defined our action with the ID MGR_ACK and created a new OTR for the label, as shown in Figure 18. 

Figure 18

Assign the attributes of the manager acknowledgement action

• GET_ACTION_CONF: No changes made.
• GET_SEL_CRITERIA: We liked the selection criteria used by the SAP application class used by the type ERC_WORKCENTER_TYPE_NEW_APPL. We simply substituted our type Z_MGR_INTERNAL_CAND using find/replace.
• GET_FIELD_CATALOG: We substituted our type Z_MGR_INTERNAL_CAND for ERC_WORKCENTER_TYPE_NEW_APPL. We added definitions for our new fields (ZCURR_MGR, ZCURR_MGR_EML, and ZCURR_MGR_PHN), set the colpos (column and position) attributes so that the new fields we added will be displayed prominently, and identified OTR texts for the labels.
• GET_OBJECT_DEFINITION: We replaced the SAP standard return structure with ZRCF_MGR_ACK_S
• GET_OBJECTS: We substituted our type Z_MGR_INTERNAL_CAND for ERC_WORKCENTER_TYPE_NEW_APPL. We want only internal candidates so we added a new selection parameter:

        ls_selection_var-selname = 'CANDTYPE'.

        ls_selection_var-sign    = 'I'.

        ls_selection_var-option  = 'EQ'. 

        ls_selection_var-low     = 'I'.

        APPEND ls_selection_var TO lt_selection_var.

• GET_DETAIL_COMP: We substituted our type Z_MGR_INTERNAL_CAND for ERC_WORKCENTER_TYPE_NEW_APPL 
• HANDLE_ACTION: We substituted our type Z_MGR_INTERNAL_CAND for ERC_WORKCENTER_TYPE_NEW_APPL. We added a handler for our new activity, a manager acknowledgement patterned after the rejection action, and we supplied the number for our custom action type (9109).

After performing the above steps, we ran our query, anticipating success only to be met with errors. It was not until we debugged that we discovered that the class called by SAP to perform the heavy lifting on the query, CL_HRRCF_APPLICATION_WL_PL, was actually hard-coded with references back to the original class CL_HRRCF_M_APPLICATION_POWL_UI and types RCF_T_WC_APPL_UI and RCF_T_WC_APPL_UI. To address this, in the Class Builder we made a copy of CL_HRRCF_APPLICATION_WL_PL to our namespace ZCL_HRRCF_APPLICATION_WL_PL, and made the following changes to the class:

• We changed the class attribute GO_SINGLETON to reference our newly created class ZCL_HRRCF_APPLICATION_WL_PL (Figure 19).

Figure 19

GO_SINGLETON attribute changed to reference the new class

For each of the methods below, we updated the case statements to include our new type of Z_MGR_INTERNAL_CAND wherever we found a reference to ERC_WORKCENTER_TYPE_NEW_APPL:

• INITIALIZE_BUFFER
• DETERMINE_SEL_CRIT
• BUILD_WHERE_CLAUSE_APPL
• PERFORM_SELECT_APPL
• BUILD_RETURN_TABLE_APPL
• BUILD_FROM_CLAUSE_APPL
• BUILD_WHERE_CLAUSE_APPL_2
• BUILD_WHERE_CLAUSE_APPL_1

For example, in INITIALIZE_BUFFER, the IF statement condition that begins the method used to look like this:

  if gv_powl_type eq 'ERC_WORKCENTER_TYPE_NEW_APPL' or
     gv_powl_type eq 'ERC_WORKCENTER_TYPE_TEAM_APPL'.

And now looks like this:

  if gv_powl_type eq 'ERC_WORKCENTER_TYPE_NEW_APPL' or
     gv_powl_type eq 'ERC_WORKCENTER_TYPE_TEAM_APPL' or
     gv_powl_type eq 'Z_MGR_INTERNAL_CAND'.

• Additionally, we needed to change the import parameter on GET_INSTANCE to use our new custom class name, ZCL_HRRCF_APPLICATION_WL_PL (see Figure 20).

Figure 20

Change the import parameter to use the custom class name

After making all of the necessary adjustments, our custom query is finally complete. Figure 21 shows the new query and its fields in the dashboard.

Figure 21

Voila! An Updated POWL with a new internal candidate worklist

Mark Ingram

Mark Ingram is a recruiting technology consultant and entrepreneur with a focus on SAP systems. Mark was the product manager at SAP for E-Recruiting before consulting. You may follow him on Twitter @ingramtalent, or read his blog at https://blog.ingramtalent.com.

You may contact the author at mark@ingramtalent.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Brandon Toombs

Brandon Toombs is a long-time SAP ERP HCM consultant, specializing in ESS, MSS, ECM, E-Recruiting and Performance Management. You may follow him on Twitter @brandontoombs.

You may contact the author at btoombs@toombsconsulting.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.