Table permissions allow users to view, edit or delete data into the tables directly (without using a process).
You can set the following table permissions for each app role you have defined in your app:
Permissions on all fields, all rows¶
true grants permissions on any field, any row.
false does exactly the opposite of course.
# myTable.yml permissions: recruiter: create: true delete: true view: true edit: true
Permissions on specific fields¶
edit options you can grant permissions to specific fields. For example:
# myTable.yml permissions: interviewer: view: [firstName, lastName, email, resume] # will be able to view only these fields edit: [interviewerComments, score] # will be able to edit only these fields # won't be able to create or delete
You can use the
"*" wildcard to include all fields, and
"!" to exclude a specific field. For example:
# myTable.yml permissions: recruiter: create: ["*", "!salary"] # when creating an entry, it will be able to set every field except salary view: ["*"] # will be able to view all fields. It's the same as "view: true" # won't be able to edit or delete
Permissions on specific rows¶
delete options, you can limit which rows can be modified, by using the following filters:
own: Allows to view/edit/delete rows that have been created by the user. (Directly or through a process).
assigned: Allows to view/edit/delete rows that are connected to a task that is assigned to the user. After the task is completed or reassigned, the user won’t be able to modify the row data anymore.
any: Allows to view/edit/delete any rows.
You can combine the
assigned filters, but not the
You can also combine these filters with the permissions on specific fields, that were described before.
permissions: recruiter: view: any: true # can view all fields in all rows. It's the same as view: true delete: own: true # can delete rows created by themselves assigned: true # can delete rows of processes currently assigned to them edit: any: ['*', '!address'] # can edit all fields, except address, on any row interviewer: view: assigned: ["*", "!salary"] # can view all the fields, except salary, for the rows that are assigned to them
You don’t need to grant
edit permissions when you want the user to modify fields through a process.
This is because the process is the one that will be modifying the data, not the user.
Anyways, you might want to give them access to
view fields that the user needs in the forms for completing their tasks. If they don’t have permissions to view those fields, those fields will appear empty.
If you want them to view only the data of tasks assigned to them (not all the data), make sure to use the
Guest User Permissions¶
Guest users are not able to create, view, edit or delete any data by default.
If you have processes with tasks that will be assigned to guest users, you might want to grant them access to view the specific data they need to complete the tasks they’re assigned.
It’s important to keep permissions for guest users as limited as possible. We recommend to only give them view access to specific fields, filtering with the
For example, in the following code, a guest user will only be able to view
phoneNumber of the data connected to a task assigned to the user.
permissions: guest: view: assigned: [officeName, phoneNumber]
As stated before, if you need a user to modify data through a process, you don’t need to give them
edit permissions. If you grant
delete permissions to the
guest role, any guest user will be able to modify the data directly through the GraphQL Endpoints.