Permissions & actions

In Pantarey control is available per data schema who can do what – and it is possible to run targeted actions on records when needed.

Manage permissions

Each schema has its own “Permissions” tab. Use it to control access to records.

Permission types

Action	Description
List	Find records in lists, search and Kanban boards.
Read	View records.
Create	Add new records.
Update	Modify existing records.
Delete	Remove records permanently.
Query	Use records in SQL analytics: in dashboard widgets, in the SQL editor and in queries of AI assistants.

Define access

Assign permissions to individual users or entire groups.
Processes have full access by default so they can read and write automatically. Conditions and denies (see below) do not restrict processes.

🔐 Permissions apply in the UI as well as in processes and forms.

Description

Every permission can have a short description: why it exists, e.g. "Sales only sees customers of its region (agreed with management)". It is shown in the table below the name and helps to understand it later. Connected AI assistants read it too when they answer questions about permissions. The default permission "Alle Benutzer" of a new schema already has one.

Above the table, "Who may do what?" sums up all entries in sentences; in the dialog, "This means" shows how a permission works.

Only for certain records

A permission can be limited to certain records. Examples:

Employees only see their own leave requests.
The field sales team only sees customers in its region.
A project is only visible to the members of its team.

How it works

In the "Permissions" tab, open a permission or create a new one.
Under Condition, turn on the "Only for certain records" switch.
Choose field, comparison and value, e.g. Region · equals · South.
Save. In the table, the Condition column shows the rule in words.

Compare with the current user: Under "Compare with", the user's e-mail or the user's groups can be chosen instead of a fixed value. Created by · equals · user's e-mail, for example, means: everyone only sees what they created themselves.

Several conditions: "Add condition" adds more rows. At the top you choose whether all of them must match or at least one. "Add group" combines both, for example "Region South and (status open or amount below 1,000)".

Lists inside a record: "Condition on a list" puts a condition on the entries of a list, e.g. "for at least one element of Team: E-mail equals user's e-mail". Then every team member sees the project.

What the user notices: Records that do not match the condition do not appear in lists, search and Kanban boards and cannot be opened. With a conditional permission to update, a record can only be saved in a way that still matches the condition.

Permissions add up. If a user has a permission without a condition through a second group, they see all records.

Denies

A deny takes something back out of an allow. Typical cases:

Released invoices may no longer be changed – except by accounting.
Only management may set the status "Approved".
Interns may not delete anything.

How it works

In the "Permissions" tab, create a new permission and choose "Deny".
Choose the person or group the deny applies to, often "Alle Benutzer" (all users).
Tick the denied actions, e.g. Update.
Optionally set a condition for which records the deny applies to, e.g. Status · equals · Released. Without a condition the action is denied for all records.

Exceptions: In the condition, "Current user" offers "User's groups". With User's groups · does not contain · Accounting as a second row, the deny applies to everyone except accounting.

On update, check: If Update is denied, you choose what the condition refers to:

Choice	Effect	Example
Stored version	Records that already match the condition are locked.	Released invoices can no longer be changed. Releasing itself is allowed.
New version	A record may not be saved so that it matches the condition.	The status "Approved" may not be set.
Stored and new version	Both together.

Important

A deny wins over every allow, including allows through other groups.
A deny applies to connected AI assistants in the same way.
In the table, denies have a red background and are marked "Deny".

Where conditions and denies apply

In lists, in search and in Kanban boards
in SQL analytics: dashboard widgets, the SQL editor and queries of AI assistants
when opening, saving, deleting and converting a record
for references: in reference fields and under "Links" in an opened record
for connected AI assistants. Counts and lists of the assistant only refer to the records the user may see.

Also in SQL analytics: Dashboard widgets, the SQL editor and queries of AI assistants only return the records the user may see. Sums and counts refer to these only. The Query permission decides here. For a table over several sub-schemas, each record follows the permission of its own schema; sub-schemas without permission are missing from the result.

Deleting and converting with links: If other records refer to a record, it cannot be deleted or converted. The user only sees the links they may see. If there are more, a note asks them to contact an administrator.

Update index for conditions

If a condition uses a field that has not been used in any condition of this schema before, the existing records have to be prepared once. A warning sign in the "Permissions" tab and on the "Actions" tab points this out.

In the "Actions" tab, start "Update index for conditions". Until it has finished, users with this condition do not yet see all matching records in lists and search. Newly created or changed records are handled correctly right away.

Changing fields used in conditions

If a field is deleted or renamed, a condition on it no longer fits. So that this never makes too much visible unnoticed: a permission whose condition uses a missing field blocks its users for its actions until the condition is adjusted. This applies to allows and denies, in the app, in analytics and for AI assistants.

Example: A deny "List, Read: Region = North" applies to the group South. If the field "Region" is deleted, the group South sees no records of this data schema until the deny is adjusted or deleted. Other groups and other actions are not affected. If the field is created again, the permission works as before.

If a field gets another type, the permission stays in effect; the condition should still be checked.

Deleting a field: The delete dialog names the permissions whose condition uses the field.
Editing the schema as JSON: Before applying, a confirmation lists the affected permissions.
In the table, a warning sign marks every condition that no longer fits the schema. Please adjust the condition then.

Permissions for AI assistants (MCP)

For each permission it is also defined what applies to connected AI assistants such as Claude or ChatGPT. Sensitive data remains usable in the app without ending up in a chat.

Default "Same as in the app": The assistant may do the same as the user in the app. Existing permissions therefore behave as before.
Restricted: When the "Same as in the app" switch under Via AI (MCP) is turned off in the permission dialog, the allowed actions for the assistant are selected individually.
Never more than in the app: An action can only be allowed for the assistant if it is also allowed in the app.
Overview: The AI (MCP) column in the table shows "same as app" or the actions allowed for the assistant.

The restriction applies wherever the assistant reads data: in lists, in search, when opening a record and in SQL analytics. If a record references a record from a blocked schema, the assistant returns no content for that field.

Example: Absences should be analysable via chat, employee data should not. In the "Employee" schema, the "Same as in the app" switch under Via AI (MCP) is turned off for the default group "Alle Benutzer" (all users) and all actions are deselected. Nothing changes in the app. The assistant still reads the absences, but the "Employee" field in them stays empty.

As with all permissions: if a user has full access through a second group or a personal permission, that access applies. Permissions add up.

Define actions

The “Actions” tab offers tools to update all records at once – for example after changing a schema.

Example

Adjusting the document name pattern.
Use the “Refresh entries” action to update every record.

Administrators only: “Refresh entries”, “Delete all data” and importing records change all records of a schema at once. They are therefore only available to administrators. Other users see them greyed out.

Future capabilities

Bulk edits.
Actions based on specific filters.
Automated migrations of legacy values.

✨ These functions are especially helpful after major schema changes.

The next chapter explains how to export and import the data models.