User roles and permissions
Three access levels decide the shape of somebody’s account. After that, 367 individual permissions decide the detail — which screen they open, and whether they can change what is on it. A subcontracted adjuster, a bookkeeper and an owner can share the same claim and see three different versions of it.
The short version
A user in CRM For Claims carries one access level. It is not a bundle of rights that somebody wrote for you — it is the answer to two questions the system asks constantly: how much of the company this person can see at all, and whether a folder or a stage that is opened “to managers and above” should reach them. The three levels and their wording come from one place in the code, so the Add User dialog, the user record, a project stage and a document folder all offer the same three, described the same way.
| Access level | What it means |
|---|---|
| Sales | Can access only sales-required sections, and only the records they create or are assigned to. The level a commission-only rep or a new hire starts on. |
| Manager | Access to all projects and contacts, but no access to secured folders or company payment settings. The level most of an office sits on. |
| Admin | Complete control over the account, including payment methods. The level that can change what everyone else is allowed to do. |
Admin outranks manager, and manager outranks sales. That ordering is the whole of it — there is no fourth level, and no level you write yourself. Everything finer than those three is done with the permission list on the person’s own record, which is where most of the real configuration happens.
Permissions
Open a user, open the Permissions tab, and you are looking at every screen in the system as a list of tick boxes.
Each line is one right on one screen, labelled with the screen it belongs to and a code such as WP57-A02. A page is not a single permission: the user record alone carries separate rights for its general information, its files, the public adjuster licence block, the login credentials, the permission list itself and the session activity log. That is why there are 367 of them rather than a dozen.
| Kind | What it allows |
|---|---|
| Green padlock | A view right. The person can open the screen or the block and read what is on it. Around a third of the 367 permissions are this kind. |
| Red padlock | A change right — add, edit, delete, send, approve. These are separate switches, so somebody can read a claim’s finances for years without ever being able to alter a figure on it. |
The check happens on the server, on the request, not only in the menu. A screen somebody has no right to open answers with a no-access page whether they reached it from the sidebar or pasted the address in — and a link they are not allowed to follow is not drawn for them in the first place. Hiding a button and refusing the action are two different jobs, and a permission system that only does the first one is decoration.
Granting in bulk
Ticking 367 boxes for every new hire would be its own kind of unusable. The parts of the system that multiply — document folders and claim stages, of which a busy company has hundreds — can therefore be granted by level instead.
A folder can be opened to an access level, and the padlock next to it says which: green for sales, orange for manager, red for admin. Choosing a level hands that folder to everyone at that level and above and takes it from everyone below, in one action, for the whole company. Folders are covered in full under claim document management.
A stage works the same way: open it to an access level, or switch to custom and tick the exact people allowed to put a claim into it. That is what stops a job being marked approved by somebody who is not the one who heard from the carrier. The stages themselves are in how the claims pipeline is set up.
Two things about that are worth knowing before you use it. A folder or stage that has never had a level chosen is managed by hand — the padlock colour on its own grants nothing, so nothing changes under you because of how an icon looks. And once a level is chosen, it is authoritative: it will overwrite an individual grant somebody was given earlier. The dialog says so before you save, because “open this to managers” quietly meaning “except for the four people we made exceptions for” is how an access model stops being trustworthy.
Roles
The word “role” means something specific here, and it is not permissions. Under Settings → Roles you keep a list of the jobs in your company — from the catalogue the system ships with, or a name you create yourself — and put people in them. A role holds several users, carries an optional description of the position and its responsibilities, and keeps its own files.
Roles exist so the rest of the system can point at a job instead of a person:
A role says what somebody does. An access level and the permission list say what they may open. Somebody can hold the Project Manager role and still be on the sales level — the two are set in different places, on purpose, because the person who does a job and the person allowed to see the money on it are not always the same.
Your company
Roles, users, folders, stages and the permission rows themselves all carry the company account they were created under, and every query that reads them is written against that account. Your role list is yours; another company on the same system keeps its own, with its own names in it. A page’s permission check runs against the permission row for that user in that company, so nothing is inherited from anywhere else.
Two honest notes on the edges of that. When our support staff open your account to help with something, they do it through a separate support mode rather than an ordinary login, and in that mode they see the account the way your own admin sees it — so a screen you have locked down for your team is not a screen support quietly has a different key for. And a user who is deactivated stops being able to sign in, but is still named against the roles they held, so a claim from two years ago still says who ran it instead of going blank.
Seats
Permissions and billing meet at the same place: everyone who can sign in is a seat. The company account and the first admin user are included in the plan, and each additional user is $39 a month on both Essentials and Professional. Plans start at $59 a month; the pricing page has both tiers in full.
Adding a user charges that seat straight away, prorated to the end of the current billing period, and the user is only created once the payment goes through — a declined card leaves you with the seat count you had, not a half-made account. Deactivating or deleting a user gives the seat back, and the credit lands on the next invoice.
The practical consequence is that permissions are worth setting properly rather than handing everyone an admin login to avoid the argument. A bookkeeper who needs the finance screens and nothing else costs the same $39 as an owner, and the difference between the two is a tick list, not a plan.
Team permissions are part of Essentials, the entry plan — they are not held back for a higher tier. What Professional adds is the automation, documents and messaging described on the features overview.
Honest limits
If you are weighing this against a broad construction platform or a general-purpose CRM, the comparison page is honest about where each one fits — including the cases where a claims-first system is not the right answer.
FAQ
Straight answers about who we serve, what we automate, and how to get started.
Every user holds one of three access levels: Sales, which reaches only sales sections and only the records that person creates or is assigned to; Manager, which reaches all projects and contacts but not secured folders or company payment settings; and Admin, which has complete control of the account including payment methods. Separately from those, you keep a list of job roles — project manager, estimator, and so on — which is what tasks and project teams are assigned to.
Yes. Each user record has a Permissions tab listing 367 individual rights, each tied to one screen or block and marked as either a view right or a change right. Viewing and editing are separate switches, so somebody can read a screen without being able to alter anything on it.
An access level is about permission — how much of the company a user can see, and which by-level folders and stages reach them. A role is about the job: it groups people under a job title so automatic tasks, project teams and commission splits can point at the role instead of a name. A person has one access level and can hold a role independently of it.
Yes. A project document folder can be opened to an access level, and the padlock beside it shows which: green for sales, orange for manager, red for admin. Choosing a level grants that folder to everyone at that level and above and removes it from everyone below, across the whole company, in one action.
Yes. Each stage has its own access setting: open it to an access level, or switch to custom and tick the exact users allowed to put a claim into it. The refusal happens on the server, not just by hiding the option.
No. Permissions are stored per user, so a new person is a list to tick rather than a template to apply. The access level and the by-level grants on folders and stages are what save most of that work, which is why they exist.
Yes. Team permissions are listed in Essentials, the entry plan, alongside claim pipelines, project records and document storage. Plans start at $59/month for the company account and the first admin user, with additional users at $39/month.
Deactivating the user stops them signing in and releases their paid seat, with the credit applied to the next invoice. Their name still appears against the roles they held and the claims they worked, so the history stays readable instead of going blank.
