Designing RBAC - Multi tier enterprise structures

I led the UX architecture for a large scale enterprise portal serving complex multi entity organisations. These organisations operated across nested account hierarchies with shared services, delegated administration, and strict governance requirements.

The challenge was not visual design. It was structural clarity.

We needed a permission model that could scale across:

  1. Head accounts

  2. Parent entities

  3. Child and sub entities

  4. Shared services

  5. Multiple user types with overlapping responsibilities

The platform ran on Salesforce with predefined permission constraints, which meant UX and system logic had to align precisely.

The Core Problem

Enterprise customers do not operate as flat organisations.

A single company may have:

  • A corporate head entity

  • Regional subsidiaries

  • Department level cost centres

  • External affiliates

Users often operate across multiple levels simultaneously. An individual might administer services for one child entity, view reporting for another, and have no access to financial controls at the head level.

Traditional role models break down in this environment.

  1. Flat roles create over permission.

  2. Granular rules create confusion.

  3. Delegated admin introduces risk.

The problem became:

How do we design a permission system that is secure, scalable, and cognitively simple?

Constraints

  • Salesforce RBAC and permission set architecture

  • Regulatory and financial governance requirements

  • Delegated administration models

  • Cross account reporting needs

  • AI surfaced insights that must respect data boundaries

This was not just a backend decision. Every permission rule had a UX consequence.

My Approach

I reframed RBAC as a user experience problem rather than a technical configuration problem.

Instead of asking “What permissions exist?” I asked:

  1. Who am I in this structure?

  2. Where am I operating right now?

  3. What am I allowed to do here?

  4. Why can I not do something?

I developed a three dimensional permission model:

Role × Entity × Capability

Example:

  • Role
    Org Admin
    Service Admin
    Portal User
    Affiliate

  • Entity
    Head account
    Parent
    Child
    Sub entity

  • Capability
    Manage users
    View billing
    Order services
    Edit contracts
    Access AI insights

By mapping these as intersecting dimensions, we created a matrix that clarified scope and responsibility.

This model informed:

  • Navigation states

  • Visibility rules

  • Action availability

  • Delegation flows

  • Error messaging

  • AI insight exposure logic

Designing for Clarity

We introduced clear structural cues in the interface:

  • Explicit entity context switching

  • Visible role indicators

  • Scoped action panels

  • Permission based UI states

  • Transparent messaging when actions were restricted

Instead of silent failures, the system communicated boundaries.

For example:
“You can view this contract but cannot edit because you are assigned as Service Admin at Child Entity level.”

This reduced ambiguity and improved trust.

Governance and Delegation

Delegated administration is where enterprise systems often fracture.

We designed structured delegation flows that:

  • Prevented privilege escalation

  • Respected hierarchy boundaries

  • Made inheritance rules explicit

  • Reduced accidental over permission

This required close collaboration with backend engineers to align UX flows with Salesforce permission sets.

AI and Data Safety

As AI surfaced insights such as contract risk, cost anomalies, and service recommendations, permissions became even more critical.

We ensured AI respected the same Role × Entity × Capability model.

Insights were scoped to user authority.
No cross entity leakage.
No exposure of restricted financial data.

The AI layer inherited governance rather than bypassing it.

Impact

While specific metrics are confidential, the structural outcomes included:

Reduced permission related support escalations
Improved clarity in delegated administration
Safer self service at scale
Increased confidence in AI surfaced insights
A scalable framework adaptable across enterprise accounts

More importantly, the permission model became reusable infrastructure for future product development.

Reflection

Enterprise UX is not about decorative dashboards.

It is about invisible correctness.

When permissions are unclear, users hesitate.
When boundaries are silent, trust erodes.
When governance is brittle, scale breaks.

By treating RBAC as a design problem rather than a configuration task, we created a system that balanced flexibility, safety, and clarity across complex organisational structures.