Set up roles and permissions

As soon as more than one person uses your app, you have to decide who can do what. In Vorx you describe those rules in plain English, and they land on the data rather than only on the buttons.

Add authentication first

Permissions only mean something once Vorx knows who each user is. If you haven't already, add sign-in:

Add email and password sign-in, and require users to log in before they can see any data.

With accounts in place you can attach roles to real people. For the fuller walkthrough, see Add authentication.

Two different kinds of role

Worth separating before you start. The roles in this guide belong to your app and govern its users. Who can build or view the project inside Vorx is a separate, workspace-level setting — an admin in your app is not a person with edit access to your project, and vice versa.

Define your roles

Most apps need a handful. Name them for the jobs people actually do rather than for abstract access levels:

• Admin, who manages users and settings
• Manager, who sees everything but doesn't change settings
• Member, who works with their own records
• Viewer, who has read-only access

Add roles for admin, manager, member and viewer, and let an admin assign a role to each user.

Set what each role can do

Now the rules. Spell out create, read, update and delete where it matters — being explicit here avoids surprises later.

Members can create and edit their own records but not others'. Managers can edit any record. Only admins can delete records or change settings.

Vorx enforces this in the database through row-level security, not just by hiding controls. That distinction is the whole point: a Member who guesses a URL, or pokes at the app from outside it, still can't read a record the rule excludes.

Restrict pages and actions

Beyond record-level rules, some whole screens should be out of reach:

• Hide the settings and user-management pages from non-admins
• Remove the delete button for anyone below manager
• Show an approvals page only to managers and admins

Only show the Users page to admins, and hide the export button from viewers.

Be careful with delete

Deletion is the permission worth thinking hardest about, because it's the one you can't test your way out of afterwards. Consider whether the role needs to delete at all, or whether archiving would do — "let managers archive a record; only admins can delete permanently" is a rule most teams are happier with a month later.

Test with each role

Rules are easy to get subtly wrong, so test them the way a user would. Create an account per role under Settings → Cloud → Users and click through the app as each one.

Confirm that a viewer can't edit, a member can't reach settings, and an admin can do everything. Then try the sneaky version: sign in as the lowest role and navigate straight to a restricted URL. If the rules only live in the navigation, that's where you'll find out.

In the docs: Authentication and Sharing and permissions.