Praxsuite

Users & Endusers

documentation/core/users

Users

Users are the people who operate a Workspace in Praxsuite. They can create, manage, and interact with your system - Tables, Forms, Dashboards, Automations, Files, and more - but always within the security rules you define.

Users are the people who operate a Workspace in Praxsuite. They can create, manage, and interact with your system - Tables, Forms, Dashboards, Automations, Files, and more - but always within the security rules you define.

In Praxsuite, being a user never automatically means having full access. Access is always limited (or expanded) through:

  • Roles

  • Permissions

  • Access Grants

This keeps your Workspace secure, predictable, and scalable.

Users as administrators of the system

Praxsuite users are often admin users in the sense that they work inside the operational backend. They are not end customers; they are the team members who manage and run the system.

What they can do depends on the access model:

  • Some users may build and configure (admins, operators, developers).

  • Others may only view or update specific tables or records.

  • Some may be restricted to a single area of the operation.

Praxsuite is designed so that control is intentional, not accidental.

Ownership and the first user

Every Workspace begins with one user:

The Owner

The Owner is the user who creates (or acquires) the Workspace.

The Owner can:

  • create and configure any feature in the Workspace

  • invite users

  • assign roles

  • grant or revoke permissions

  • manage Access Grants

  • remove users or cancel invitations

Because the Owner is responsible for the Workspace, they have full visibility across it.

Seats and user limits

Every user in a Workspace occupies a Seat.

Seats are the way Praxsuite controls how many admin users can participate in a Workspace. Think of seats as “available slots” for team members.

How seats work

  • Each subscription includes a certain number of seats.

  • When you add a user, one seat is consumed.

  • When you revoke a user’s access, that seat is freed and becomes available again.

  • If you reach your seat limit, you can purchase additional seats.

Seat limits by Workspace type

  • Free Workspace

    • Maximum: 1 user

    • Intended for sandbox/testing only

  • Paid subscriptions

    • Include multiple seats depending on plan

    • Example: Basic plans start at 3 seats, and higher tiers include more.

    • Seat limits grow with subscription level.

This model lets teams scale gradually, without forcing you to overpay upfront.

Why the seat model matters

Seats keep Workspaces:

  • organized: only the right number of admin users are inside

  • secure: user access is explicit, not uncontrolled

  • scalable: you add people as your system grows

  • predictable cost-wise: pricing aligns with real usage

In short

  • Users are the internal operators of a Workspace.

  • Access is never automatic; it is defined through Roles, Permissions, and Access Grants.

  • Every Workspace starts with an Owner who manages access.

  • Users consume Seats, and seats define how many users can be in the Workspace.

  • Revoking a user frees a seat instantly.