Reporting 2.0 Overview
Reporting 2.0 provides a simple and intuitive way to build and use report templates to gather and deliver the information that matters most to every level of the organization.
Popular Topics | Training and Troubleshooting Resources | |
|
Click here to download the Reporting 2.0 Adoption Kit.

Anna Administrator
- As Anna Administrator, I build and maintain reports for my organization.
- I am most interested in the filter properties because I can:
- Make it easier for Viewers to know which criteria to set.
- Hide confusing filters.
- Limit how Viewers interact with filters.
- I build reports and bring in my favorite standard and custom fields.
- I share reports with other users and let them know they have a new report.
- I spend the most time making sure the filter logic is correct and easy to use.
Vicky Viewer
- As Vicky Viewer, I run reports for my team.
- I do not have the create permission, thankfully, because I am too busy to learn how to build reports.
- I love running report templates others have built for me. I change a couple filters like date.
- If I need something complex changed in the report, I will talk to Anna Administrator and ask her to change it for me.

With support for Succession, this includes the following custom fields:
- User Career Preferences
- Incumbent (Incumbent and User Succession Metrics)
- Successor (Successor, Successor Fields, and Successor Succession Metrics)
- Position Criteria
- Job Pool Task
The following features are not yet available:
- Exception Reports on custom fields
- System Templates for standard reports not explicitly listed
- Custom Fields for:
- SF-182
- Folders
- Succession Comment Log

The maximum number of records that can be returned in the report is 1,000,000.

This functionality is automatically enabled in all portals.

The granular model uses the Reporting 2.0 permissions to allow you to create more specific reports by report field. For this reason, permissions are at more of a granular level with this functionality.
The permissions are broken down by the main product level permission, section level, and then at the field level. For example, if you wanted to report on Instructor Led Training (ILT) in the system, you would need:
- The Reporting - Manage permission to create reports.
- The Reporting - View permission to preview reports and view reports.
- The top-level product specific permission to create reports related to that product.
- e.g. Reporting - Learning - Manage
- The section specific permission to create reports for that feature within the product.
- e.g. Reporting - Learning - ILT - Manage
- The field level permissions to be able to create reports with the specific fields for that feature within the product.
- e.g. Reporting - Learning - ILT - ILT Facility - Manage
If a user does not have each level of permission, then they may not have access to the report builder, or the section may not be visible, or the fields within the section may not be visible. Also, if a user does not have the top-level product permission, then none of the fields for that product will be visible, such as the fields for LMS reports.
The power of this granularity of permissions is that you can give access to as many or as few fields as necessary for your users. For example, you may give users access to the User section but not give them access to the User Identifier section if that contains sensitive data for your portal.
If a user has all relevant permissions, but the backend setting for a particular area is set to FALSE, any fields related to that section will still appear blank in a report. An example where this could occur is SCORM 2004 quiz data.
Note: When a user has a top-level, section, or field level permission, it is not necessary to also assign the or permissions since the more granular product specific permissions will give the user access to Reporting 2.0.
Note: Due to sensitivity, users who need to report on Gender, Ethnicity and Grade information, would need the following permissions in addition to the reporting permissions:
- For Gender: User Upload - Gender
- For Ethnicity: User Upload - Ethnicity
- For Grades: View Grades
List of Permissions
For the full list of permissions and their relationships, see the permissions spreadsheet.

The Apply Owner Constraints setting for reports in the Report Properties panel. This setting affects shared users, delivery, and reports published to dashboards.
permission grants the ability to turn on theWhen the setting is enabled, the report owner's constraints are applied to the report, and users that run the report will see the report with the report owner's constraints instead of their own. For reports published to dashboards the owner constraints are only applied if the underlying report is also shared with the user. If just the dashboard is shared, but not the report itself, the users own constraints are applied even though the toggle is set to apply owner constraints.
Due to the possibility of unintended user data becoming visible to a user viewing a report with the report owner's constraints, it is recommended that filters be added to the report to restrict data visibility. It is also recommended that the report owner test the report prior to sharing to ensure the data visibility is appropriate and intended.

The
permission grants users the ability to download Reporting 2.0 reports. This permission cannot be constrained; however, when users download a report, any Reporting - View constraints are applied. Users with the permission see the download option on the Report Home and the Report Viewer.For clients that have already opted in and previously activated Reporting 2.0, this new permission is added automatically to the System Administrator role and to any security role that currently has at least one Reporting - View permission.
For clients that are opting in and activating Reporting 2.0 for the first time with the August ’18 Release, this new permission is available to administrators in the System Administrator role who can then add the permission to other roles at their discretion. Users without this permission will not see any download options in the Report Home or the while Viewing Reporting 2.0 reports.

The
permission grants the ability to deliver reports in Reporting 2.0. Users must also have permission to view reports. The permission can be used in conjunction with the various product, section, and field level permissions. Users must have permission to view Reporting 2.0 in order to have access to a report that is delivered to them. If they do not have view access, then the Reporting 2.0 navigation sublink will not display for them.Users who have permission to manage Reporting 2.0 can edit a report that is delivered to them. They can also copy the delivered report.
The following constraints are available for this permission:

The
permission grants the ability to schedule delivery of Reporting 2.0 reports to an FTP directory. This permission cannot be constrained.This permission is used in conjunction with the view permission for Reporting 2.0 and can also be used in conjunction with the various product, section, and field level permissions. Users must have permission to view Reporting 2.0 in order to have access to a report that is delivered to them. If they do not have view access, then the Reporting 2.0 navigation sublink will not display for them.
Users who have permission to manage Reporting 2.0 can edit a report that is delivered to them. They can also copy the delivered report.

The
permission grants the ability to publish calculated fields to all users. This permission cannot be constrained.Note: Calculated fields can be created by all users who have permission to create reports in Reporting 2.0. However, in order to publish the calculated field globally, a user needs permission to manage global calculated fields.

The
permission grants access to build and manage reports in the Custom Integrations section. This permission cannot be constrained.
The
permission grants access to view the Custom Integrations section in reporting. This permission cannot be constrained.
The option for sharing reports is only visible to users who have the Reporting - Share permission. Users without the permission can still receive shared reports, but constraints (for other permissions, such as Reporting - Core permissions) will be respected. For example, if you share a report that contains data around Location A and the user receiving the report is constrained to only see data for Location B, the report would not contain any records.
The following constraints are available for this permission:
- OU
- User’s OU
- User Self and Subordinates
- User’s Direct Report
- User
- User's Self
- User's Manager
- User's Superiors
- User’s Subordinates
- User’s Direct Subordinates
- Relationship

The permission grants users the ability to use all system templates. System templates are available for generating certain Learning, Core, and Performance data.
This permission works in conjunction with other Reporting 2.0 permissions. For example, users without the Reporting - Learning - View permission will not see any templates for Learning.
This permission is automatically added to the Cornerstone Administrator and System Administrator security roles in all portals that have self-enabled Reporting 2.0.
Sharing Reports Created with a System Template
When you share a report that was created using a template, the shared users will be able to view the report without needing to be granted the Reporting - System Templates permission. The permission is only needed for administrators who should distribute templates to their users.
Permission Constraints
Constraints exist at the section level for permissions. The following constraints are available:
- OU
- User’s OU
- User Self and Subordinates
- User’s Direct Report
- User
- Learning-specific constraints:
- Requisition-specific constraints:
- User's Division
- User's Position
- User's Location
- Division
- Position
- Location
Note: Constraints are applied differently for Recruiting reports. Multiple criteria for the same OU type use the OR logic (e.g., only constraints for Location OU), while inter-OU type criteria use AND logic (e.g., a constraint for Location OU and a constraint for Division OU).
For all other reports, the regular constraint logic is applied. See this Knowledge Article for more details about the general constraint logic: https://csod-external.force.com/supportcentral/s/article/Several-constraints-added-to-permission-work-as-OR-statements.
Contents
The following information is available within this folder. Click a link to navigate directly to the appropriate topic: