Understanding Context-Based Person Relative Delegations
Person Relative Delegations grant access to all resources of a given type within a person's organizational scope—for example, managing all computers in the person's locations or viewing all mailboxes the person is responsible for. The resource scope adjusts automatically as the person's organizational assignments change.
Context-Based Person Relative Delegations use this same foundation but add a Business Role qualification. The delegation is configured to require that the person hold a specific Business Role within an Organization before they receive access to resources in that Organization. Only people who hold the qualifying Business Role receive the delegation, and because access is tied to Business Role assignments, it adjusts automatically when those assignments change.
Example: Your organization wants HR Managers to manage employee records, but only people who actually hold the HR Manager Business Role should have this access—not every employee in those locations. A context-based delegation grants access only to people assigned the HR Manager Business Role and adjusts automatically as role assignments change.
This article explains how context-based delegations work, when they are the right choice, and where they are not the right tool for the job.
Person Relative Delegations: The Foundation
A Person Relative Delegation grants access to all resources of a given type within a person's organizational scope, rather than to a specific list of resources. When configured as both Organization Relative and Location Relative, the delegation applies across all Locations within the Organization where the person is assigned. The resource scope is determined by where the person sits in the organizational structure, so as people move between Organizations or Locations, their access adjusts automatically.
Context-Based Person Relative Delegations add a Business Role qualification. The person must hold a specific Business Role within an Organization before receiving the delegation for resources in that Organization. Only people who hold the qualifying Business Role receive access, while preserving the person-relative characteristic that resources are determined by organizational position rather than explicit assignment.
How Context-Based Delegations Differ from Standard Delegations
Standard Organization and Location relative delegations apply to everyone within the organizational scope. Context-based delegations add a qualification: the person must hold a specific Business Role within that Organization before the delegation takes effect.
| Aspect | Standard Delegation | Context-Based Delegation |
|---|---|---|
| Who Gets Access | Everyone within the organizational scope | Only people who hold the specified Business Role |
| Access Lifecycle | Persists until manually removed | Follows Business Role assignment changes automatically |
| Scope | All Locations within the Organization | All Locations within Organizations where the person holds the qualifying Business Role |
| Best For | Uniform access across the organization | Role-driven access that should vary by assignment |
Use standard delegations when everyone in the organizational scope should have the same access and requirements do not vary based on role assignments.
Use context-based delegations when access should be restricted to people who hold a specific Business Role, you want access to follow role assignments automatically, or you need to avoid maintaining large numbers of individual delegations as people change roles.
Business Roles as Context Qualifiers
The qualifying condition in a context-based delegation is always a Business Role. Business Roles represent job functions or titles within your organization—for example, HR Manager. A person holds a Business Role at a specific Location, and that assignment is what the system checks when determining whether the delegation applies to them. If the person holds the specified Business Role within an Organization, they receive the delegation for resources within that Organization.
Understanding this is important because it shapes how you think about configuring these delegations: you are not defining who gets access by name or by group, but by the job function they hold and where they hold it.
How Context-Based Delegations Work
When evaluating whether a person should receive a context-based delegation, the system works through three questions in sequence.
Does this person hold the required Business Role anywhere in the system? If the person has no assignment to the qualifying Business Role at any Location, the delegation does not apply to them.
In which Organizations does this person hold that Business Role? Business Role assignments are made at specific Locations. Each Location belongs to a parent Organization. The system identifies all Organizations where the person holds the qualifying Business Role.
What resources exist within those Organizations? The system finds all resources of the delegated type across all Locations within the matching Organizations and grants the delegation for all of them.
The Organization boundary is a critical characteristic of how this works. The Organization is never stored on the delegation definition itself—it is derived from where the person holds the qualifying Business Role and where the target resources exist. The Organization where these two factors intersect is where the delegation applies. This means a person holding a Business Role in one Organization receives access only to resources within that Organization's Locations. Holding the same Business Role in a second Organization would independently extend access to that Organization's resources.
To see how this plays out in practice, the following example walks through a complete scenario.
Example: HR Manager Access
Organization structure:
- Meridian Corporation
- North America Division — Locations: Chicago, Toronto, Mexico City
- Europe Division — Locations: Amsterdam, Madrid, Warsaw
Business Role: HR Manager
People:
- Sarah Okafor — HR Manager at the Chicago Location (within North America Division)
- David Reyes — Standard Employee at Madrid (no HR Manager role anywhere)
Delegation configured: HR Managers can manage Person resources, configured as both Organization Relative and Location Relative, with context qualifier: HR Manager Business Role.
How the system resolves this:
The system checks Sarah's Business Role assignments and finds HR Manager at Chicago. Chicago belongs to North America Division, so the system records Sarah as holding HR Manager context within North America Division. The delegation requires HR Manager context, Sarah qualifies within North America Division, and Person resources exist in Chicago, Toronto, and Mexico City—all within that Division. Sarah receives the delegation for all three Locations.
David holds no HR Manager assignment anywhere, so the delegation does not apply to him.
Result:
| Chicago | Toronto | Mexico City | Amsterdam | |
|---|---|---|---|---|
| Sarah Okafor | ✅ | ✅ | ✅ | ❌ |
| David Reyes | ❌ | ❌ | ❌ | ❌ |
Sarah cannot access Amsterdam because that Location belongs to Europe Division, where she does not hold the HR Manager Business Role. If Sarah is later assigned HR Manager at the Amsterdam Location, access to Europe Division resources is granted automatically. If her Chicago assignment is removed, access to all North America Division resources is revoked automatically—no delegation changes are required.
When Context-Based Delegations Do Not Apply
Context-based delegations qualify who receives a delegation based on their Business Role. They do not control where a delegation applies within a Location hierarchy. These are different problems that require different solutions.
If your requirement is to prevent a delegation from reaching specific Locations—for example, applying a delegation to all child Locations except those of a particular type—context-based delegations cannot solve this. The context mechanism evaluates the Organization as a whole and qualifies people within it; it has no way to filter which Locations within that Organization the delegation reaches, and it cannot express exclusions at the Location level.
When you need to control which Locations inherit a delegation, use the Block Inheritance setting available on each Location. When Block Inheritance is enabled on a Location, that Location does not inherit delegations from its parent. This allows you to delegate at a high level and selectively exclude specific Locations by enabling Block Inheritance on them. Note that the Block Inheritance setting applies to all parent delegations at once. For scenarios that require blocking specific delegations while allowing others at the same Location, contact your implementation team.
Related Topics
- Standard Person Relative Delegations — Applies permissions to all resources of a type within a person's organizational scope without Business Role qualification. Use when access should be uniform rather than role-driven.
- Business Roles — Understand how Business Roles represent job functions and how assignments work before configuring context-based delegations.
- Block Inheritance — Prevents specific Locations from inheriting delegations from parent Locations. Use this when the requirement is Location filtering rather than person qualification.
Next Steps
Before configuring context-based delegations in your environment:
- Confirm that Business Role assignments are correctly in place for the people who should receive the delegation
- Identify the specific Business Role that will serve as the context qualifier
- Verify that the target resources are organized within Locations belonging to the appropriate Organizations