Concept: Security in Prism Analytics
Prism Analytics uses Workday's strong, flexible, and configurable security model to control access to data, objects, and tasks. Which users have access to what data depends on where in the Prism data workflow they are. For more information on the workflow, see Concept: Prism Analytics Data Management Workflow.
Phase 1 and Phase 2: Create and Edit Tables, Datasets, and Data Change Tasks
In the first and second phases in the data management workflow, you bring data into the Prism Analytics Data Catalog and then transform it. You create and edit these objects in the Data Catalog:
- Tables. Tables include metadata and all data rows in the table.
- Derived datasets. Datasets include metadata and a subset of data as a small collection of example rows.
- Data change tasks. Data change tasks include a small collection of example rows from the target table, and from the source if it's another dataset or table.
When it comes to security with tables, data change tasks, and datasets, you control access to the metadata and data together.
Table and Dataset Security
Workday controls who can do what with tables and datasets in these ways:
Method | Notes |
|---|---|
Security administrator grants access | Your Workday security administrator can configure Workday security domains to grant groups of users to be able to create, edit, or manage tables and datasets. Depending on how the administrator configures the security domains, some users might be able to create, view, edit, or act as an owner of all tables and datasets. Your Workday security administrator can configure these Workday security domains to grant access to groups of users:
|
Table sharing and dataset sharing | The user who created a table or dataset can share it with particular users and grant different levels of access to each user.
When you create a table or dataset, you're the table owner or dataset owner. Being the owner means that you have Table Owner or Dataset Owner permission on the table or dataset. As an owner, you can grant different levels of access by assigning permissions to another user. Example: You can assign Table Viewer or Can Truncate Table Data permission to a table, or Dataset Editor permission to a dataset. |
Access to a table or dataset is unconstrained. This means that any user who can create or view a table or dataset can view all fields and data (example data for datasets and data change tasks), regardless of the origin of the data. When you create a table or base dataset from a Workday report, Workday removes all security domains configured for the business objects in the table or dataset.
If you're new to Workday, you don't have access to create or edit base datasets.
This unconstrained access only applies when you use these tasks and reports:
- View Table Details
- Edit Table
- View Dataset Details
- Edit Dataset Transformations
- View Dataset Transformations
- Create Data Change Task
- Edit Data Change Task
Instead, you define the data source security to apply to the data in the Prism data source before making the data available for analysis.
Data Change Task Security
You can't configure access on a data change task directly. Instead, Workday controls your access to a data change task based on:
- Your target table permissions. Workday uses these table permission types:
- Table Viewer
- Table Editor
- Table Owner
- Can Delete Table Data
- Can Insert Table Data
- Can Update Table Data
- The specified operation type. You need permission to change data in the table that is compatible with the specified operation type. Example: To create or edit a data change task on the Claims table using the upsert operation, you must have permission to insert and update data in the Claims table.
- Your source access. You need permission to view the source, such as view permission on a custom report, source dataset, or SFTP connection. You don't need view permission on the source when the type is file upload.
Workday doesn't enable users to have view permission only on a data change task. If you have permission to edit a data change task, then you have permission to view it.
If you meet the source access requirement, then you can perform the actions below with the specified target table permissions:
Table Viewer Only | Table Viewer and Can Delete/Insert/Update Table Data | Table Editor or Table Owner | |
|---|---|---|---|
View a data change task. | No | Yes | Yes |
Create a data change task. | No | Yes, but you can only select an operation type that is compatible with your table permissions. | Yes |
Edit the data change task operation type. | No | Yes, but you can only select an operation type that is compatible with your table permissions. | Yes |
Edit the data change task source. | No | Yes, but you need permission on the new source. | Yes, but you need permission on the new source. |
Edit other data change task properties (not the source or operation). | No | Yes | Yes |
Phase 3: Apply Security to the Data
You define the security that Workday will apply to the Prism data source before you make the data in the Data Catalog available for analysis. By applying security to the Prism data source, you can ensure that both Workday and non-Workday data have the proper restrictions applied when viewed in a discovery board or report.
You configure the data source security by editing the table or dataset, but Workday applies the security to the data in the Prism data source.
Define the data source security after the data is ready to be exposed to other users by giving them access to the Prism data source.
To configure the data source security, you must access to the
Prism: Manage Data Source
security domain. For details, see Edit Prism Data Source Security.You can restrict access to the data in a Prism data source at these levels:
- Data source-level.Specify 1 or more security domains that apply to the Prism data source that Workday creates. These domains determine which users can see the Prism data source. This is sometimes known as table-level security. If you don't configure any domain, Workday uses thePrism: Default to Dataset Accessdomain.
- Row-level.Optionally, you can enforce row-level security by specifying in theSecuring Entitiesprompt 1 or more Instance or Multi-Instance fields in the table or dataset, such as Supervisory Organization. The securing entities work with the configured data source-level security domains to determine which users have access to which rows (and field values) in a Prism data source.
- Field-level.Specify 1 or more security domains to apply to the fields in the Prism data source. These domains determine which users can see each field in the Prism data source.
- Field value-level.Workday uses any configuredSecuring Entitieswith the configured field-level security domains to determine which users have access to which field values in a Prism data source.
Phase 4: Make the Data Available for Analysis
When you make Prism data available for analysis, Workday creates the Prism data source, loads it with the transformed data, and applies the appropriate security restrictions to the data.
The way you create a Prism data source and the security required depend on the Data Catalog object. For more information, see Concept: Making Prism Data Available for Analysis.
Optionally, you can create a Prism data source without any data source security configured. When no data source security is configured, Workday applies the
Prism: Default to Dataset Access
security domain to the Prism data source. The Prism: Default to Dataset Access
domain provides contextual access to a Prism data source based on your access to the underlying table or dataset.Phase 5: Analyze and Visualize the Data
Workday controls access to data in a Prism data source according to the configured data source security. The configured data source security determines who can see the Prism data source, and which rows, fields, and field values each user can see when they query the Prism data source in a discovery board or report.