Grant a role
Updated
Give a login a named set of grants: which documents and dictionaries they may touch, which buttons they may press, and which named capabilities they hold.
Note
An object with no grant rows is open to any signed-in caller. The first Allow (or Revoke) on that object closes it: after that, the caller needs a role that is granted. A command with no Execute row is the same trap — the button is not a gate until you grant Execute. Named capabilities Admin and Developer are the opposite: nobody holds them until you grant Hold. You need the Administrator ribbon to do this work.
How to#
To grant a role, open Ribbon → Administrator → Access → Roles. If Administrator is not on the ribbon, this login does not hold Admin.
Press New. The New role window opens. Fill Name (required). Description can wait. Press Save. The toast Role created appears, and the role is in the list.
A folder is a different button. Press Folder. The window title is New folder. Save then toasts Folder created. Use a folder to group the tree, not to grant rights.
Open the role (double-click or edit). The editor title is Role: plus the name. Across the top: Roles, Documents, Dictionaries, Commands, Totals, Permissions, Row security, Printers, System.
On Documents, each object is a row. Columns are Read, Create, Update, Delete, Post. On Dictionaries the columns are Read, Create, Update, Delete. Click a cell. The menu is Allow, Revoke, Clear. A green check is this role's own allow. A pale check is inherited. Revoke is an explicit deny. Clear removes this role's own row so a parent can show through again. The All column applies Allow all, Revoke all, or Clear all to every operation of that object. A cell change is stored when you pick the menu item — you do not press the header Save for it.
On Commands, family sub-tabs are Dictionary commands, Dictionary list commands, Document commands, Document list commands, User commands, and Global commands. The operation on each is Execute. Until some role has an Execute row on that command, every signed-in caller can press the button. Grant Execute for each role that should press it, or the button is not a gate.
On Permissions, the operation is Hold. Find Access families / Admin and Access families / Developer. Allow Hold on Admin before that role can see Administrator. Allow Hold on Developer before it can see Developer. Until you grant them, those tabs stay hidden — unlike an empty document or dictionary matrix.
On Roles, set Inherits from roles (a multi-select). This role gets what its parents may do and adds its own; its Revoke cuts an inherited allow. An explicit deny on the caller's own role wins even if another role they hold grants. Press Save in the header after you change the parents. The toast is Role saved.
Users on that same tab is a list, not an editor. Empty text is No users hold this role. You do not add members here.
To assign the role, open Ribbon → Administrator → Access → Users. Open the user. In Roles, pick the role. Press Save. The toast User saved appears. Open the role again: that login is listed under Users.
On Row security, no predicate means the role sees every row. The hint is Restrict which rows of an object this role may see or edit. No predicate = the role sees all rows. Press Add predicate, pick Object type and Object, fill Expression, press Save. The toast is Predicate saved. Tokens on that tab lists @currentUserId and @currentUserName; click a token to append it. The expression box suggests [Name] = @currentUserName. Do not write SQL.
The built-in Administrator role is marked System on the list. It is the superuser: it bypasses the permission model. You cannot delete it. Name and Description on that role are locked.
Three more system roles ship on every stand for the phone: Agents (Sales agent), Sales managers (Sales manager), and Warehouse (Storekeeper). Each already has Mobile app view and Allow cells on the dictionaries, documents, and document commands that view uses. Warehouse also has the office stock documents (goods issue, transfer, adjustment, count). Five more system roles cover the office: Sales, Purchasing, Accountant, HR, and Production. Assign the role to the login; do not recreate it. Those Allow cells are the first rows on those objects, so a login that is in none of them (and is not a superuser) loses office access to them too.
Example
Open the purchaser user:
- Roles Purchasing
Save. The role's Roles tab lists that login.
Tip
The first Allow on an object that was empty locks every other signed-in caller out of that object until you grant their roles too. Grant Execute on a command in the same pass, or the button stays open to everyone. Admin and Developer never fail open.
If the command refuses#
| What you see | What to do |
|---|---|
| Administrator is not on the ribbon | This login does not hold Admin. Sign in as a member of Administrator, or have that login Allow Hold on Access families / Admin. |
| Role name is required | Fill Name, then Save. |
| No users hold this role. | That is the empty list, not an error. Assign the role on Ribbon → Administrator → Access → Users, then Save the user. |
| Pick an object. | Pick Object on the predicate, then Save. |
| Expression is required. | Fill Expression. Use a token from Tokens. |
| Could not save the predicate | The expression did not validate. Use the tokens on the tab. Do not write SQL. |
| Approve order is missing for a login after you granted Execute to someone else | Grant Execute on that command for this role too. Until the first Execute row existed, the button was open to everyone — Approve a purchase order. |
| Role not found. | The role is gone after a refresh. Return to Roles and open it again. |
See also
- Approve a purchase order
- Invite someone — Lifecycle Portal roles, not this ribbon
- Install the phone app
- Permissions
- Work with a list