Is Your HRIS Missing Team-Level Granularity for RBAC?

When your source of truth is not granular enough.

Workday says she’s in “Engineering.”

Which of the 47 engineering teams? Backend? Frontend? Platform? SRE? Security? Data? Machine Learning? Infrastructure? DevOps?

Each team needs different access. Different repos. Different Slack channels. Different dashboards. Different tools.

But the HRIS only knows “Engineering.”

This is the granularity gap.

What HRIS Provides vs. What RBAC Needs

Human Resources Information Systems (HRIS) like Workday, BambooHR, or ADP are designed around organizational hierarchy and employee administration. They track legal employer and cost center, high-level department, job title, manager, location, employment type, and compensation data. This information serves HR’s needs: payroll, benefits, org charts, headcount reporting.

RBAC needs differ fundamentally. Provisionr asks: “What specific resources should this person access?” The answer depends on functional role, which is often more granular than anything in HRIS.

Consider the difference:

HRIS knows	RBAC needs to know
Department: Engineering	Team: Platform Engineering
Title: Software Engineer	Specialty: Kubernetes, AWS
Manager: Jane Smith	Project assignments: Project Alpha, Project Beta
Location: San Francisco	On-call rotation: Yes

The HRIS attributes are too high-level to drive granular access decisions. An “Engineering” group is easy to create. But “Platform Engineers who work on Kubernetes and are part of the on-call rotation”? That data doesn’t exist in HRIS.

Where the Granularity Actually Lives

If granular role information isn’t in HRIS, where does it reside?

1. In managers' heads

   Managers know which sub-team each person is on, what projects they’re working on, and what tools they need. That knowledge isn’t systematically captured anywhere.

2. In team wikis and docs

   Somewhere there’s a Confluence page or Notion doc listing team members. It’s almost certainly out of date.

3. In the tools themselves

   GitLab knows who has access to which repos. Slack knows who’s in which channels. But each tool only knows about itself.

4. In custom attributes

   Some organizations add custom fields to Okta or their IdP to capture team-level information. The question of who maintains those fields rarely has a satisfying answer.

5. In spreadsheets

   The dreaded spreadsheet makes another appearance. Someone, somewhere, has a spreadsheet of team assignments.

The granularity exists, but it’s fragmented, inconsistent, and not connected to access automation.

The Downstream Effects

When the source of truth lacks granularity, the effects cascade.

1. Access becomes over-broad

   If groups can only be created at the department level, everyone in Engineering gets Engineering access—even if they only need access to one sub-team’s resources. Least privilege disappears.

2. Access requests fill the gap

   When automation can’t provision team-specific access, users request it manually. Every team-specific access need becomes a ticket.

3. Manual maintenance burden grows

   Someone has to track team membership outside the system and manually update group membership when it changes. That someone is usually IT.

4. Audit answers are incomplete

   “Why does this user have access to X?” The answer is often “because they’re in Engineering,” which isn’t a satisfying justification for team-specific resources.

Over-broad access based on department rather than team creates least-privilege violations that auditors flag during SOC 2 and ISO 27001 assessments. When access can’t be justified at the appropriate granularity level, organizations face findings under CC6.1 (logical access controls) and A.9.2.1 (user access provisioning).

The Custom Attribute Trap

The obvious solution is custom attributes. Add a “Team” field to the IdP. Populate it with values like “Platform Engineering” or “Frontend” or “SRE.”

This works, but creates new problems.

1. Ownership becomes unclear

   HR owns the HRIS. Who owns the custom attribute? IT? Managers? When ownership is unclear, data quality suffers.

2. Currency becomes a challenge

   HRIS data updates when HR processes happen (hiring, promotions, departures). Custom attributes update when someone remembers to update them, or when a manager submits a request.

3. Multi-team membership creates complexity

   Some people are on multiple teams. Custom attributes typically hold a single value. Multiple attributes or comma-separated lists introduce their own challenges.

4. Naming conventions drift

   Is it “Platform Engineering” or “Platform” or “platform-eng” or “Platform Team”? Without governance, variations creep in and break automation.

Custom attributes can work, but they require discipline and process that most organizations don’t have. They become yet another thing that’s always slightly wrong.

Dimensions: A Different Approach

What if, instead of cramming everything into IdP custom attributes, organizations built a purpose-built layer for organizational dimensions?

A Dimension is a category of organizational metadata—like “Team” or “Region” or “Management Level.” Each Dimension has Attributes, which are the specific values—like “Platform Engineering” or “EMEA” or “Director.”

Here’s the key insight: Attributes can be defined by rules, not just data.

Consider “Management Level.” Most HRIS systems don’t have a management level field. But it can be derived from job titles:

Attribute: "Director"
Rules:
- title starts with "Director"
- title starts with "Sr Director"
- title starts with "Senior Director"
- title ends with "Director"

Anyone whose title matches any of these rules is assigned the “Director” Attribute. A Dimension that doesn’t exist in source data is now computable from data that does exist.

Building Dimensions the HRIS Doesn’t Have

Let’s walk through creating a “Management Level” Dimension since it’s universally useful and almost never exists in HRIS.

Step 1: Define the Dimension

Dimension: Management Level Purpose: Categorize users by their position in the management hierarchy Values: Executive, Vice President, Director, Manager, Individual Contributor

Step 2: Define each Attribute’s rules

Attribute: Executive

Rule 1: title equals "CEO"
Rule 2: title equals "COO"
Rule 3: title equals "CFO"
Rule 4: title equals "CTO"
Rule 5: title equals "CIO"
Rule 6: title starts with "Chief"
Rule 7: title starts with "Executive Assistant"  // Include EAs at exec level

Attribute: Vice President

Rule 1: title contains "Vice President"
Rule 2: title starts with "VP"
Rule 3: title starts with "SVP"
Rule 4: title starts with "EVP"

Attribute: Director

Rule 1: title starts with "Director"
Rule 2: title starts with "Sr Director"
Rule 3: title starts with "Senior Director"
Rule 4: title ends with "Director" AND title does not contain "Vice"

Attribute: Manager

Rule 1: title starts with "Manager"
Rule 2: title starts with "Sr Manager"
Rule 3: title starts with "Senior Manager"
Rule 4: title ends with "Manager" AND title does not contain "Account"  // Exclude Account Managers who are ICs

Attribute: Individual Contributor

Rule 1: NOT matches any other management level
// Or explicitly: does not contain "Manager" AND does not contain "Director" AND ...

Step 3: Use the Attributes in access policies

Now there’s a “Management Level” Dimension that can be referenced in any Ruleset:

Ruleset: Leadership Dashboard Access
Conditions: Management Level equals "Director" OR Management Level equals "VP" OR Management Level equals "Executive"

The title variations are handled once in the Attribute definitions. Every downstream use references the computed Attribute, not raw title strings.

Rule-based Attributes create auditable, repeatable access decisions. Instead of explaining “we manually determined this person is a Director,” organizations can demonstrate “this person matches our documented Director criteria, which automatically grants leadership dashboard access.” This satisfies SOC 2 CC6.2 requirements for logical access implementation.

Team Dimensions Without HRIS Data

The same pattern works for team-level granularity.

Option 1: Manager-based teams

If team structure follows reporting lines:

Attribute: Platform Engineering Team
Rules:
- Manager is Jane Smith (Head of Platform)
- Manager's manager is Jane Smith (include skip-levels)

When someone changes managers, their team Attribute updates automatically.

Option 2: Project-based teams

If teams are project-based and tracked in a project management tool:

Attribute: Project Alpha Team
Rules:
- Custom attribute "projects" contains "Alpha"

The custom attribute can be populated by a sync from Jira, Asana, or the project tool.

Option 3: Hybrid definition

Combine multiple signals:

Attribute: SRE Team
Rules:
Rule 1: Department is "Engineering" AND title contains "SRE"
Rule 2: Department is "Engineering" AND title contains "Site Reliability"
Rule 3: Department is "Operations" AND title contains "Infrastructure"
Rule 4: Specific user: [e-mail]  // Edge case, was hired before title standardization

The Metadata Enrichment Strategy

Here’s the strategic approach to solving the granularity gap.

1. Identify the Dimensions needed

   What organizational structures drive access decisions? Department (from HRIS), Team (not in HRIS), Management Level (derivable), Region (from HRIS), Project (from project tools)?

2. For each Dimension, determine the data source

   Some come from HRIS. Some are computed from other attributes. Some need to be synced from other systems. Some require manual curation (but minimized).

3. Build Attributes with rules

   Define each Attribute using whatever conditions match users correctly. Prefer computable rules over manually maintained data.

4. Reference Attributes in access policies

   Rulesets use Attributes, not raw data. When the underlying data changes, Attribute membership recalculates automatically.

5. Handle edge cases explicitly

   Some people won’t fit neatly into computed rules. Named user conditions handle exceptions without polluting the rules.

The result: access policies that are as granular as they need to be, without requiring HRIS to track information it was never designed to track.

---

Ready to build the Dimensions your HRIS doesn’t have? Learn how to create custom Dimensions and Attributes →