Skip to main content
Documentation
Documentation
Administrator Guide
Last Updated: 2024-03-08
Steps: Set Up Constrained Security to People Analytics

Steps: Set Up Constrained Security to People Analytics

Security:
Manage: People Analytics
 domain in these functional areas:
  • People Analytics
  • Prism Analytics
When you configure the Security step of the
Worker
 and
Hiring
 pipelines, you can provide constrained access to the
People Analytics
 report at both the row level and field level.
Row Level Security
Field Level Security
To provide constrained access at the row level:
  • Specify a hierarchy in the
    Row Level Security
     section on the
    Security
     step.
  • Use a role-based constrained security group in the security policy of one of the People Analytics view domains:
    • View: People Analytics
      . Use this domain only if you don’t need to enforce field level security.
    • View: People Analytics Business Leader
    • View: People Analytics HR Business Partner
    • View: People Analytics Custom 1
    • View: People Analytics Custom 2
    • View: People Analytics Custom 3
To provide constrained access at the field level:
  • Choose how to enforce field level security in visualizations using a field restricted to the current viewer. For more information, see the
    Steps
     section.
  • Select 1 or more fields to restrict access to in one of the domains listed in the
    Field Level Security
     section on the
    Security
     step.
  • Use a role-based constrained security group in the security policy of the same view domain that you configured for field level security.
Ensure that a given user does not have access to more than 1 People Analytics-related view domain.
When constraining access at the row level, the hierarchy that you select and the fields included in that hierarchy determine which users have access to specific content in the application. Example: You map these fields:
Target Field
Mapped Business Object and Source Field
Example Value
Level 1
Supervisory Organization - 2nd level of the hierarchy
Corporate Customers
Level 2
Supervisory Organization - 3rd level of the hierarchy
Sales and Marketing
Level 3
Supervisory Organization - 4th level of the hierarchy
North America Marketing
Assigned Organization
Worker - Supervisory Organization
Leads Generation
A People Analytics user who has constrained access at Level 1 can view focus insights related to Level 1 and its subordinates. Therefore, a user who is assigned a role in Sales and Marketing sees focus insights for Sales and Marketing and North America Marketing.
A People Analytics user who is assigned a role in North American Marketing (mapped to Level 3) can see focus insights related to North American Marketing, but not to Sales and Marketing.
If you need to change the security settings after the initial deployment of People Analytics, you might consider requesting support through People Analytics Office Hours (available as a paid service) to ensure that the change won't cause security issues.
  1. Access the
    Configure People Analytics
     report.
  2. Select
    Edit
     for the
    Worker
     pipeline, and proceed to the
    Security
     step.
  3. For
    Row Level Security
    , select either
    Primary Hierarchy
     ,
    Secondary Hierarchy
     or
    Multiple Hierarchy
    . If you have constrained security access across both primary and secondary hierarchies, we recommend not choosing the
    Multiple Hierarchy
     option. The hierarchy you select must be a valid Prism securing entity field.
    Example: If you have
    Primary Hierarchy
     mapped to
    Organization Level
    , and
    Location
     mapped to a
    Secondary Hierarchy
    , each user's security group is secured by a single hierarchy at a time.
    • With
      Primary Hierarchy
       as row-level security: Only User A (constrained on the primary hierarchy
      Organization Level
      ) would be able to view KPIs and insights on the
      People Analytics
       dashboard. User B, whose security is based on
      Location
       (a secondary hierarchy), wouldn't have access to the data.
    • With
      Multiple Hierarchy
       as row-level security: Both User A and User B would be able to see insights and KPIs on the
      People Analytics
       dashboard. The system automatically applies the appropriate hierarchy to the corresponding users, so that each user sees the data they are entitled to based on their hierarchy constraints.
  4. For
    Field Level Security
    , select the security mode:
    • Standard. Workday enforces security strictly by displaying an empty state in a visualization instead of the data.
    • Threshold. Workday displays aggregated data in a visualization when a minimum population threshold is met, and hides restricted fields on the Detailed Data tab.
    You might lose some KPIs and focus insights when you restrict some of these fields if the population count goes below the minimum threshold during a data snapshot.
  5. On the
    Review
     step, select
    Finish
     to save the changes to the Worker pipeline.
  6. Configure the
    Hiring
     pipeline, and proceed to the
    Security
     step.
    • For
      Row Level Security
      , select the same hierarchy as the Worker pipeline.
    • For
      Field Level Security
      , select which sensitive data fields in which domains you want to restrict access to.
  7. Select
    Run Installation
     on the
    Configure People Analytics
     report.
    Wait for the installation activity to complete before proceeding so that Workday can finish securing the data records. Make sure that Workday secures the data records before you provide access to constrained users. You can view the progress on the
    People Analytics Activities
     report.
  8. Create security groups for your application viewers, and assign users.
    When configuring role-based constrained security groups, ensure that:
    • If you configured row level security, the security group type matches the securing hierarchy that you specified for
      Row Level Security
      . Example: You use Primary Hierarchy as the securing hierarchy, and map the Supervisory Organization field to the Assigned Organization target field. You create a security group of type Roles - Supervisory. Example: You use Secondary Hierarchy as the securing hierarchy, and map the Location field to the Level 3 target field. You create a security group of type Roles - Location Hierarchy.
    • In the
      Access Rights to Organizations
       section, you select
      Applies To Current Organization And All Subordinates
      . If
      Applies to Current Organization And All Subordinates
       isn't selected for your role-based security groups, you won’t see results for your entire organization and there will be a discrepancy between KPI and Insight results.
    • In the
      Access Rights to Multiple Job Workers
       section, you select
      Roles have access to the positions they support
      .
  9. Edit Domain Security Policies.
    Add the security groups to the security policies for the configured domains on the Security step, such as
    View: People Analytics Business Leader
    . If you didn’t configure Field Level Security, then add the groups to the
    View: People Analytics
     domain security policy.
    Ensure that each user has access to only 1 of the People Analytics view domains.
  10. Activate Pending Security Policy Changes.