Human Capital Management Blogs by SAP
Get insider info on SAP SuccessFactors HCM suite for core HR and payroll, time and attendance, talent management, employee experience management, and more in this SAP blog.
cancel
Showing results for 
Search instead for 
Did you mean: 
FrankErle
Product and Topic Expert
Product and Topic Expert
797

Abstract

There is often the request to restrict the permissions for showing historic employee data and to show only the actual data at the employee profile versus the request to report on employee data. This blogpost highlights the dilemma, provides some deeper insights and gives some recommendations.

Introduction

Story reports can currently only be executed if the permissions for "XXX Information Action" => "View History" (where xxx = Personal, Address, Compensation, Dependents, Job, Job Relationship) have been assigned. Figure 1 shows the settings from Admin Center -> Manage Permission Roles -> User Permissions -> Employee Central Effective Dated Entities.

Deeper_Insights_Into_Story_Reporting_Of_Historic_Data_1.jpgFigure 1 – “View History” for Address, Dependents and Job Information Actions required to execute story reports

Multiple customers are not happy to provide report users the permission for “View History”; in particular if such report users should only execute simple operational reports which run just for “Today”. Examples of such simple operational reports are “Address lists”, stories about work permit details, compensation details and also simple headcount or FTE analyses for various dimensions (e.g. regular versus temporary employees, fulltime versus parttime employees, male versus female employees, age ranges or length of service ranges).

The "View History"-requirement is a kind of precautionary measure to avoid that data shown in the story reports are visible in the employee profile and vice versa. It is so-to-say a consequence of the fact that the permissions settings were originally built for the master data maintenance, i.e. the Employee Profile UI, and do not 100% "fit" for reporting. This is discussed and shown in the following in more details. Nevertheless, an approach is described how to restrict the data which are exposed to users and it is illustrated what this means for reporting.

Before a deeper dive in the reporting behaviour is given, it’s worth to remember how the Employee Profile UI behaves:

  • Only if "Job information Action -> View History" is assigned, historical data is accessible (1) via "clock watch" and (2) via "As of Date" picker (top right of employee profile UI). Figure 2 illustrates this: The "As of Date" picker is indicated in yellow. The "clock watch" is indicated in red; if you click on it, the “Change History” popup shows the complete history. Here, you can click on the different time slices on the left panel, so that the respective details are shown on the right side.
  • If "Job information Action -> View History" is not assigned, then the clock watch is invisible. If now the "As of Today" is changed to any historic/future date, then the text "This information is temporarily unavailable" is shown for the respective portlet (see Fig. 3).

Deeper_Insights_Into_Story_Reporting_Of_Historic_Data_2.jpgFigure 2 – Accessing the job information history details

Deeper_Insights_Into_Story_Reporting_Of_Historic_Data_3.jpgFigure 3 – Behaviour if "Job information Action -> View History" is not assigned and "As of Today" is changed to any historic/future date

The following need to be kept in mind for reports. Reports....

  • ....can run for one specific date (e.g. today, last day of last year, today two years back, etc.)
  • .... or you can configure the time filter so that a time range is considered. Here, a distinction is made as to whether a "history" is considered (e.g. employment or compensation history) or whether certain events such as e.g. "Hires", "Promotions" or “Terminations” are reported in a selected time range (e.g. last 5 years).

Solution

In the following a permission configuration is presented which restricts the display of history details in the employee profile but in parallel allows the execution of simple reports for today. The downside of this approach is that more sophisticated reports which run for time ranges have to be considered with care.

It is suggested to use the following configuration (see Fig. 4): You can set the data blocking for “XXX Actions (View History)” from "Full Access" to "Restricted - 0 months" (where xxx = Personal Information, Address Information, Dependents, Job Information or Compensation Info).

Deeper_Insights_Into_Story_Reporting_Of_Historic_Data_4.jpg

Figure 4 – Setting up the data blocking for “Job Information Actions (View History)” to “Restricted – 0 months”

This means that

  • the "Clock Watch" is visible in the corresponding portlet. If you click on it, however, only the current time slice is visible (indicated with the red box in Figure 5), all other time slices are no longer visible (indicated in the red dashed box in Figure 5).
  • If you select something different than "As of Today" in the Date Picker, the corresponding portlet shows the text "This information is temporarily unavailable".

Deeper_Insights_Into_Story_Reporting_Of_Historic_Data_5.jpgFigure 5 – Only current time slice is visible in Change History portlet

After this configuration the different time filters in reporting behave in the following way:

  1. No time filter is applied in the query:
    => Then, simply the latest record is reported.
  2. An “As of Date” filter is applied in the query:
    => Then, the latest record is reported if the Reporting Date is equal or larger than the effective start date of the latest record (May 12, 2022 or later for the example of “Michael Pittman” as shown in the example above). Otherwise no record is reported.
  3. A “Date Range” filter with the option “Include only records that begin during your defined date range” is applied:
    => Then, the latest record is reported if the reporting time range start date is equal or larger than the effective start date of the latest record (May 12, 2022 or later for the example of “Michael Pittman” as shown in the example above). Otherwise no record is reported.
  4. A “Date Range” filter with the option “Include any records that partially or completely overlap your defined date range” is applied:
    => Then, the latest record is reported if there is an overlap between the entered reporting date range and the time slices of the today's record (i.e. May 12, 2022 until infinite for the example of “Michael Pittman” as shown in the example above). Otherwise no record is reported.

Most important to mention is the guiding principle that the described behaviour is 100% consistent with the employee UI behaviour: No data are shown in the report which are not exposed on the employee profile UI and vice versa.

Nevertheless, note that the described behavior can lead to some confusion with the story report output if the permission for the full history is not given. This can be illustrated by the following two examples:

  1. There are time slices for Employee A and Employee B with effective start date “1.March 2024”. In addition, for employee B an event "Pay Rate Change" is posted at 16.September 2024. Therefore following records exist in the job information table:
    EmployeeEffective Start DateEffective End DateEvent 
    Employee A01.03.202431.12.9999Data Change 
    Employee B01.03.202415.09.2024Data Change 
    Employee B16.09.202431.12.9999Pay Rate Change 
    If the configuration was set up as described above (i.e. permission for job information action granted but data blocking period = 0 months) and an “As of Date-report” is executed for 1.July 2024, then only Employee A will show up (reason: the record valid at 1.July 2024 is the today's record), while Employee B will not show up in the story report at all because the start date of the latest (=today's) record is after 1.July 2024 and the time slice valid at 1.July 2024 is hidden due to the permission settings.
  2. Employee C and Employee D were both hired at 1. July 2024. For employee D an event "Data Change" is posted at 1.September (e.g. the job title was corrected), while for Employee C the hiring record is still the record which is valid today. Therefore following records exist in the job information table:
    EmployeeEffective Start DateEffective End DateEvent 
    Employee C01.07.202431.12.9999Hire 
    Employee D01.07.202431.08.2024Hire 
    Employee D01.09.202431.12.9999Data Change 
    If the configuration was set up as described above (i.e. permission for job information action granted but data blocking period = 0 months) and a Hire Analysis report (i.e. reading job history with filter for event = "Hire/Rehire") is executed for 2024, then, Employee C is reported as new hire (reason: the hire record is the latest = today's record), while Employee D will not show up in the report because the latest (=today's) record is the "Data change" and the previous "Hire-record" is hidden due to the permission settings.

Conclusion

These examples illustrate that the results of reports which are run for a date different than “today” or run for time ranges may appear as incomplete when they are executed with limited “View History”-permissions. Vice versa, the "data blocking = 0 months" – configuration, is only recommended for roles of report users which use stories that are executed for a particular day which is “Today”.

1 Comment