Role-Based Access & Advanced Rule Capabilities

What roles allow

Each operator role can be configured to control:

• How and when the role is granted to an operator — either statically or based on the operator's attributes.

• The priority order in which role assignment rules are evaluated when multiple could apply.

• The set of users the operator holding this role is allowed to manage — its administrative scope.

Rather than assigning operator roles one by one, rule expressions let the system evaluate role membership automatically against directory attributes. A role can be granted dynamically when an operator matches a condition, and its scope — the population of end users the operator can act on — can be expressed using runtime placeholders that resolve to each candidate user's own attributes. This enables delegated administration over a precisely defined slice of your directory (for example: "Help-Desk operators in France can manage users in France").

Basic role information

Every role is described by the three attributes below. You'll want to decide a value for each before requesting role setup.

1. Role Name

2. Unique ID

3. Role Description

Advanced rule capabilities

The capabilities below move operator roles beyond static assignment. They let you define when an operator should automatically receive a role, and which users that operator is then allowed to manage — all driven by directory attributes.

4. Priority New

5. Role Mapping Rule New

Examples

{user.givenDisplayName} = "testUser"

({user.givenDisplayName} Equals "testUser" OR {user.country} equals "USA")

{user.givenDisplayName} contains "testUser"

// Complex expression combining AND with OR — parentheses make the grouping explicit:
(({user.givenDisplayName} Equals "testUser") OR ({user.country} equals "India"))
  AND
(({user.country} equals "USA") OR ("Argentina" equals {user.country}))

6. Scope Rule New

Examples

{users.givenDisplayName} = "testUser" OR {users.givenDisplayName} = "testing"

{users.group} = "Default Group_LOCAL"

"testUser@gmail.com" = {users.user_email}
  AND
{users.givenDisplayName} equals "testUser"

Rule expression syntax

Both Role Mapping Rules and Scope Rules share the same expression grammar. Knowing the small set of conventions below is enough to write any rule you will ever need.

Variables — the curly-bracket convention

Every reference to a user attribute is written between curly brackets, in the form {subject.attribute}. The brackets tell the rule engine that the value is to be resolved at runtime against directory data, not treated as a literal string. Anything outside curly brackets is a literal (typically a string in double quotes, or a logical operator).

Reserved keywords

Three keywords are reserved by the rule engine and must be used exactly as shown:

Special attribute: .group

Alongside the standard directory attributes (such as givenDisplayName, country, user_email), the engine exposes a special .group attribute on both user and users. It resolves automatically to the group(s) the user is a member of, based on the membership information Conductor already maintains — you do not have to import, sync, or hardcode group lists into the rule.

// Grant this role to any user who belongs to the Engineering group:
{user.group} = "Engineering"

// Operator can manage users who share their group membership:
{users.group} = {operator.group}

// Scope to a specific local group already known to Conductor:
{users.group} = "Default Group_LOCAL"

Operators, literals, and grouping

• Logical operators: AND, OR

• Comparison operators: equals (also written =), contains

• Literals: string values are written in double quotes (e.g. "USA"). Values inside { } are not literals — they are variable references.

• Nested attributes: dot notation is supported (e.g. {user.profile.country}).

• Grouping with parentheses: when an expression mixes AND and OR, you must use parentheses to make the evaluation order explicit. Ambiguous expressions are rejected.

Lifecycle & system behavior

A few system-level guarantees are worth knowing as you design your roles:

Atomic role removal with cascading cleanup

When a role is removed from your environment, the system performs the following in a single atomic transaction:

1. The role itself is removed.

2. Every Role Mapping Rule associated with the role is deleted.

3. Every Scope Rule associated with the role is deleted.

4. The priorities of all remaining roles are automatically re-adjusted to close the gap left by the removed role.

This guarantees there are no orphaned rules and that your priority sequence stays contiguous — no manual cleanup or renumbering is required.

Rule evaluation safety

Role Mapping Rules are re-evaluated whenever the user attributes they reference change. If an expression fails to evaluate for any reason, the failure is logged but does not block user operations — meaning a faulty rule cannot lock users out of the system.

Immutable identifiers

Once a role exists, its Role Name and Unique ID cannot be modified. Other attributes — priority, description, and the rule expressions — can be updated at any time.

Preparing rules for Axiad

Because Axiad configures operator roles in your environment on your behalf, the most efficient way to onboard or change them is to provide a complete specification per role. For each operator role you'd like created or updated, prepare the following:

1. Role Name — the human-readable display name (max 40 characters, alphanumeric / hyphen / underscore / space).

2. Unique ID — the stable machine identifier (max 45 characters, must be unique). Remember this cannot be changed later.

3. Role Description — a clear explanation of what the role is for (max 450 characters).

4. Priority — a non-negative integer if this role should participate in rule-driven assignment. Lower number = higher priority. Consider leaving gaps between values to allow future inserts.

5. Role Mapping Rule — the expression that automatically grants this role when a user matches. Max 1,000 characters. Define the rule that determines membership for this role.

6. Scope Rule (optional, for operator roles) — the expression defining which users an operator holding this role is allowed to manage. Max 1,000 characters.