--- title: Access Rights Strings slug: access-rights-strings createdAt: 2025-11-30T21:49:33.332Z --- 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.