Roles and access

Four separate things decide what a user can reach and do. They fail in different ways, and diagnosing an access problem is mostly working out which one is involved.

The four controls

Control	Set where	Decides
The plan	Your subscription	Which modules exist for the company
Module access	Users, Modules tab	Which of those a user can open
Module permissions	Users, Modules tab, the permissions list under a module	What they can do inside it: edit, delete, approve, send, see money
Project and estimate permissions	Users, Projects tab - or the project’s People tab	Which jobs they can see

They apply in that order. A module your plan excludes cannot be granted to anyone; a module a user cannot open is invisible regardless of their project permissions.

Changing plan changes the first control for everyone at once. Upgrade and every existing user gets the new plan’s modules and their permissions without anyone ticking boxes. That is a change worth knowing about if you have carefully limited what someone can see — the new modules arrive switched on, so check them after an upgrade.

Diagnosing

Symptom	Cause	Fix under
Padlock on the menu item	Plan excludes it	Change plan in the Admin panel
Greyed out, no padlock	No module access	Users, Modules tab
Module opens, no projects listed	No project permission	Users, Projects tab
Project opens, an estimate is missing	No estimate permission	Users, Projects tab - open the project’s estimates
Module opens, a button or the price columns are missing	A module permission is off	Users, Modules tab, the permissions under the module. See Module permissions
Not in the menu at all	Switched off system-wide	SmarteBuild support

The middle four are the ones you can fix yourself, and the second and third look similar enough to be confused constantly. The distinguishing question: can they open the module at all? If yes, it is permissions. If no, it is module access.

Sensible setups

Estimator

Modules	Projects, Documents, Take-Off, Cost Codes, BOQ, Tenders, Quotes
Projects	The jobs they are pricing
Administrator	No

They do not need Purchase Orders or Claims, and giving access to modules someone does not use makes the menu harder to navigate rather than more useful.

Site supervisor

Modules	Documents, Schedule & Booking, Site Diary, Checklists & Safety, Defects, Messages, Purchase Orders
Projects	Their jobs only
Administrator	No

The interesting question is Purchase Orders. Supervisors often need to raise orders on site, and they generally should not see the whole job’s margin. Grant Purchase Orders; leave the BOQ off. If they do need the BOQ for quantities, give it and switch off its two See money module permissions.

Contract administrator

Modules	Orders, Expenses, Claims, Variations, plus BOQ read access
Projects	All live jobs
Administrator	No

Business owner

Modules	Everything
Projects	All
Administrator	Yes

Grant what people need

The default instinct is to give everyone everything, because it avoids being asked. It is worth resisting for two reasons, neither of which is distrust.

A shorter menu is easier to use. A supervisor with fifteen modules they never open has to find the three they do.

Estimate data is commercially sensitive. Your margin, your rates and what you pay each subcontractor are not information every user needs, and site staff work alongside the subcontractors in question.

Project permissions are the sharper tool

Rather than restricting modules heavily, give people the modules they need and use project permissions to limit which jobs. Someone who can use Purchase Orders properly but only on their own two sites is both useful and contained.

Reviewing

Worth a look twice a year, and immediately when someone changes role:

1. Anyone disabled who has left?
2. Anyone still on projects they finished a year ago?
3. Anyone an administrator who does not need to be?
4. Anyone who changed role and kept their old access as well as their new?

The fourth is the one that quietly accumulates.