Documentation / Members & Roles

Members & Roles

Invite team members to your project, assign roles, and control what each role can see and edit.

Overview

Team access in Configo is scoped to a project, not global to your account. Every person on a project has exactly one role, and the role determines what they can see and change — from which orders they're allowed to view to whether they can see the purchase price of a material. Open Members in the project sidebar; it has two tabs, List and Roles.

Managing members and roles requires both the Edit project and Edit members permissions. The project owner always has full access and bypasses permission checks entirely.

Adding a member

Open the List tab and click Add. You'll need:

  • Email (required) — the email address of an existing Configo account. Adding a member looks up an existing user by email; it doesn't send an email invitation, so the person needs to have already registered a Configo account with that address before you can add them.
  • Role (required) — pick from the roles already defined in this project.

Click Save. The member appears immediately in the list with their name, email, assigned role, and the date they joined.

The number of members you can add is limited by your subscription plan — adding beyond the limit, or with an expired subscription, is rejected. See Billing & Subscription for plan limits.

Editing or removing a member

Click the edit icon on a row to change their role, or the trash icon to remove them from the project. The project owner's own row has no edit or delete controls — ownership can't be reassigned or revoked from this screen.

Roles

Open the Roles tab to see every role defined in this project, and click Add to create a new one. Configo ships with a few sensible starting points depending on your plan (an Owner-equivalent role, a Manager, and often a Dealer), but you're free to rename, edit, or add your own.

Each role has a name and a permission table covering every resource in the project: Orders, Contacts, Tasks, Purchase Price, Sale Price, Dealer Price, Order Product Prices, Materials, Configurators, Products, Documents, Email Templates, Reports, Warehouses, Wiki, Wiki Comments, Automations, Project, Members, Statuses, and Data Export.

How the permission table works

The table has two columns — Read and Edit — but not every row uses both the same way:

  • Orders, Contacts, and Tasks have an owner concept, so their Read column is a scope selector instead of a plain toggle: None, Own, By role, or All.
    • Own — the member sees only records they're personally responsible for.
    • By role — the member sees records assigned to anyone sharing their role.
    • All — the member sees every record in the project regardless of who's responsible.
    • This is what lets a salesperson be limited to their own deals without hiding the pipeline from their manager, or a whole sales team see each other's orders without seeing another team's.
  • Everything else with a Read column (Materials, Configurators, Products, Documents, Reports, Warehouses, Wiki, …) is a plain view/hide toggle — there's no ownership concept for a material or a configurator.
  • The three price rows (Purchase Price, Sale Price, Dealer Price) are independent toggles with no Edit column. Turning one off hides that specific price everywhere in the app for members with this role — order lines, material tables, reports — while the other two stay visible. This is how you let a dealer quote from the sale price without ever seeing what materials cost you.
  • Project, Members, Statuses, and Data Export only have an Edit column — there's nothing to "view" separately from administering them.

Rows with no applicable column (e.g. no Edit for a price-visibility row) show a dash.

Click Save to apply the role. Changes take effect immediately for every member currently assigned to it — you don't need to reassign anyone.

Deleting a role

Click the trash icon on a role's row. Members currently assigned to a deleted role keep their project access removed until reassigned — move any affected members to another role first.

What roles don't cover

A few things sit outside the permission table entirely:

  • The project owner bypasses all permission checks, always.
  • OAuth applications have their own, separate scope system for API access — see the API Reference — unrelated to project member roles.
  • Widget visitors (people using a public configurator link) are governed by the permissions baked into the widget token, not by a project role — see Getting a widget link.