Assign Shop Roles, shop access, and User Permissions
Both are managed from the user's page under Configurations > General > Users: Shop Roles on the Info tab, User Permissions on the Permissions tab. A Shop Role is a descriptive label. User Permissions decide what the person can actually open and change. Keeping them straight is the main job of this page.
To make these changes you need grants of your own: Users Update to edit roles, User permissions Read to see someone's grants, and User permissions Update to change them. A user invited as a Shop Administrator has all three by default.
A Shop Role is a label; a User Permission is access
A user can hold any combination of the three Shop Roles: Technician, Service advisor, and Shop administrator. A role does exactly two things:
- At invite time, each selected role applies a default set of User Permissions matched to that job.
- Tasks and automations can be pointed at a Role Pool, and a pooled Task can be seen and claimed by any user who holds that Shop Role at the shop.
A role does not gate any page or button. Adding or removing a role later changes nothing about what the person can do, because role defaults apply once, at invite. After that, access is edited only on the Permissions tab. If you promote a technician to service advisor, change the role for the label and the Task pools, then add the advisor permissions yourself.
A User Permission is one grant: a resource (Customers, Estimates, Payments, and so on) and an action (Read, Create, Update, or Delete), scoped to either one Shop or a whole Organization. Every save, create, and delete in Shop Atlas is checked against the person's grants, and the request passes if any one grant covers it.
Assign or change Shop Roles
- Open Configurations > General > Users and select the person.
- On the Info tab, select Edit on the Shop Roles card.
- Check or uncheck Technician, Service advisor, and Shop administrator. A person can hold all three.
- Select Save changes.
Roles are also chosen on the invite form; that flow is covered in Add, update, deactivate, or reactivate users.
Edit a user's permissions
- Open Configurations > General > Users, select the person, and open the Permissions tab.
- Select Edit on the Shop Permissions card.
- Check or uncheck boxes in the grid. Rows are resources, columns are Read, Create, Update, and Delete. Each click saves immediately, so there is no Cancel; to undo a click, click the box again.
- Select Done when you're finished.
The boxes you check here are grants for the active Shop only. If the person also has Organization-wide or all-resource grants, those appear as badges in an Effective Broader Access card above the grid. They apply on top of the grid and can't be edited in the app; to change them, contact support.
The grid shows the twenty resources shops manage most often. A few grants exist outside it, such as customer messaging, technician assignments, inventory counts and transfers, return orders, and tax configs. Role defaults and support can apply them and they work normally; they just don't show in the grid yet. The planned Permission reference in the Reference and Updates section will list every resource and action.
What each role grants at invite
Technicians can find and create customers, vehicles, and repair orders, do everything on inspections including deleting a retaken photo, log work time, look up inventory parts, and work Tasks. They can't touch estimates or payments.
Service advisors get the customer-facing spread: customers, vehicles, estimates, repair orders, payments, messaging, the full calendar, counter sales, and assigning technicians to work. They can read parts, purchase orders, and vendors but not change them, and they can't manage users.
Shop administrators get the management spread: shop settings, users and their permissions, automations, workflow stages, communications, and inspections. The defaults notably do not include estimates or payments, so an owner who also writes service work should be invited with both the Shop administrator and Service advisor roles.
These are starting points. Tighten or loosen any individual on the Permissions tab afterward.
How BayEngine decides whether an action is allowed
A grant matches a request when three things line up: the grant's resource equals the request's resource, its action equals the request's action, and its scope covers the shop the request is about. Scope covers the shop when the grant names that Shop directly, or names the Organization the Shop belongs to with no specific Shop. A grant can also use a wildcard for its resource or action, which matches anything; wildcards are applied by support, not the grid.
One matching grant is enough. There are no deny rules, so removing access always means revoking a grant rather than adding a block.
Shop access and Organization-wide scope
A person has access to a Shop when they hold any grant covering it. That is what puts the Shop in their shop switcher and puts them in that Shop's Users list. Every invite includes a minimum Shops Read grant for the inviting Shop, so a person invited with no roles can still sign in and see the shop; they just can't open anything else until you grant more.
For a multi-shop Organization, an Organization-scoped grant covers every Shop in it, including shops created later, with no per-shop copying. This is how an owner or bookkeeper works across locations. Since the grid only writes single-shop grants today, ask support to set up Organization-wide access. How settings themselves cascade across shops is a separate topic, covered in Organization defaults and shop overrides.
When a change takes effect
Grants and revokes are checked on our server at the moment of each request, so they apply to the person's very next click. No re-invite, and no need for them to sign out.
Live-updating pages are the one lag. The Workflow board, document lists, and Inbox stream reads through the person's signed session token, which is reissued about every 15 minutes. Until their token turns over, a newly granted Read permission won't fill those live pages, and a revoked one will keep streaming what it already covered. Signing out and back in applies everything at once, so if a change needs to land right now, have them do that.
To see sign-ins and past permission changes, see Review login and permission history.