How to Design Authorization Model for Facility Management Systems

An authorization model for facility management systems is a design framework that separates operational scope, organizational relationships, and access policies into distinct dimensions so that multiple vendor organizations can share a site without collapsing their visibility and management rights into a single hierarchy.

This article draws on work around a production facility platform that already serves multiple vendor organizations. Client and product names are omitted; the relationships and failure modes are unchanged.

During ongoing development, we started seeing early symptoms that the current authorization model would not hold as vendor complexity grew: overlapping operational scopes with no way to separate organizational boundaries, cross-vendor rules living in role exceptions rather than explicit policy, and requirements that sounded simple in business terms: each vendor sees only their own people, but could not be expressed cleanly in the existing design. The model had been adequate for an earlier stage. Multi-vendor contractor management was pushing it past that point.

Rather than wait for those gaps to surface during the next vendor onboarding, we ran a structured stress test of the authorization model. The goal was adversarial scenario generation: contractor chains, peer vendors on shared sites, client override rights without full chain visibility. Not code. A clearer domain model and a set of targeted improvements we could proactively propose to the client.

What follows explains why access control in shared facilities cannot rely on location or asset hierarchy alone. The location tree answers where someone operates. The asset tree answers what equipment they work on. Neither answers who they can see or manage across organizational lines, or what rules govern that visibility. Shared facilities need three separate authorization dimensions: operational scope, organizational relationships, and explicit policies for cross-boundary visibility and management rights. This article explains why those dimensions are distinct, how each maps to a design concept, and what changes in system design when they are properly separated.

Key Takeaways:

• Shared facility systems cannot model access through location or asset hierarchy alone. Once multiple organizations operate in the same site, a single hierarchy produces permission leaks.
• Three authorization dimensions are required and distinct: operational scope tells where, organizational relationships tell who, and explicit policies govern visibility and management rights across boundaries.
• Policy is a first-class authorization concept. Without it, cross-boundary visibility and management rules live in undocumented flags, role exceptions, and hard-coded cases.
• Introducing the Policy dimension as a first-class concept reduces role proliferation because relationship-based rules move out of role definitions and into explicit, auditable policies.
• Stress-testing an authorization model before the next vendor onboarding surfaces dimension collapse early: when the fix is a design conversation, not a production incident.

What Does a Single-Hierarchy Authorization Model Get Wrong?

Facility management platforms typically serve several vendor organizations at once. Cleaning companies, security firms, and maintenance contractors all operate in the same building. Their workers and administrators share the same system.

Without proper separation, a cleaning company administrator can gain visibility into security staff. A maintenance vendor can interact with workers outside their organizational boundary. These are the kinds of outcomes we were trying to rule out before they reached production: not theoretical edge cases, but realistic failure modes as more service providers join a shared platform.

The root cause is a modeling decision made before multi-vendor requirements appeared. Most systems organize access through a single hierarchy: a location tree, an asset tree, or both. Those hierarchies answer one question well. Location tells the system where an actor operates. Asset hierarchy tells it what equipment or resources they work with. Neither dimension answers who an actor can see or manage, or what rules govern interactions between organizations sharing the same floor.

When the location tree is the only authorization axis, two vendors on the same floor appear equivalent to the system. Their scopes overlap. Their organizational boundaries do not. The model has no way to express the difference.

Why Do Location and Asset Hierarchies Fall Short for Multi-Organization Access?

Scope is the hierarchical structure of physical or logical spaces: building, floor, unit, zone. An admin assigned to Floor 3 can operate anywhere within that floor and nowhere above it in the tree.

Asset hierarchy is a parallel structure built around equipment, systems, or resource groups rather than locations. A technician assigned to an HVAC system or a zone of electrical panels has a scope defined by what they work on, not just where they stand.

Both hierarchies answer one question well. Scope answers where. Asset hierarchy answers what. Neither answers who.

Consider two vendors, both assigned to Floor 3 of a logistics facility. Their scopes are identical. Their organizational boundaries are completely separate. The system has no way to express that distinction using location alone. Add an asset hierarchy and the problem persists: both vendors may have overlapping access to the same equipment register while belonging to organizations that should have no visibility into each other.

Scope is a spatial concept. Organization is a structural one. Treating them as the same dimension produces gaps that are hard to detect and harder to reason about when something goes wrong.

What Are the Three Authorization Dimensions a Shared Facility System Needs?

Each dimension answers a different question. None substitutes for another. Together, they replace a single hierarchy with a model that can express what shared facilities actually require.

Operational scope

Scope is the location tree: building, floor, unit, zone. It determines operational territory, not organizational reach. A vendor’s scope may overlap completely with another vendor’s scope. That tells the system where both vendors work. It tells the system nothing about whether they should see each other’s workers or manage each other’s roles.

Organizational relationships

Organization defines the administrative perimeter around a tenant or vendor. An admin inside an organization manages the people, roles, and assignments within that boundary. In this model, Organization is the Party Pattern from enterprise data modeling, renamed to fit project vocabulary. The structure is identical.

The Party Pattern

The Party Pattern is a structural concept from enterprise data modeling presented in the book Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML by Jim Arlow and Ila Neustadt, published on January 8, 2004. A Party is any person, organization, or group that participates in business relationships within a system. Individual workers, cleaning companies, logistics operators, and HVAC subcontractors are all modeled as Parties. What distinguishes them is not their type but their position in a relationship.

Each Party holds one or more Party Roles that describe its position: client, vendor, subcontractor, employer, employee. The same Party can hold different roles in different relationships. A maintenance firm is a vendor to the logistics operator and effectively a client to its own HVAC subcontractor. Parties are connected through Party Relationships that describe the nature of the connection: contractual, employment, subcontracting, ownership. These relationships are directional and typed. A logistics operator has a contractual Party Relationship with a maintenance vendor. That vendor has a subcontracting Party Relationship with its HVAC specialist. The cleaning firm and the renovation firm have no Party Relationship at all.

That last point carries noteworthy weight. The absence of a Party Relationship between two parties is not a gap in the data. It is the model explicitly stating that no administrative connection exists between them. That explicit absence is what makes the default-closed principle workable in a multi-vendor platform.

The Party hierarchy determines administrative reach. A party can see and manage other parties that sit below it in the relationship structure, and only those parties. This maps directly to the authorization model: who falls within an organization’s administrative reach is determined by the Party Relationships attached to that organization, not by the physical space they share.

Role defines what a user can do in functional terms: approve timesheets, onboard workers, manage access cards. Most systems already model role reasonably well. The gap is not in role definition. The gap is that role ends at the organizational boundary, and the system has no mechanism for what happens when two organizations share a site.

Explicit policies

Policy is the concept most often absent. It governs the visibility and management rights that exist between actors from different organizations, without collapsing those organizations into a shared perimeter. A security firm needing to see which workers are on site is a policy question. The security supervisor role defines what supervisors can do inside their own organization. Policy defines what that supervisor can see in relation to workers from other organizations.

Party relationships define default administrative reach inside a vendor chain. Policies express the cross-boundary rules the business requires explicitly: extensions, limitations, and overrides that the relationship structure alone does not cover. Separating these three dimensions produces a cleaner domain language and enables safer defaults: the system denies cross-organizational access unless a policy explicitly grants it.

The three dimensions at a glance

In the production system we stress-tested, scope and organization are modeled separately. The location tree runs downward; admin and vendor assignments attach to scope levels beside the tree, not as children of it. Security Co. and Cleaning Co. appear at the same scope nodes (Logistic centers, POZ1). That overlap is exactly what scope alone cannot resolve.

Scope nodes (blue): location tree. Organization assignments (yellow): client admins and vendor admins attached to a scope level. Same scope, different organizations; the gap the three-dimension model is designed to close.

How an Access Decision is Evaluated?

Consider a security supervisor at a shared logistics site who attempts to view an active worker employed by a cleaning company. The request is not resolved by a single hierarchy check. Each dimension answers a separate question in sequence.

1. First, scope: both the supervisor and the worker operate within the same site. Scope alone would treat them as co-located actors with no further distinction. That check passes and stops short of granting access.
2. Second, organizational relationships: the supervisor’s organization and the worker’s employer are peer vendors. There is no Party Relationship between them and no administrative reach across that boundary. At this evaluation step, the default is deny.
3. Third, policy: the site requires security staff to maintain read-only visibility of all active workers on site, regardless of employer. A policy attached to that site grants exactly that visibility level: read-only, scoped to the site, with no management rights. The access decision is granted by policy, not by shared scope or organizational hierarchy.

This sequence is what a collapsed model cannot express cleanly. Scope says yes. Organization says no. Policy resolves the conflict with an explicit, auditable rule. That is the behavior multi-vendor facility platforms need by design, not as a growing list of exceptions.

How Does This Model Handle Contractors and Subcontractors?

The scenario below maps directly onto contractor and subcontractor relationships we encountered during the stress test. A client hires a service company for equipment maintenance. That company subcontracts HVAC work to a specialist firm. From the client’s perspective, one vendor relationship exists. The client does not need to manage the full subcontractor chain. The client retains the right to block any worker operating in their facility after a safety incident.

Three distinct relationships appear in this scenario:

• Client to service company: contractual, with override rights at the individual worker level.
• Service company to subcontractor: managerial, within the vendor hierarchy.
• Peer vendors to each other: a renovation firm and a cleaning firm both operate on the same site. Neither has management rights over the other.

All three vendor firms may share the same scope. The logistics center is their shared operational territory. Their organizational boundaries differ entirely. The cleaning firm and the renovation firm are peers: same scope, no management relationship. The service company and its HVAC subcontractor are in a parent-child relationship. The client sits above all of them with selective override authority.

Each relationship maps differently onto the authorization model. Same scope. Different organizational boundaries. Different policy rules.

In Party Pattern terms, the mapping is direct:

The cleaning firm cannot manage the HVAC subcontractor because there is no Party Relationship between them. That rule does not need to be encoded as a permission flag. It follows from the structure of the model. The Party Pattern is what makes that default-closed behavior explicit rather than accidental.

Without the Policy dimension, the system has no formal mechanism to express these distinctions. Developers either hard-code exceptions or leave the gaps unaddressed until onboarding pressure forces attention. This is where contractor management requirements routinely outgrow the current model, and where we identified the need to propose structural improvements before the next vendor contract exposed them in production.

What Does the Policy Dimension Actually Do?

Policy is the third authorization dimension. It governs specific visibility and management rights between actors from different organizations. Each policy is a Strategy in implementation terms: a named, interchangeable rule attached to a scope context and evaluated at runtime between a source organization and a target organization, actor, or resource. Each policy has four components: source organization, target organization or resource, access level, and scope constraint. The access level: read, manage, or none, is the core of what the policy grants or denies.

Where the Party Pattern defines the structure of organizational relationships, Policy defines the cross-boundary rules the business requires when structure alone is not enough.

Examples of what the Policy dimension can express:

• Grant: A security company can see all active workers on a site, regardless of their employer. The access level is read-only. The scope constraint is the site itself.
• Default deny: A cleaning company cannot manage security staff, even if both operate on the same floor. No policy exists between them, that absence is the rule.
• Structure suffices: A parent contractor can manage its subcontractors within the platform. That right follows from the subcontracting Party Relationship, no separate policy is required unless the business needs to limit or extend it.
• Override: The client’s contractual Party Relationship provides standing to block any individual worker in their facility. A policy defines what “block” means in practice, without granting visibility into the full subcontractor chain.

Role grants capability; Policy constrains or extends that capability across organizational boundaries. A user’s role defines what they can do in general. Policy defines what they can do in relation to a specific other organization or actor. This distinction reduces the pressure to create increasingly specific roles to cover relationship-based edge cases. A standard supervisor role handles the function. A policy handles the relationship. Role proliferation is a symptom of a missing Policy dimension.

Why Does Multi-Organization Access Control Go Beyond RBAC?

Role-Based Access Control (RBAC) handles uniform permissions well within a single organization. It answers one question clearly: what can a user with this role do inside their organization? It breaks down when the same role behaves differently depending on the organizational relationship between the actor and the subject. A supervisor at a subcontractor does not carry the same effective permissions as a supervisor at the client company. RBAC has no clean way to express that difference because it models only one of the three dimensions a shared facility requires.

Access decisions in a multi-vendor facility platform depend on three separate dimensions: where you operate, who you are relative to other organizations, and what explicit policies govern your visibility and management rights across those organizations. RBAC covers the role component of the second dimension. It does not address the first or third.

Attribute-Based Access Control (ABAC) and Relationship-Based Access Control (ReBAC) address adjacent parts of this problem. ABAC conditions access decisions on any attribute of the user or resource. ReBAC grounds access decisions in explicit relationships between entities. Either can complement the three-dimension model described here.

The appropriate approach depends on the domain. The decision is not which single model to use as a universal solution. The decision is which dimensions the system needs to express, and whether the chosen model can express them without collapsing them into each other.

What Does This Model Change in System Design?

Adopting this model has practical implications at the design level.

• Clearer domain language. Developers and domain experts share the same vocabulary. Scope, organization, role, and policy each carry a precise meaning. Conversations about requirements stop drifting between concepts.
• Safer defaults. Organizational boundaries are explicit. The system denies cross-organizational access unless a policy grants it. The default is closed. Access is a documented grant, not an assumed baseline.
• Fewer hidden permission leaks. Implicit access paths that exist because scope and organization were conflated are removed. Each cross-boundary rule has a name, an owner, and a documented rationale.
• Easier edge case reasoning. When a new scenario appears, the team asks which dimension it belongs to. That question guides the design rather than triggering a patch against the nearest available concept.
• Alignment with business relationships. The software model reflects the contracts, responsibilities, and hierarchies that exist between clients, vendors, and subcontractors in the real world.

This kind of model refactoring rarely fits a single sprint. It begins with naming the missing concepts clearly. Then it introduces those concepts into the domain model and access control implementation one at a time.

A practical starting point: audit the existing authorization model against the three dimensions. Identify where organizational boundaries are expressed only through scope or asset hierarchy. Identify where relationship-based rules are embedded in roles. For platforms handling contractor management at scale, that audit often surfaces more dimension collapse than anyone expected.

How We Stress-Tested the Authorization Model?

The three-dimension model described in this article did not emerge from a greenfield design exercise. It was the output of a structured stress test run against the authorization model of an existing production system, before the next wave of vendor onboarding made the gaps visible to end users.

We used an AI assistant as a reasoning partner for scenario generation, not as an architect. The engineer with domain knowledge of the client system posed the questions. The AI helped work through them systematically: What happens when a service company subcontracts to a specialist firm? What does the client retain authority to do without seeing the full chain? What can peer vendors never do to each other? What breaks when two organizations share a floor but have no contractual relationship?

Each scenario demanded a precise answer. Where the current model could not produce one, a missing concept appeared. Organization, scope, and policy all existed in practice but had not been separated formally. The Party Pattern was already the right structure for organizational relationships. It had simply not been named as such in the project. Naming these concepts was a prerequisite for proposing them correctly to the client.

The session resembled event storming with a smaller room: one domain model, one engineer, structured questions moving in one direction. The output was a glossary, named concepts, and a draft policy structure. That output became the input to a client conversation about targeted improvements, not an all-at-once rewrite proposal.

The value was not code generation. It was problem framing under pressure: surfacing where the current model would fail, documenting why, and arriving at a vocabulary the development team and the client could share. The experienced engineer remained the one deciding what made sense. The AI accelerated the scenario work that would otherwise require a larger workshop to cover in the same depth.

Closing: What is the Best Way to Model Access Control in a Shared Facility System?

Access control in shared facility systems cannot be modeled through location or asset hierarchy alone. Once multiple organizations operate in the same site, a single hierarchy produces leaks that cannot be patched with more roles or finer permission flags. The model needs three separate dimensions: operational scope to answer where, organizational relationships to answer who and what, and explicit policies to govern visibility and management rights across boundaries.

Policy is the dimension most often absent. Without it, cross-boundary rules live in undocumented exceptions and grow with every new vendor contract. With it, those rules become auditable, testable, and transferable to the next onboarding.

When a platform starts serving more vendors than its original authorization model assumed, the cost of reactive fixes grows with every onboarding. Stress-testing the model early, before permissions leak into production incidents, is often the difference between a patch and a sustainable improvement path. The investment in a precise, multi-dimensional authorization model pays increasing returns in safety, maintainability, and alignment with the business.

Working on a facility or multi-vendor platform where authorization requirements are outgrowing the current model? Contact us to discuss how we approach authorization modeling, including stress-testing existing designs, before the next vendor onboarding forces the issue.