Panzo lets you give every person exactly the access their job needs, no more. Access is controlled per module and per action, money-moving work is locked down by default, and what each person can see follows your reporting lines. This guide is for owners and admins setting up who can do what.
How access works
Access in Panzo is governed by a Profile: a permission matrix that says which actions a person holds, module by module and verb by verb. A Profile might grant a site engineer projects.edit and site.create while withholding anything in Finance. You build Profiles once in Control Panel, then assign one to each user, so access is a job description rather than a per-person fiddle.
The same decision runs everywhere. Whether a request comes from the web app, the mobile field companion or a background action, one rule engine answers it, so what a person can tap on their phone and what they can do at a desk never drift apart. Someone with super_adminrights bypasses the matrix entirely and is the only role that can change another user's underlying role.
Deny-by-default on money
Most modules fail open: if you have not configured a module yet, the team is not locked out of it, so you can start working before every Profile is perfect. Money is the deliberate exception. Modules and actions that move rupees deny by default, so a brand-new account with no Profile assigned can never record or approve a payment before you explicitly grant it.
| What is locked by default | Why |
|---|---|
| Finance | Invoices, collections and payment milestones stay closed until granted. |
| Procurement | Vendor payments, purchase orders and BOQ approval are gated from day one. |
| Aftercare money actions | Approving claim amounts, warranty decisions and service config deny by default, even though everyday ticket work stays open. |
Note
Everyday work still flows
Reporting hierarchy and record visibility
Alongside what a person can do, Panzo controls what they can see. Every module applies one of four scopes, and it applies to writes as strictly as to reads, so a rep on "Own" cannot edit or delete a teammate's record even by opening its link directly.
| Scope | What the person sees and touches |
|---|---|
| Own | Only records they own. Right for individual reps and engineers. |
| Team | Their own records plus their reporting line's, so a manager sees the team under them. |
| All | Every record in the module across the organisation. |
| None | No access to the module at all. |
Because Team scope follows your reporting hierarchy, setting up who reports to whom is what makes a sales head see their pod, or a project manager see their site team, without handing anyone the keys to the whole company.
Setting it up
Build your Profiles
In Control Panel, create a Profile per job type and tick the module actions each one holds. Keep the money modules tight.Assign a Profile and role to each user
Under Users, set the person's Role and Profile. Creating a user also provisions their sign-in automatically, so they can log in straight away.Set the visibility scope
Choose Own, Team, All or None per module so people see exactly their slice of the pipeline.Check with View As
Use View As to see the app exactly as that person will, and confirm nothing sensitive is exposed and nothing they need is hidden.
Tip
View As is audited
Important
Enterprise identity is on the roadmap
Key takeaways
- Profiles set access per module and per action, and the same rule is enforced on web and mobile.
- Money modules deny by default, so a new account can never approve or record payments unasked.
- Own / Team / All / None scopes follow your reporting hierarchy and apply to writes, not just reads.
- View As lets you verify a person's access, and both View As and access changes are logged.
- SSO, 2FA and SCIM are on the roadmap, not available today.