Skip to main content
Users & Roles settings page

Settings > Users & Roles

This view can look different dependent on your user role.
See Visibility & Permissions for details.

​
Primary Purpose

Invite team members, assign roles, and control what each user can see and do. Each user can hold a base system role and any number of custom roles. Effective permissions are the union of all assigned roles.
Customisable user roles are available on the Standard and Enterprise plans. The Self-service plan includes the built-in system roles (Owner, Admin, Manager, and Member). See plans.
Invite team members by email. An invited user shows as Invited until their first sign-in, then flips to Active — see Invite lifecycle. Active users can be suspended without losing their audit trail.
Four built-in system roles: Owner (every permission, including billing and subscription), Admin (full feature access — finance is read-only), Manager (operational access with limited settings), and Member (limited access). System roles are fixed templates you cannot edit. Every user has exactly one, and it sets their baseline permissions.
Create roles tailored to your team structure — for example, a “Refunder” role granting orders:order_payments, or a “Cost analyst” role granting inventory:stock_item_cost. Both are things a Member cannot reach on the base role. Assign any number of custom roles to a user alongside their system role. Each custom role also defines which visible areas appear in the sidebar, independently from data access permissions.
Select a user to open their detail view. Next to General, an Activity log tab lists every request that user made across the account — the Activity Log scoped to them as the actor, rather than to a record they touched. The tab appears only for users who have an email address, and only if your roles grant account_settings:general:view.
Activity Log history is available on the Standard plan (3 months) and the Enterprise plan (36 months). See plans.

​
Invite lifecycle

A user you invite by email appears in the users list as Invited. Their roles are already in effect at that point — the status records whether they have accepted, not whether they have access.

​
From Invited to Active

An invited user becomes Active the first time they use the admin with your merchant account selected. Clicking the link in the invite email is one way to get there, but it is not required: signing in through SSO, or setting a password from the login page, activates the membership just the same. Two cases behave differently:
  • The invited email is new to TWICE Commerce. The invite creates their account pointed at your merchant account, so their first sign-in lands there and flips them to Active automatically.
  • The invited email already belongs to another merchant account. Their sign-in lands on that account instead. To reach yours they open the invite link, or select Join next to the Invited merchant account in the admin’s merchant-account list. Switching merchant accounts is blocked while the invitation is unaccepted.
An Invited user who never signs in still holds every permission their roles grant. If you invited someone by mistake, delete them from the users list rather than waiting for the invite to lapse.

​
Managing an open invite

  • Resend — the invite link expires 7 days after it is sent. An invitee who opens an expired link gets a Send new invitation button on that page, which emails a fresh link and restarts the 7 days. There is no resend action in the admin.
  • Revoke — delete the user from the users list. This removes their membership and their pending invite.
  • Suspend — available for Active users only. You cannot suspend or reactivate an Invited user, and you cannot flip one to Active by hand.
Link expiry only governs the emailed link. It never revokes the invited user’s access, so an invitation whose link has lapsed still activates on the next sign-in.

​
How a permission is built

Every permission is a key made of three parts: resource:sub_resource:operation.
  • Resource — one of the ten top-level areas: tasks, inventory, catalog, orders, customers, online_store, reports, location_settings, account_settings, finance.
  • Sub-resource — the slice of that area, usually matching a tab. inventory:stock_item_cost is the income and expenses data on a stock item; orders:order_payments is the Payments tab.
  • Operation — one of exactly four: view, create, manage, delete.
So inventory:stock_item_general:create is “register a stock item”, and orders:order_payments:manage is “change a payment on an order”.
There is no “edit” level. Updating an existing record is the manage operation, and creating and deleting are separate operations of their own. Older pages on this site describe a Manage / Edit / View hierarchy that the product has never had — treat the four operations above as the model.

​
Multi-role assignment

A user’s access is determined by the combination of their system role and any custom roles assigned to them.
  • System role — one per user. Sets the baseline: Owner, Admin, Manager, or Member.
  • Custom roles — zero or more per user. Each adds specific permissions on top of the system role.
  • Effective permissions — the union of all assigned roles. If any role grants a permission, the user has it.
A Member already views and manages inventory and orders on the base role alone. What these custom roles add is the two things Member genuinely lacks: the Payments tab on an order (orders:order_payments) and stock item cost data (inventory:stock_item_cost).
Custom roles only ever add. There is no way to subtract a permission the system role already grants — to give someone less than Member, you need a lower system role, not a custom one.
Deleting a custom role requires removing it from all users first. You cannot delete a role that is still assigned.

​
Visible areas

Each role defines a set of visible areas — the top-level admin sections that appear in the sidebar. Visible areas are independent from data access permissions. A role can grant customers:view (so the user can pick customers inside the order flow) without showing the Customers tab in the sidebar. When you create or edit a custom role, the permissions matrix includes a Show in UI column. Toggling it on for a resource adds that resource to the role’s visible areas. The matrix enforces an asymmetric rule: enabling Show in UI automatically enables View data, but enabling View data does not enable Show in UI. A user’s effective visible areas are the union of all assigned roles. If any role includes an area, that area appears.
Visible areas are a UI convenience, not a security boundary. Data access is always governed by permissions, regardless of sidebar visibility.
Read more: Visible Areas concept guide

​
Settings navigation gating

The Settings dialog only shows pages you have permission to access. If your combined roles do not include the required :view permission for a settings page, that page is hidden from both the sidebar and the URL. The Security page is the exception — it is always visible to every role, though saving changes still requires manage access.

​
What each system role grants

System roles are fixed templates defined in code, not editable records. Rather than a graded hierarchy, each one is a set of whole areas: The practical consequences are narrower than the role names suggest. A Member can register stock items, create SKUs, build listings, and fulfil orders — the base role grants create, manage and delete on those. What Member cannot reach is money: stock item costs, listing prices, price tables, discounts, and the Payments tab on an order.

​
Visibility and Permissions

Access to this page is gated by on the account_settings resource, in the operations described above. A ✓ means all four operations. Custom roles can grant any of these to a user on any system role.