PLATFORM · CAPABILITY
People, roles and permissions
Permissions in EveryonePlans are role-based and granular: every screen and every API call checks a named permission, so you can give somebody exactly the access their job needs without making them an administrator of everything.
01THE PROBLEM
Why this is worth having
Small teams usually run on two access levels — full access, or none — because setting up anything finer is too much work in most tools. So the bookkeeper can see the sales pipeline, the subcontractor can see what you make on the job, and the seasonal hire you onboarded in March still has a login in November.
02HOW IT WORKS
The mechanism
- Roles are sets of named permissions, and you compose them. There is no fixed ladder of Admin / Manager / User to squeeze your organization into.
- The API enforces the same permission the screen does — the interface is a client, not the security boundary. Hiding a button is a courtesy; the check behind it is the control.
- Access is scoped per organization, so somebody who works across two of your clients sees the right thing in each without two logins.
- Where a role cannot see something, the UI hides it rather than showing a disabled control — a greyed-out button still tells somebody the feature exists and that they are not trusted with it.
02bWITHOUT SIGNING IN
What it looks like.
SC-people-roles-and-permissions · TO BE SUPPLIEDSTILL · 16:9
People, roles and permissions — screenshot
REAL SCREEN CAPTURE, NOT GENERATED. The role editor with a role part-built — a handful of permissions checked, most not — so it is visibly granular rather than a set of three tiers. Capture at 1600x900 with believable seeded data — real-looking names, dates within the next two weeks, non-round money amounts — and blur anything identifying a real customer.
DROP AT
/art/screens/people-roles-and-permissions.png03WORKED EXAMPLE
Onboarding a subcontractor for one job
- Create a role that can read jobs assigned to them, upload files, and mark work complete.
- It carries no permission to read pricing, so margin is not hidden from them — it is genuinely not returned by the API.
- They get the job, the address, the schedule and the checklist, and nothing else.
- When the job is done the role is removed and their access ends with it; the record of what they did stays.
04QUESTIONS
About people, roles and permissions
How granular do permissions actually get?
Down to the individual action on the individual module — reading invoices is a different permission from creating them, which is different again from voiding one. Roles are assembled from those, so you can describe a real job rather than approximate it.
Can somebody work across several organizations?
Yes, with different permissions in each, under one identity. That is the normal case for an agency or a bookkeeper, so it is a first-class arrangement rather than a workaround.
05READ NEXT
Contacts and pipelineLeads, customers, organizations and the relationships between them — with the history kept against the record rather than in somebody’s inbox.API and webhooksA versioned REST API over the whole system, with idempotency keys, cursor pagination, signed webhooks and a sandbox.Files and documentsAttachments that belong to the record they describe, with the same permissions as everything else attached to it.
TRY IT
Reading about it only gets you so far.
Create an account and use it. It costs nothing to look, and you will learn more in twenty minutes of clicking than in any amount of this page.