Concept: Reporting Permissions
You can grant and be given varying levels of access to different capabilities and data within reporting and the report builder. Typically, users have multiple permissions working together to enable functionality. The least privileged user has only
custom.reports.execute
and the most privileged user has all permissions. Find the full list of VNDLY permissions and their descriptions by selecting , clicking Security Settings
under the Security
section, and then selecting the Permissions
tab.Vendor and Contractor Users
While users such as resource managers can have reporting permissions added and removed from their
Roles
under Security Settings
, vendor users get these reporting permissions by default:
- custom.reports.execute
- custom.reports.export
- custom.email.schedule
- custom.reports.create.limited
- custom.reports.create.full
- custom.reports.share
- custom.sftp.schedule
If you need to revoke any of these permissions for your VNDLY environment, please contact the VNDLY Support team.
Contractors have no access to reporting.
Dataset, Field, and Record Level Access
Having permissions to create, execute, and manage reports enables you to perform those actions, and to see the resulting data within the reports. You must also have the permissions related to the relevant area of VNDLY. This access is controlled in 3 levels or access: by dataset, by field, and by record.
Dataset and Field Access
You need permissions for a specific dataset or field, such as work orders or the budget field, to see the data in the report builder. Example: To see information around the work orders dataset, you'd need either the
workorder.owned.read
or workorder.read
permission. To see information around the Budget
field, you'd need the budget.read
permission. To view the required permissions for reporting datasets and fields, navigate to the
Reports
page. Depending on your permissions, you can access this page directly from the VNDLY header or in the drop-down menu. Click . On the Datasets
tab, these permissions are in the Access Permissions
column, and in the Fields
tab, you can find them in the Field Permissions
and Dataset Permissions
columns.Manage permissions for custom fields through the
Permissions
section of the Custom Fields
page. See Create Custom Fields in Settings in Workday VNDLY for more information.Record Access - Full Read Versus Owned
For many datasets, there's an option to limit records based on users who have some ownership of—or association to—the records. Otherwise, you can give them access to all records in a dataset that have data, not just the ones they're associated to.
Full-read permissions use a naming convention that doesn't include owned in the permission name. Example:
checklists.read
. When assigned a role that contains a full-read permission, you acquire read access to the data based on the Organization Unit
where the role was assigned to you, giving you access to any Organization Unit
that's a descendant of yours.Owned permissions use a naming convention that includes owned in the permission name. Example:
checklists.owned.read
. When assigned a role that contains an owned read permission, read access to the data is based on 2 criteria:
- TheOrganization Unitwhere the role is assigned.
- Ownership of the records in the dataset reported.
This access does generate for the descendants of the related
Organization Unit
, but both criteria must be satisfied. Examples of ownership (though not a comprehensive list):
- Resource managers are considered owners of jobs and work orders.
- A user who created a job is also considered an owner of that job and any work orders under it.
- Expense approvers are considered owners of an expense report record.
You can further enable
Reporting Hierarchy Access
on owned-read permissions, by going to , selecting Security Settings
under the Security
section, and navigating to the Configuration
tab. When you check the boxes in-line with each module, anyone with an owned-read permission passes that permission up their reporting line, according to the field Report to User
in the user profile.