Comparing row-level security vs object-level security models for workforce analytics

HCM Workday HCM
, , , , , , , ,
1

I’m evaluating security models for our workforce analytics implementation and wanted to get the community’s perspective on row-level security versus object-level security. We have complex data privacy requirements across multiple regions and business units.

Row-level security seems more granular - we could filter which employee records each user sees based on organization, location, or custom criteria. But I’m concerned about performance impact when running large analytics queries with thousands of security rules being evaluated.

Object-level security is simpler - users either have access to the entire report/dashboard or they don’t. Easier to maintain but less flexible for our use case where managers should only see their org’s data.

What are others using for workforce analytics? What are the real-world performance considerations and maintenance tradeoffs you’ve experienced? On R1 2023 if that matters for security features.

2

I’ve implemented both models. For workforce analytics specifically, row-level security is almost always necessary unless you have a very flat organization. The performance considerations are significant - row-level security adds a WHERE clause to every query, and if your security rules are complex, it can slow down report generation by 30-40%. We mitigate this by pre-aggregating data in custom reports and applying security at the aggregated level rather than the raw transaction level.

3

We use row-level security extensively and the performance impact is real but manageable. The key is designing efficient security rules. Avoid complex nested conditions and use indexed fields (like organization hierarchy) for filtering. Our largest reports have 50K+ rows and still perform acceptably because we optimized the security rule logic. The maintenance burden is higher though - you need to update rules whenever org structures change.

4

The maintenance tradeoffs are often underestimated. With row-level security, every organizational change requires security rule updates. When we did a major restructuring last year, it took three weeks to update all the row-level security rules across our analytics reports. Object-level security would have required no changes. That said, row-level is the only way to meet data privacy requirements - you can’t show European managers data for US employees without row-level filtering. We ended up using a hybrid approach: object-level for high-level executive dashboards, row-level for manager self-service reports.

5

After implementing workforce analytics security at three different organizations, here’s my comprehensive perspective on row-level vs object-level security:

Row-Level Security vs Object-Level Security Comparison:

Row-level security provides granular control - each user sees a filtered subset of data based on security rules. Object-level security provides all-or-nothing access - users either see the entire dataset or nothing.

For workforce analytics, row-level security is almost always necessary due to:

  • Management hierarchy requirements (managers see only their teams)
  • Regional data privacy regulations (EU employees data restricted to EU HR)
  • Business unit separation (finance analytics separate from operations)
  • Sensitive data protection (compensation data limited to compensation team)

Object-level security works only in limited scenarios:

  • Executive dashboards where all executives see all data
  • Public HR metrics (headcount, diversity stats) available to all employees
  • Department-specific reports where access is uniform within the department

Performance Considerations in Practice:

Row-level security adds computational overhead:

  • Query execution time increases 20-40% on average with complex security rules
  • Impact scales with number of security conditions and data volume
  • Worst case: complex nested rules on 100K+ row datasets can add 2-3 seconds

Performance optimization strategies that work:

  1. Use organization hierarchy for filtering (indexed, efficient)
  2. Avoid calculated field evaluations in security rules
  3. Pre-aggregate data where possible (apply security to summaries, not transactions)
  4. Cache security rule results for frequently-accessed reports
  5. Use Workday’s security segment calculated fields (pre-compute authorized viewers)

Real example from our implementation:

  • Before optimization: Manager dashboard with row-level security took 8 seconds
  • After optimization: Same dashboard with indexed org hierarchy filtering took 2.5 seconds
  • Key change: Replaced complex conditional security with simple ‘User is Manager of Organization’ check

Maintenance Tradeoffs:

Row-level security maintenance burden:

  • Organizational changes require security rule updates
  • New business units need new security segments
  • Ongoing testing to ensure rules work correctly after changes
  • Documentation overhead (which rules apply to which reports)
  • Estimated maintenance effort: 5-10 hours per month for large organizations

Object-level security maintenance burden:

  • Minimal - only changes when report access requirements change
  • Estimated maintenance effort: 1-2 hours per month

However, the maintenance cost of row-level security is offset by:

  • Reduced risk of data privacy violations
  • Better compliance with regulations
  • More flexible access control (easier to grant temporary access to specific data)
  • Audit trail of who accessed what data

Hybrid Approach Recommendation:

For most organizations, use a hybrid model:

  1. Object-level security for:

    • Executive dashboards (C-suite sees all data)
    • Company-wide metrics (headcount, diversity publicly visible)
    • Compliance reports (specific roles get full access)

  2. Row-level security for:

    • Manager self-service reports (filtered by management hierarchy)
    • HR business partner dashboards (filtered by assigned organizations)
    • Regional analytics (filtered by worker location)
    • Compensation analytics (filtered by job level and authorization)

  3. Security design patterns:

    • Use ‘User is Manager of Organization’ for hierarchical filtering
    • Use ‘Related to User’ for HR BP assignments
    • Use location-based rules for regional compliance
    • Create security groups for special access (compensation analysts, HR operations)

Implementation Guidance:

Start with object-level security as your baseline, then add row-level security only where business requirements demand it. This minimizes complexity while meeting compliance needs.

For R1 2023 specifically, take advantage of the enhanced security segment functionality - you can now use multiple security segments in a single report, which provides more flexibility without performance penalty.

Test performance with production-scale data before rolling out. What works fine with 1000 rows may be unusable with 100K rows. Build in performance monitoring and set SLAs for report load times (we use 5 seconds as the maximum acceptable for interactive dashboards).

The real-world tradeoff is: row-level security costs more to implement and maintain, but it’s the only way to meet modern data privacy requirements and provide appropriate access control for workforce analytics. The performance impact is manageable with proper optimization, and the compliance benefits far outweigh the costs.