Table Permissions

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:

  • create

  • delete

  • view

  • edit

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

For the create, view and 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

For the view, edit and 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.

Note

You can combine the own and assigned filters, but not the any filter.

You can also combine these filters with the permissions on specific fields, that were described before.

For example:

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

Important

You don’t need to grant create or 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 assigned option.

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.

Important

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 assigned property.

For example, in the following code, a guest user will only be able to view officeName and phoneNumber of the data connected to a task assigned to the user.

permissions:

  guest:
    view:
      assigned: [officeName, phoneNumber]

Warning

As stated before, if you need a user to modify data through a process, you don’t need to give them create or edit permissions. If you grant create, edit or delete permissions to the guest role, any guest user will be able to modify the data directly through the GraphQL Endpoints.