Access Rights Strings
Access rights strings are used throughout Activate to express permission checks in a compact, declarative way. They are evaluated by the Activate security engine against access control entries (ACEs) defined on products, objects, and their parents.
A common usage of access rights string is on the AccessRights property of toolbars, so specific buttons only appear when the specified criteria is met. Great for cases like the owner of this service is allowed to unpublish the service, but only if they are the owner.
This guide explains the supported syntax, how expressions are evaluated, and the common pitfalls to avoid when writing access rights strings.
Basic access rights
The examples in this document use Service permissions for simplicity. Other object types in Activate support different sets of permissions.
An access rights string always uses the permission code, not the display name shown in Activate Studio.
Standard rights:
- CREATE (Create)
- READ (Read)
- WRITE (Write)
- DELETE (Delete)
- MANAGE (Manage)
Service-specific rights:
- USE (Use Service)
- ADD (Add User to Service)
- VIEW (View Instance)
- IUPD (Update Instance)
- IDEL (Delete Instance)
If an ACE grants Full Control, all standard and service-specific rights automatically match.
Combining rights
Access rights strings support two combination operators with very different behaviour.
Semicolon (;) — AND semantics
Use a semicolon to require that all listed rights must be granted.
When a semicolon is used, the expression is evaluated as a logical AND.
Example:
IDEL;IUPD
Meaning:
- The user must have IDEL
- AND the user must have IUPD
If any one of the rights is missing, the check fails.
This form is commonly used when an operation genuinely requires multiple permissions at the same time.
Pipe (|) — OR semantics
Use a pipe character to indicate that any one of the listed rights is sufficient.
When a pipe is present anywhere in the string, the expression is evaluated as a logical OR.
Examples:
IDEL|IUPD
IDEL|IUPD|MANAGE
Meaning:
- The user may have IDEL
- OR IUPD
- OR MANAGE
Only one matching right is required for the check to succeed.
Important difference between ; and |
Although both operators appear similar, they are evaluated very differently.
- Semicolon (;) expressions are evaluated together as a single AND group
- Pipe (|) expressions are split first and evaluated as independent OR options
This means the following are not equivalent:
IDEL;IUPD
IDEL|IUPD
The first requires both rights. The second requires only one.
Order of rights
The order of rights in the string does not affect the result.
Examples:
IUPD;IDEL
IDEL;IUPD
These evaluate identically.
The same applies to pipe-based expressions:
IUPD|IDEL
IDEL|IUPD
Owner, self, and target modifiers
Some rights may be qualified with modifiers that restrict when they apply.
Supported modifiers include:
- +SELF
- +OWNER
- +TARGET
Examples:
IUPD+OWNER: User must have IUPD and be an owner of the object, non-owners with IUPD will return false:
ADD+SELF: User must have ADD and be ordering for themselves.
These modifiers are evaluated as part of the right name and must match the ACE configuration exactly.
If a modifier is present:
- The ACE must be defined with the corresponding scope
- The context object must satisfy the condition (for example, the user must be the owner)
Unsupported separators
Commas (,) are not valid logical separators for access rights.
Example:
IUPD,IDEL
This is treated as a single literal right name and will not match IUPD or IDEL individually.
Always use:
- ; for AND
- | for OR
Worked examples
The following examples illustrate how to write access rights strings and how they are evaluated.
Each example shows:
- The configured security on the object (ACEs)
- The users and their relevant role or ownership context
- A series of access rights strings and the expected results
Example 1 — Service Desk and owner (Service)
Configured security on the object
Object: Service "Adobe Acrobat"
Local ACL (top to bottom):
- Allow ROLE: Service Desk → Full Control
- Allow ROLE: Administrators → Full Control
- Allow OWNER → VIEW, IUPD, IDEL
Users
- Jamie: member of Service Desk
- Wendy: owner of the service
- Alice: member of Administrators
- Bob: standard user with no special roles
Expected outcomes
User | VIEW | IUPD | IDEL | IDEL;IUPD | IDEL+OWNER |
|---|---|---|---|---|---|
Jamie | ✅ | ✅ | ✅ | ✅ | ❌ |
Wendy | ✅ | ✅ | ✅ | ❌ | ✅ |
Alice | ✅ | ✅ | ✅ | ✅ | ❌ |
Bob | ❌ | ❌ | ❌ | ❌ | ❌ |
Example 2 — Extended rights (USE)
Configured security on the object
Object: Product feature "Customer Portal" (illustrative)
Local ACL:
- Allow ROLE: Portal Users → VIEW plus special right [USE]
- Allow ROLE: Administrators → Full Control
Users
- Jamie: member of Portal Users
- Wendy: owner of the service
- Alice: member of Administrators
- Bob: standard user with no special roles
Expected outcomes
User | USE | VIEW | IUPD | USE;VIEW | USE;IUPD |
|---|---|---|---|---|---|
Jamie | ✅ | ✅ | ❌ | ✅ | ❌ |
Alice | ✅ | ✅ | ✅ | ✅ | ✅ |
Bob | ❌ | ❌ | ❌ | ❌ | ❌ |
Summary
- Access rights strings use permission codes, not display names
- Standard and service-specific rights are evaluated uniformly
- ; means all rights are required (AND)
- | means any one right is sufficient (OR)
- Commas are not valid separators
- Modifiers such as +SELF and +OWNER further constrain matching
Understanding these rules is essential to writing predictable and secure access checks in Activate.