Role-Based Security

Role-based security in Essembi is managed at the team level. Each user in an app belongs to a team, and that team’s rights determine what the user can see and do. Teams can be granted access to workspaces, views, forms, data models, tables, teams, users, and related system areas.

Use this guide to understand the security layers, adjust access rules, validate effective permissions, and apply complementary view-only and form scripting controls.

Security Layers

Essembi security is layered. Users often need the right combination of access across layers:

Workspace — Which workspaces (and the views inside them) a team can see or edit. This is the navigation and layout layer.
View — Access to a specific view inside a workspace. Use this when a team should see only certain views, not every view in the workspace.
Data Model — Whether a team can access the data model behind views and forms. Workspace or view access alone is not enough without data model View All or View Specific.
Table — Table configuration and data entry (open forms, enter data, edit form layouts). This is the data layer.
Form — Creating/editing form designs and opening forms to enter data.
Teams and Users — Who can create and maintain teams and users.
Settings and system areas — Controlled by the team’s Access Settings flag plus Create / Edit All / Edit Specific rights for each settings area (API keys, properties, integrations, automations, data imports, input devices, and more).

Practical example: To open a sheet and edit records, a team typically needs:

Workspace access (View All, View Specific, or Manager) or View Specific on that view
Data Model View All or View Specific for the model behind the view
Table Enter Data (or broader table rights) when creating or editing records
The view’s Data Editing setting must allow editing for that team (see Sheet View-Only Security below)

Levels of Security

Most object types use a consistent set of access levels:

Create — Create new objects of that type.
Edit All — Edit every object of that type, and manage security options that apply to “all” objects.
View All — See every object of that type (used for workspaces and data models).
Edit Specific — Edit one specific object (and usually manage that object’s security).
View Specific — See one specific object only.

Specialized levels include:

Workspace - Manager — Manage that workspace.
View - Edit Data — Edit data inside a view when Data Editing is set to Security Controlled.
Table - Enter Data for All / Enter Data / Edit Form Layout — Broad or specific rights to enter data and maintain form layouts.
Form - Enter Data — Open a form to create or edit records.

As a rule: All rights are app-wide; Specific rights limit access to one object. Grant the narrowest access that still lets the team do their work.

Also separate these ideas:

See a view — Workspace / View / Data Model view rights
Edit the view’s configuration — View Edit Specific (or broader workspace edit rights)
Edit data shown in the view — Table/form enter-data rights plus the view’s Data Editing setting

Sheet View-Only Security (Data Editing)

Sheet (and other editable) views have a Data Editing setting on Edit View. This controls whether users can change data in the sheet, independent of whether they can open the view.

Data Editing options:

Editable — Users who have the required table/form data rights can edit records in the view (inline sheet editing, add row, and related edit actions, subject to normal table security).
Read Only — The view is view-only for everyone. Users can open and review data, but cannot edit content in the view. Use this for reporting sheets, shared readouts, or any sheet that should never be an edit surface.
Security Controlled — Editing is allowed only for teams granted View - Edit Data on that specific view. Teams without Edit Data can still open the view (if they have view access) but cannot edit data in it.

How to set view-only on a sheet:

Open the sheet view.
Use the view settings menu and select Edit View.
Set Data Editing to Read Only for a fully view-only sheet, or Security Controlled when some teams should edit and others should only view.
If using Security Controlled, open the view’s security icon and grant Edit Data only to the teams that should edit.
Validate with a user on each team, and confirm the team’s effective rights in View Access.

Notes:

Chart views are always read-only for data content.
Read Only / Security Controlled controls data editing in the view. It does not replace workspace, view, data model, or table access required to open the view or launch forms.
A team can have permission to open a form for a table while still being blocked from inline edits on a Read Only sheet of that same data.

How to Adjust Security Rules

Open the object’s security settings. On objects you can administer, a security icon appears in the top-right. Select it to open the role-based security matrix for that object or record.
Read the matrix. Teams are listed down the left. Permission types for that object are listed across the top.
Grant or remove access. Use the checkboxes to turn permissions on or off for each team. Changes apply to every user on that team.
Understand Edit All vs Edit Specific while editing security. If you only have Edit Specific for that object type, checkboxes that affect “all” objects of that type are disabled. You can still set access for the specific object you opened.
Use workspace vs view grants intentionally.
- Grant workspace View All / View Specific / Manager when the team should see every view (or manage the whole workspace).
- Grant View Specific on individual views when the team should only see selected views.
Remember the data model layer. After granting workspace or view access, also grant Data Model View All or View Specific so the team can use the views/forms tied to that model.
Grant table/form data rights for data entry. To create or edit records, grant the appropriate Form Enter Data and/or Table Enter Data rights.
Set sheet Data Editing when the view should be editable, read-only, or editable only for selected teams.
Save and continue. Confirm your changes so the team’s effective access is updated.

Team-level flags that are not part of the object matrix:

Access Settings — Allows the team into the settings menu. Individual settings areas still require Create / Edit All / Edit Specific for that area.
Save Filters for Everyone — Allows the team to save view filters for all users, not only themselves.

How to Validate Rules with View Access

After you change security, validate the team’s effective rights using the View Access button on the team form (Settings → Teams → open the team).

View Access shows every permission that applies to the team, including rights inherited from a parent team. Use it to confirm:

The team has the access you intended
Access is not missing at a required layer (for example, view access without data model access)
Whether a right was granted directly on this team or came from a parent team
For Security Controlled sheets, that View - Edit Data is present only for teams that should edit

The View Access report includes:

Object Type — The securable area (workspace, view, table, data model, and so on).
Object Name — The specific object when access is specific; blank for app-wide “all” grants.
Access — The permission granted (Create, Edit All, View Specific, Edit Data, Enter Data, and so on).
Allowed — Whether that permission is currently allowed.
Team — The team the right comes from (this team, or a parent team when inherited).
Granted — When the access record was granted.

Recommended validation flow:

Adjust security on the relevant workspace, view, data model, table, or form.
Set or confirm the view’s Data Editing mode.
Open the team and select View Access.
Confirm each required layer appears with the expected access.
Have a user on that team sign in (or refresh) and verify they can reach only the intended workspaces, views, and edit actions.

Field-Level Visibility and Disable Scripting (Hidden When)

Role-based security controls who can open objects and enter data. Form scripting can further control what appears or is editable on a form for a given record and user.

On data entry form fields and buttons (in the form designer object settings), use Hidden When to conditionally hide a control.

Hidden When — A JavaScript expression/script that evaluates to true when the field or button should be hidden. Typical uses: hide fields that do not apply based on status, type, or other record values; hide actions a user should not see for the current record.

Hidden When scripts can use the available scripting context (commonly record and user) to make decisions. Example patterns:

Hide a field when a status is not “Approved”
Hide a button unless the current user is the assignee
Hide advanced options until a prerequisite field is filled

Related conditional behavior:

Some system/module fields also support conditional enable/disable behavior (enabled only when a condition is met). That keeps a field visible but not editable.
Custom buttons can combine Hidden When with click scripts so actions only appear when they are valid.
Chart buttons can also use Hidden When to control when actions appear on chart views.

How this fits with role-based security:

Use teams and object security to control who can open a form, view, or table.
Use sheet Data Editing to make a whole view editable, read-only, or security-controlled.
Use Hidden When (and related enable/disable rules) for record- and user-specific UI inside a form the team is already allowed to open.

Hidden When is not a substitute for denying Form Enter Data or Table Enter Data. A determined user with enter-data rights may still reach data through other allowed paths (other forms, sheets, imports, or API) unless those paths are also secured.

Security Items by Object

A security icon appears in the top-right of objects when a user has Edit All or Edit Specific access. Selecting it opens the security settings for that object.

Workspaces

Workspace - Create: Create new workspaces.
Workspace - Edit All: Edit workspaces and the views contained in the app.
Workspace - View All: See all views in the app’s workspaces.
Workspace - Edit Specific: Edit this workspace and the views inside it.
Workspace - View Specific: View this workspace and the views inside it.
Workspace - Manager: Manage this workspace.

To view a workspace, a team needs View All, View Specific, or Manager at the workspace level, or View Specific at the view level. That lets administrators grant access to every view in a workspace or only selected views.

Views

View - Edit Specific: Edit the specific view’s configuration.
View - View Specific: See the specific view.
View - Edit Data: Edit data in the view when Data Editing is set to Security Controlled.

Teams must also have Data Model View All or View Specific to use a view based on that data model. For sheet view-only behavior, see Sheet View-Only Security (Data Editing) above.

Forms

Form - Create: Create new forms.
Form - Edit All: Edit all forms.
Form - Edit Specific: Edit a specific form.
Form - Enter Data: Open the form to create or edit records.

Inside forms, use Hidden When scripting to conditionally hide fields and buttons for additional, record-aware control.

Data Models

Data Model - Create: Create new data models.
Data Model - Edit All: Edit all data models.
Data Model - Edit Specific: Edit a specific data model.
Data Model - View All: Access all data models through views or forms.
Data Model - View Specific: Access views or forms for this data model.

Tables

Table - Create: Create a new table.
Table - Edit All: Edit all table configurations.
Table - Edit Specific: Edit a specific table configuration.
Table - Enter Data for All: Enter data across tables (also covers form layout and enter-data rights where applicable).
Table - Edit Form Layout: Edit form layouts for this table. Also granted with Enter Data for All.
Table - Enter Form Data: Open a data entry form for this table. Also granted with Enter Data for All.

Teams

Teams - Create: Create new teams.
Teams - Edit All: Edit all teams.
Teams - Edit Specific: Edit a specific team.

Users

Users - Create: Create new users.
Users - Edit All: Edit all users.
Users - Edit Specific: Edit a specific user.

Other Securable Areas

Depending on your app, teams may also receive rights for:

API Keys — Create and manage API access
Properties — Edit app properties
Integrations — Manage integrations
Automations — Create and edit automations
Data Imports — Create, edit, and run imports (including run-all / run-specific)
Input Devices — Create and edit input devices
Published Dashboards — Access related to published dashboards

These areas still require Access Settings to appear in the settings menu, plus the matching Create / Edit rights for that area.

Security for Settings

Access to the settings menu is controlled by the Access Settings flag on the team.

Once a team can open Settings, each settings menu option appears only if the team also has Create, Edit All, or Edit Specific for that record type.

Security Inheritance by Parent Team

Child teams inherit security from parent teams for items that are not explicitly set on the child team. Explicit child-team settings take precedence for that item. View Access shows which team each right comes from, so you can tell inherited access from direct grants.

Use parent teams for shared baseline access (for example, “all employees can view Operations”), then tighten or extend rights on child teams.

Security for Filters

Whether users can save view filters for everyone (versus only for themselves) is controlled at the team level. Enable Save Filters for Everyone for teams that should publish filters to all users.

Recommended Setup Pattern

Create teams that match real job roles (Administrators, Supervisors, Operators, Read-Only, and so on).
Assign each app user to the correct team.
Grant workspace and/or specific view access for navigation.
Grant data model View All or View Specific so those views can load data.
Grant table/form enter-data rights only to teams that should create or change records.
Set sheet Data Editing to Read Only or Security Controlled where inline editing should be limited.
Use Hidden When on forms for record-specific field and button visibility.
Open View Access on each team and confirm the effective rights.
Test with a user on each team before rolling out broadly.

Back to help