User Seats

Understand the difference between user types and their powers.

Seats

What's a user seat?
User seats are defined by your subscription plan. They define the maximum powers of a specific user.

For example: if you have a no-code seat and you want to edit a low-code function, you'll not be able to. Although you didn't block it explicitly, only the developer seat can access the low-code function area.

🚧

Seats should not be used as permissioning

We strongly recommend that you control all your user's powers using roles.

What's the difference between seats and permissioning?
To do something in your Jestor, both your seat and permissioning have to allow it. It's the intersection of powers, or "sum of restrictions", that results in your final powers.

Example:

• Seat: Member.
• Permissioning: full power to access and edit the structure of the table "clients".
  Result: Members can access and create records on the table "clients", but cannot create new fields or add automations in this table.

What are the seat types?
There are 4 types of seats: Members, Builders, Portal (beta), and Guests (beta).

Builders

They have the power to build and edit the organization structure and edit records. There are 2 types of builders:

• Business:
  • They can build all the system structures using no-code tools and premium blocks.
  • Plan: Bussines.
• Developer:
  • They have all the powers of a no-code builder plus: access to low-code tools, developer fields, and advanced permissioning rules.
  • Plan: App Developer.

Members

• They can edit records and use apps.

You can check the differences between builder types and prices here.

Member Seat

They are "users that use" the Jestor internal tool built by builders (Business and Developer). They can navigate and interact with all tools built by builders. However, they can't build or create new structures, except for pages.

Example of powers:

• Create, edit, write, and delete records.
• Upload and download data.
• Send messages in the chat.
• Move cards on a kanban board.
• Interact with dashboards.
• Click buttons.
• Fill out forms.
• Edit their Information.
• Individual login and password.

Members are not allowed to be super-root admins. Therefore, they can't (and shouldn't) be able to manage your Jestor account.

Builder Seat (Business)

Business builders can create structures and automations without using code. They have all the powers of a Member, plus builder powers and tools.

Example of powers:

• Manage tables, views, and apps.
• Install templates.
• Settings access to user management, plans, language and region, roles, and history log.
• Manage users, seats, and plans.
• Manage automations.
• Manage chat channels.
• Manage workspaces.
• Manage APIs.

Manage = Create, edit, and delete powers.

Builder Seat (Developer)

Low-code builders can do all that the no-code builders can, plus access to low-code tools and special features.

Example of powers:

• Manage low-code functions.
• Manage low-code triggers.
• Manage low-code webhooks.
• Developer fields and blocks (tagged as "App Dev").

Portal Seat (Beta)

Available exclusively to a limited number of select accounts.

• Member seat powers with a few restrictions.
• Access 1 App (máxiumum of 10 App Pages).
• Cannot access tables directly.
• Cannot be used by company employees if they share the same email domain as the organization owner.
  • For example, if Nike owns an account, users with the email domain [email protected] cannot be added.

Guest Seat (Beta)

Available exclusively to a limited number of select accounts.

• Member seat powers with a few restrictions.
• Access 1 App Page.
• Can't comment on cards or records.
• Cannot access tables directly.

Viewer (Beta)

Available exclusively to a limited number of select accounts.

• Read-only access to app pages.
• Obs: you need to ensure that the permission rules are in place to enforce restrictions. For instance, access to the table email should be restricted either by removing it from the app or through role-based permissions.