Division Hierarchy Structure¶

RCX supports hierarchical division structures that mirror organizational hierarchies and enable sophisticated access control patterns.

Division Hierarchies¶

You can organize divisions hierarchically using the parent field, which references another division's ObjectId.

SP1 (Super Parent)
├── Site1
│   ├── Site1Sub1
│   └── Site1Sub2
└── Site2
    ├── Site2Sub1
    └── Site2Sub2
SP2 (Super Parent)
└── Site3
    ├── Site3Sub1
    └── Site3Sub2

Hierarchical Access Control¶

User access based on division position:

• Super Parent User (SP1): Can access all descendant divisions (Site1, Site1Sub1, Site1Sub2, Site2, Site2Sub1, Site2Sub2)
• Mid-Level User (Site1): Can access parent divisions (SP1) and child divisions (Site1Sub1, Site1Sub2) but not divisions in a sibling branch (Site2, Site2Sub1, Site2Sub2)
• Leaf User (Site1Sub1): Can access parent divisions (SP1, Site1) but not sibling divisions (Site1Sub2) or divisions in a sibling branch (Site2, Site2Sub1, Site2Sub2)

Table 1. Access Matrix by Entity Type

Policy and Segment Associations in Hierarchies¶

When divisions are organized hierarchically, the associations between reward policies, tier policies, and their related segments must follow specific validation rules to maintain consistency across parent-child relationships.

Depending on whether your policies span a single hierarchy or multiple hierarchies, segments and tier policies must meet different requirements to ensure proper data integrity. Understanding these association rules is critical for correctly configuring segments and tier levels within your hierarchical division structure.

Reward Policy/Rule Association with Segments¶

When working with hierarchical divisions, segment associations must follow specific rules:

Single-Hierarchy Associations:

• If a reward policy belongs to a single hierarchy (such as Child division), associated segments can belong to any level in that hierarchy (GrandParent, Parent, Child, GrandChildren)

Multi-Hierarchy Associations:

• If a reward policy has divisions from multiple hierarchies, every associated segment must include divisions from all represented hierarchies
• Segments belonging to only one hierarchy cause validation errors

Reward Policy divisions: [Child from Hierarchy 1, Child from Hierarchy 2]
Valid Segment: Must have divisions from both Hierarchy 1 AND Hierarchy 2
Invalid Segment: Has divisions from only Hierarchy 1 OR only Hierarchy 2

Tier Policy Level Associations¶

Similar rules apply to tier policy associations:

• Single-Hierarchy: Tier levels must belong to the reward policy's hierarchy
• Multi-Hierarchy: Tier policies must include divisions from all hierarchies represented in the reward policy

Activity Execution with Division Hierarchy¶

Activity processing respects the hierarchical division structure for enhanced flexibility:

Hierarchical Activity Execution:

• Users can execute actions on entities belonging to their division hierarchy (parent and child divisions).
• Activity location divisions are expanded to include the full hierarchy for validation.
• Program default divisions support hierarchy-based fallback assignment.

Division Evaluation Priority:

1. User's Active Division
2. Activity Location Divisions (expanded to hierarchy)
3. Program Default Division (expanded to hierarchy)

Enhanced RBAC + ABAC Enforcement¶

The system enforces both Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) simultaneously, where the attribute is a division.

Dual permission check:

1. RBAC Check: User's role must grant the required permission
2. Division ABAC Check: User's division must have the required permission flag set

Both checks must pass for the action to be allowed. If either fails, access is denied.

Division permission defaults:

{
  "read": true,
  "create": false,
  "update": false,
  "delete": false
}