SAP Knowledge Base Article - Public

2080162 - Employee Central - Ad-Hoc Report Types & Permissions Explained

Symptom

  • What do the different Report-Table (AdHoc Report) Schema’s do for the Employee Central Report-Table (AdHoc Report)?
  • We are trying to create several different types of Employee Central Report-Table, but we are unsure what each report schema allows us to do!
  • How do the reports work with Permissions?

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental. 

Environment

SAP SuccessFactors Employee Central

Resolution

Please refer to the Employee Central Master Handbook for more information on this topic.

There are several report schema’s available for Employee Central Report-Table (AdHoc Report), some are end-user reports and others are purely meant for Admin or Power users (these reports are listed below with brief descriptions).

Basic Information about Report-Table (AdHoc Report)

  • Reports will time-out after 5 minutes - therefore, for the more complex / large Report-Table (AdHoc Report), we recommend that you run these Offline, or if they are to be run on a regular basis, they can be scheduled to run and output to SFTP.
  • Some reports do not support Role-Based Permissions
  • Always use filters in Date Range and As Of Date reports
  • If you encounter performance issues, please refer to KB article 2631131 - Ad Hoc Report queries take a long time to execute or are timing out - EC

Person and Employment (As of Date)

Employee data as of a given date (today by default unless specified)

  • Report on an employee’s HR information as of a particular date; for example, reporting all employees hired as of a certain date.
  • This report can be run based on future dates also, an example would be running a Termination report on 01/01/2013 to see how many future dated Terminations are set to take place As Of Date 01/31/2013.

Tips:

  1. Be mindful of the amount of Column Sets (JOINS) you include in 1 report - for example you could end up with duplicate rows in the report if you include Pay Component or Compensation Information  data (if employees tend to have more than one)
  2. Make sure to use Filters to limit the size/scope of the report - such as filtering on a particular Legal Entity, or Country.
  3. If you need to run a cell/field level permission report, please use Advanced Reporting tool
  4. When the report is executed, the "As of date" filter (under Required parameters) will show today's date by default. It is not possible to change this default date in the background or Backend. If you want to change this date, it must be done manually by the user who is executing the report.

Job Information (Date Range)

Employee data within a given date range, driven by Job Information

  • Report on an employee’s Job Info for a range of dates; for example, reporting all Job Information and Status changes within the give date period. For example, all Job Information and Status changes between 01/01/2012 and 07/01/2013 (mm/DD/yyyy).
  • Please note this schema will report on data based on the effective dates of the employees Job Information records. If you report on say Compensation Information, the report will generate 1 row per Job Info effective dated record the employee has, and NOT based on 1 row per Compensation Info effective dated record the employee has. Example is, if the employee has 3 Compensation Info records but 6 Job Info records, and you report on Job Information using this report, you will see 6 rows for Compensation Information, because the Compensation Information records are reported on based on the Job Info record effective dates, within the date range you specify.
  • This report does not respect Cell Level Permissions

Tips:

    1. The report will always generate based on Job Information data structure.
    2. If you add multiple column sets to the report, this will increase the complexity of the report and you may need to run the report offline for it to complete successfully
    3. When the report is executed, the "Start Date" and "End Date" filters (under Required parameters) will show +1/-1 year from current date by default. It is not possible to change these default dates in the background or Backend. If you want to change these dates, it must be done manually by the user who is executing the report. 

Recurring Compensation (Date Range)

Employee data within a given date range, driven by Compensation Information

  • Report on an employee’s Compensation Info for a range of dates; for example, reporting on salary changes between 01/01/2012 and 07/01/2013 (mm/DD/yyyy).
  • Please note this schema will report on data based on the effective dates of the employees Compensation Information records. If you report on say Job Information, the report will generate 1 row per Comp Info effective dated record the employee has, and NOT based on 1 row per Job Info effective dated record the employee has. Example is, if the employee has 3 Job Info records but 6 Comp Info records, and you report on Job Information using this report, you will see 6 rows for Job Information, because the Job Information is reported on based on the Compensation Info record effective dates within the date range you specify.
  • This report does not respect Cell Level Permissions

Tips:

    1. Only use this report to identify Spot Bonus/One-Time Bonus information for a period
    2. Do not include too many complex joins - for example do not include Pay Component Recurring data if there is no need
    3. If you are getting multiple (what looks like duplicate) rows - please ensure for each Effective Dated column set, you include also the Start Date and Sequence Number fields - this makes the report easier to understand when mashing a lot of different table data together 

Non-Recurring Compensation (Date Range)

Bonus payout within a given date range

  • Return information on the Non-recurring Pay Components within a Date Range specified by the user; for example, reporting bonus payments within a certain date range.
  • As with any Date Range report, be mindful of how the report is created - based on Spot Bonus data.
  • This report does not respect Cell Level Permissions

Tips:

    1. Only use this report to identify Spot Bonus/One-Time Bonus information for a period
    2. Do not include too many complex joins - for example do not include Pay Component Recurring data if there is no need
    3. If you are getting multiple (what looks like duplicate) rows - please ensure for each Effective Dated column set, you can also include the Start Date field - this makes the report easier to understand when mashing a lot of different table data together. 
    4. Transaction sequence number is not reportable in for Non-Recurring pay components. You can use One-Time Payments (EmpPayCompNonRecurring) entity from Integration Center > Create New Scheduled CSV File Output Integration and look for sequence number as an alternative.

Person and Employment (Audit)

Audit trail data for all Employee Central Core tables.

  • Report on all the inserts and corrections of an employee’s EC information, including who made changes and when; for example, reporting employee movements and flagging any historical changes.
  • We recommend that you use this report to determine who inserted, deleted or edited a record in the employees EC data. This is a very powerful report that will show 1 row per Insert/Update/Delete of EC data for each record that is reported on.
  • TIP - Run this on only 1 area of EC data at a time, example: Job Information (do not include Comp Info, or other data). Make a separate report for Comp Info audit, or Personal Info audit, etc.
  • This report does not respect Cell Level Permissions
  • Action Type in Audit Report:
    • Insert = Represents the change was made using 'Take Action' or Inserting a record into the history
    • Update = Can happen from either the 'Pencil' icon or from editing an existing record from the Employee History
    • Delete = The record was deleted. Please note that you can view any Deleted record with this report

Tips:

    1. You must filter the report to ensure that you do not get too much data returned. No filter will result in ALL audit data, but this will cause the report to likely fail (as it will be a LOT of data)
    2. The report should only ever be run on 1 column set. Do not mix fields from different columns sets, else this will skew the report when the tables are joined
    3. Only Admin users should have access to this report
    4. This report should not be used for any headcount/functional reporting - this is purely an Admin report to check who changed what, when
    5. You can see Deleted records in this report
    6. This report does not respect field level or cell permissions. It respects row level of the target population of the permission role.

NB: audit report always query the audit table and display all change (Insert, update, delete, correct, incorrect record) not the transcation table  information such as (Job information, personal infos)

Person and Employment (Export)

Employee data in a format ready for import

  • Export employee data so that they can be updated offline and reimported without having to format data in an import friendly way;  for example, you need to update Job Information records for multiple users. You would use this report to extract the data.
  • If you need to create multiple export files on a regular basis, you can create a Multi Data Set report using only the P&E Export schema, and include 1 column set per domain. Then you can extract data for Job Info, Comp Info, Home Address, etc, into separate tabs. Excel export is recommended here.
  • This report does not respect Cell Level Permissions

Tips:

    1. This report is only used to export EC data in an Import friendly format.
    2. Do not include multiple column sets (such as Job Information, Compensation Information etc). This report is meant to be run against 1 column set at a time (all fields in Job Information column list for example).
    3. This report should not be used for any headcount/functional reporting - this is purely an Admin report to allow export of data in an easy to use format for data imports
    4. This report does not respect Role-Based Permissions
    5. Ensure that this report is always run with filters - it will likely fail when run with no filters if the employee/employment population in the instance is very high. 

 Q) Is it possible to change the default "Start Date" and "End Date" filters (under Required parameters)?

No, the default date would always be as Start Date = (Current Date – 12 months) and End Date = (Current Date + 12 months).

If custom dates are required as a filter, the end user must manually set them during report execution.

Foundation Objects

Foundation object data

  • Export information directly from the Foundation Object tables that have been loaded to the system or manually entered; for example, reporting directly on one or more particular Foundation Objects, such as returning the details of all Locations and linked Organization Units (showing the relationship).

Tips:

    1. Use this report to Export only the Legacy Foundation Object data, in an import friendly format
    2. If you need to export MDF based Foundation Object data for import, please use "Import and Export Data" instead 

Multi Data Set Reporting

Note you should not mix and match the report schemas listed below when creating Multi Data Set reports. For example, if you create a multi data set report using a Date Range and an As Of Date schema, the system will generate the report based on the As Of Date schema. The same is true if you include the Export schema within the above scenario (Export, Date Range and “As of Date” schemas), then the report will actually run based on the Export report, and date range/as of date will not be possible with the reports. You will also have unexpected results and behavior, as the system is not designed to work in this way. If you do need to create Multi Data Set reports, please ensure you use the same schema type for each domain you add to the report.

Scheduled Reporting

All Employee Central Report-Table (AdHoc Report) can be scheduled to run and export to SF or external FTP folders. To set up scheduled Employee Central Report-Table (AdHoc Report), please create the report you wish to have scheduled, and then raise a Support ticket with the Customer Success team, who will help schedule the report for you. Please be sure to provide Customer Success with the timing the report should run under (what date/time should the report be scheduled to run, how often), and also the Name of the report and the username of the owner of the report.

Role-Based Permissions

Important:
This section will discuss the different features of permissions that can be applied to Report-Table (AdHoc Report). Please Note that each option has limitations and for a reporting framework which provides a rounded and inclusive permissions restriction, Advanced Reporting should be utilized.

  • Row Level Permissions - Row Level Permissions are enabled by default and cannot be disabled. This layer of security restricts the user running the report, to be able to report on the Target Population(s) assigned by Role-based Permissions. Please note that this will mean the user running the report will be able to report on any data for any user in their Target Population.
    • This is respective to the report schema you are creating. As of Date will limit 1 row for the Effective Date you report on.
      If Cell Level permission is turned off, then only Row Level permission is applied, meaning the report will include everyone in the Target Population of the user running the report.
      If Cell Level permission is enabled, then still the Row Level will include all the users in your Target Population, but then restrict what data you see in for that cell in the row for the targeted user.
    • Row Level Permissions includes Historical and Future Dated data. For period reporting = Date Range reports should be used if you want to see all records in a period.
      • An example of this would be: You have not enabled Cell Level Permission, and a Manager wants to run a Compensation report to see his Direct Reports Pay Component Data. If the Manager's Manager is in the Target Population, then they will see their Managers Pay Component Data.
      • If however Cell Level Permission is enabled, then further restricting based on RBP, the Manager will still see the columns but for the row where their manager comes, there will be no values returned in those cells. 
  • Cell Level Permissions - Please consider using Advanced Reporting tool if you need to have cell level permission in EC reports. Advanced Reporting was designed to respect the RBP permission of Employee Central automatically, without the need to enable any other switch in Provisioning. Refer the SAP Help Portal guide -> Building a New Advanced Reporting Query

    The Cell Level permission can result in different issues while running EC reports e.g. Home address columns blank; Username blank; Application errors due to memory issues; Corrupted output files exporting the reports; Manager Job Relationships fields blank in Cross domain reports, etc. These issues were reported to Engineering and the solution is to deactivate the Cell Level permission.

    In case you would like to test this feature, it can be enabled via Provisioning > Company Settings > "Enable Cell Level Permission for data model elements (in all Sub domain schemas)" and "Enable Cell Level Permissions on "Group by Reports". Once both switches are enabled, Cell Level Permissions restrict the output in the Report, based permissions in RBP. I.e. You will still be able to select the column "Legal Entity" but you will only get a value returned in that row if - 

    1) You have View permission granted to that field in your Permission Role, and 
    2) the user is in your Target Population (Row Level Permissions is always applied).
    • Once Cell Level Permissions are enabled, the As of Date schema will restrict the schema further, to limit the end users view to include All users in their Target Population, but then further restricted to see only the data in the Cells that they have Role-Based Permissions granted (still based on Target).
      • An example of this would be: You have enabled Cell Level Permission, and a Manager wants to run a Compensation report to see his Direct Reports Pay Component Data. If the Manager's Manager is in the Target Population, then they will still see their Manager in the report, but they won't see the data in the Cell's they are not permitted to view.
    • IMPORTANT: 
      • Only the "Person and Employment As of Date" report supports Cell Level Permission feature. This is the report that typically Managers would be running.
      • Cell Level Permissions are ONLY applied to permission enabled in the “Employee Central Effective Dated Entities” section of Permission Roles. Any permissions outside of this section will not be respected.
      • The enablement of this feature will cause an increase in performance times as additional processing of permissions is required on run of the reports.
      • Also, please be aware of a known issue using "Enable Cell Level Permissions on "Group by Reports" > KB article 2648522 - Error Message Occurred When Running Person and Employment Info (as of Date) Report 
  • Field Level Permissions - Field Level Permissions can be enabled via Provisioning > Company Settings > "Enable Field Level Permission for data model elements (in all Sub domain schemas)". Once enabled, Field Level permission will constrain the Report to only list Columns in the report based on fields permission granted in Permission Role.
    • An example of this would be: If you do not have permission to Legal Entity field, then you will not see it when creating or running the report.
    • IMPORTANT: With this switch, any "system" delivered fields that are not controlled in Role-Based Permissions, will no longer be available. For example, in the Audit report there are columns for "Source of Change", "Action Type", etc. As these columns are not controlled by Role-Based Permissions, turning on Field Level Permission would remove this column from the report configuration.
    • This switch applies to all EC related Report-Table (AdHoc Report)
    • It is not recommended to use this option due to the restriction of available fields for reporting. This removes valuable columns from the reporting and greatly reduced the visibility of data. 
    • This works for EP fields only. There was a tentative to implement that in EC schemas in b2011 Release. However, since this is natively supported in Advanced Reporting and People Analytics Report Stories, this is not going to be implemented anymore in Adhoc reporting.

NOTE:

  • Regarding the failure on enabling the switches in provisioning: There're a limitation in HANA DB for Join Support, if it crosses the max number of joins then error is thrown. Please note that in this particular report around 54 columns have been selected which is beyond the recommended number of 15-20 fields in a report from 3-4 different view groups. Please suggest the below recommendations:
    Reduce the number of fields to 15-20 fields in the report.

  • If 1st recommendation is not feasible or doesn't solve the issue then please disable the two switches in Provisioning "Enable Cell level Permission for all data model elements" and "Enable Cell Level Permission on "Group by Reports".

SAP employees can refer to Internal Memo for more details.

FAQ - Additional Information

Q) Field with field set to Masked = Yes or pii="true are not reportable?

A) Yes View: 2216586 - 'Masked' fields do not appear in Table (Ad Hoc) Reporting

FAQ - Additional Information

Q) Where can I get information on this from the Guide?

A) Guide:Implementing Employee Central Core                                                                                                                                                            Chapter: Permissions for Ad-Hoc Reports

See Also

  • 2648522 - Error Message Occurred When Running Person and Employment Info (as of Date) Report
  • 2317923 - Employee Central - Ad-Hoc Reports
  • 2352973 - Cannot Run an Adhoc Report on custom field with Employment Info (as of Date) for Specific Country " CSF Data Model" - SAP for Me 
  • 2631131 - Ad Hoc Reports take a long time to execute or are timing out - EC
  • 2099828 - How to see the label of the column when creating Ad Hoc Reports - EC
  • 2434120 - Ad Hoc Report Row/Field/Cell Permissions
  • 2385771 - Masking Number Sensitive Field Data in Employee Central
  • 2162775 - How to mask National ID to be kept confidential - SuccessFactors Employee Profile
  • 2464127 - Cannot Mask payComponentRecurring and payComponentNonRecurringt Value in Manage Business Configuration "BCUI"
  • 2434120 - Ad Hoc Report Row/Field/Cell Permissions

Keywords

SF, success factors, EC, Ad Hoc, Report, Table, Canvas, Center, Employee Central, types, explained, Person and Employment (As of Date), Job Information (Date Range), Recurring Compensation Non-Recurring (Audit), (Export), Foundation Objects, as date, date range, insert, update, Action, Person and Employment Info (as of Date), adhoc, ECT-130654, ECT-130892, Employee Central Effective dated entities, Provisioning,Enable Cell level Permission for all data model elements, Enable Cell Level Permission on "Group by Reports, Report-Table, reporting, permissions, rbp, role based permissions, role based permission, pii="true, Masked = Yes, Specific Country , KBA , sf employee central , LOD-SF-EC-REP , Reporting Data (EC core only) , LOD-SF-ANA , Analytics & Reporting (Ad Hoc, YouCalc, ORD) , How To

Product

SAP SuccessFactors Employee Central all versions ; SAP SuccessFactors HCM Suite all versions