Permissions

Roles are how you control what users can see and do in a High Systems application. Each application defines its own roles, you assign exactly one role per user, and each role decides what that user is allowed to access at the application, table, record, and field level.

Where roles and users live

Open Application Settings and look at the Access panel. It has two sections:

• Roles (Settings → Roles): where you create roles and configure permissions.
• Users (Settings → Users): where you invite people to the application and assign each of them a role.

You can also reach both from the left navigation: hover any menu item, click its cog icon, and choose Settings.

Built-in roles

Every new application comes with four roles:

Built-in roles are ordinary roles: you can edit or delete them like any other. The person who creates an application is added to it as an Administrator.

Creating a role

Click Add Role (or open an existing role from the Roles list) to open the role editor. It has two parts: General Settings at the top and, in edit mode, the Table Permissions panel below.

General Settings

• Role Name (required) and Description.
• Is Admin: grants full application administration (see Built-in roles above).
• Is Limited Admin: grants limited administration, scoped to tables and fields the role already has access to (see Built-in roles above).
• Can Invite: allows this role to add and remove application users.
• Read Only: blocks this role from creating, editing, or 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 for users with this role.
• Default Dashboard (required): the dashboard shown when a user with this role opens the application. See Which dashboard is used.
• Role Menu (required): the navigation menu this role sees. Choose Application Default to use the application's own menu, or pick a specific menu to give the role a custom navigation.

Table permissions

Select a table in the Table Permissions list (use Search Tables... to filter) to see three cards for that table.

Permissions

The core access switches for the table:

• Has Access: master switch. When off, all access to this table is denied regardless of the other settings, and every other toggle is disabled.
• View Records: lets the role see records.
• Add Records, Edit Records, Delete Records: lets the role create, modify, and remove records.
• Create Common Reports: lets the role create reports on this table that other users can use.
• Access Table Settings: lets the role open Table Settings and customize forms and dashboards for the table.
• Manage Permissions: lets the role manage permissions for the table.

Record-level conditions

Next to View, Edit, and Delete you'll find View Condition, Edit Condition, and Delete Condition: query-builder conditions that scope the permission to specific records. For example:

• A View Condition of status = 'published' means the role only sees published records; the condition is applied to every list, report, and search for that table.
• An Edit Condition like recordOwner = currentUser() means users can only edit records they own. Each record's Edit and Delete buttons appear or disappear based on these conditions.

Leave a condition empty to allow all records the other switches permit.

User Interface

These settings shape what the role's interface looks like on the table:

• Default Dashboard: the dashboard used when the role opens this table's homepage. Choose a table dashboard or Table Default to defer to the table's own default.
• Default Form: the form used when the role opens a record. Choose a table form or Table Default.
• Allow Imports: lets the role use bulk data import.
• Show Search: lets the role use Simple Search and Advanced Search on this table.
• Hide Add, Hide View, Hide Edit, Hide Copy, Hide Delete: hide the corresponding record buttons.

Field Permissions

The Field Permissions grid controls access per field: for each field in the selected table, toggle Has Access, View, Add, and Edit.

• Turning off Has Access removes the field entirely from the role, so it won't appear in lists, reports, or record payloads.
• Turning off View hides the field's value from this role; Add and Edit control whether the role can populate it on new or modified records.

Assigning users to roles

Go to Settings → Users to see everyone with access to the application. The list shows each user's name, email, Role, last activity, and Active status (which you can toggle directly in the list).

• Add User: enter an email address and a role. If the person doesn't exist on the instance yet, High Systems creates the account and sends them an invitation (you can turn off Send Email).
• Add Users: add several people at once, choosing a role for each.
• Each user has exactly one role per application. To change what someone can do, edit their role on this screen.
• Delete a user removes them from the application (their instance account remains). The confirmation requires typing delete user.

Users whose role has been deleted appear as Unassigned: they can't invite anyone and are treated as read-only until you assign a new role.

Public Role (anonymous access)

In Application Settings → Properties, the Public Role setting assigns the anonymous user to a role, opening the application to anyone on the internet without signing in. High Systems guards against overly permissive settings here: 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 to users

Permissions mostly work by making things disappear rather than showing errors:

• Menu items, buttons, and tabs the role can't use simply aren't rendered.
• Record rows show Edit and Delete buttons only where the record-level conditions allow them.
• Search icons and search tabs appear only for tables where the role has search access.
• If a user does hit a restricted action anyway (for example, by calling the REST API directly), the request is rejected with an error: "You do not have permission to perform this action."

Testing a role

To see exactly what a role looks like in practice, open the user menu (top-right) and choose Test as Role. Pick a role and your session is switched to it; the header shows the impersonated role with an End Test button so you can switch back when you're done.

Deleting a role

Open the role and click Delete. You'll need to type delete role to confirm. Deleting a role doesn't delete users: anyone assigned to it becomes Unassigned, so reassign them afterwards.

There is no duplicate action for roles; create new roles with Add Role.

What's next?

The menus, dashboards, and tables your roles see are built in the guides below:

• Manage your application and its settings
• Learn how to build dashboards
• Learn how tables and records work