Permission Types
Permissions in High Systems are configured on a role and applied per table and per field. This reference lists every permission option, where it lives, and what it controls.
Managing roles requires an application where your role has admin access. The same permission model backs the REST API; see the Roles endpoint reference.
Role flags
Set in the role editor's General Settings:
| Option | What it controls |
|---|---|
| Is Admin | Full application administration: all settings, roles, and users |
| Is Limited Admin | Limited administration, scoped to tables and fields the role already has access to; cannot manage roles or grant itself new access |
| Can Invite | Adds and removes application users |
| Read Only | Blocks creating, editing, and deleting records anywhere in the application, and hides the application's Import option |
| Enable Application Searches | Shows the Application tab in the global search palette |
| Default Dashboard | The dashboard shown when a user with this role opens the application (required) |
| Role Menu | The navigation this role sees: Application Default or a specific menu (required) |
Table permissions
Configured per table in the role editor's Table Permissions panel. All switches are disabled until Has Access is on; when Has Access is off, all access to the table is denied regardless of the other settings.
Permissions card
| Option | What it controls |
|---|---|
| Has Access | Master switch for the table |
| View Records | The role can see records |
| Add Records | The role can create records |
| Edit Records | The role can modify records |
| Delete Records | The role can remove records |
| Create Common Reports | The role can create reports on this table that other users can use |
| Access Table Settings | The role can open Table Settings and customize forms and dashboards for the table |
| Manage Permissions | The role can manage permissions for the table |
Record-level conditions
View Condition, Edit Condition, and Delete Condition (next to their switches) are query-builder conditions that scope the permission to specific records. A view condition is applied to every list, report, and search for the table; edit and delete conditions show or hide each record's buttons. Leave a condition empty to allow all records the other switches permit.
User Interface card
| Option | What it controls |
|---|---|
| Default Dashboard | The dashboard used when the role opens this table; Table Default defers to the table's own setting |
| Default Form | The form used when the role opens a record; Table Default defers to the table |
| Allow Imports | The role can use bulk data import |
| Show Search | The role can use Simple Search and Advanced Search on this table |
| Hide Add, Hide View, Hide Edit, Hide Copy, Hide Delete | Hide the corresponding record buttons. These hide buttons only; the underlying permission still applies, so turn off the switch itself to actually deny an action |
Field permissions
The Field Permissions grid appears below the cards for the selected table. Each field has four toggles:
| Option | What it controls |
|---|---|
| Has Access | When off, the field is removed entirely for this role: it won't appear in lists, reports, or record payloads |
| View | The field's value is visible |
| Add | The role can populate the field on new records |
| Edit | The role can change the field on existing records |
There is no per-field delete or per-field condition; record-level conditions live in the Permissions card.
Data Rules
Data Rules live on the table itself, not the role: Table Settings → Properties → Advanced Settings. A Data Rule is an SQL formula evaluated per record at the database level; if it doesn't return true, the operation is rejected with the rule's message. Because it runs in the database, it constrains every path into the table, including the REST API, unlike role permissions which are scoped by role.
Test as Role
Administrators and Limited Admins can preview any role's view of the application: open the user menu (top-right) and choose Test as Role. The session switches to the selected role; the header shows the impersonated role with an End Test button to switch back. Admin and Limited Admin roles can't be tested by non-admin users.
Public Role
The Public Role setting (Application Settings → Properties) assigns anonymous visitors to a role, opening the application to anyone on the internet without signing in. Guards apply: the public role cannot be an Administrator or Limited Admin, cannot invite users, and cannot have table settings or permission-management access.
How permissions appear
Permissions mostly work by making things disappear rather than showing errors: menu items, buttons, and tabs the role can't use aren't rendered, and record buttons appear only where conditions allow. A request that reaches a restricted action anyway (for example through the REST API) is rejected with "You do not have permission to perform this action."