Browse articles

How permissions work

The full reference for Monument's permission model: the eight account capabilities, how a practice Role cascades into project access, the built-in defaults, and how to customise them.

What you'll achieve

Understand exactly what every access level controls, how a Role's defaults cascade into project access, and where to change any of it.

You'll end up with: A working mental model of Monument's permission system, plus the exact default matrices and where to customise them.

Monument controls access with three independent levels: an account access level for each person, a project access level for each project they're on, and a team access level for each team they belong to. This article defines exactly what each one controls, how a person's practice Role feeds sensible defaults down into their project access, what the built-in defaults are, and how to change any of it.

The model in one paragraph

Your account access level is firm-wide: it decides whether you can see business finances, manage the rate catalogue, create projects, administer every project's configuration, manage staff and teams, submit expense claims, open reports, and see contact information, no matter which project you're looking at. Your project access level is per project: it decides how far you can go on that one job specifically, separately for revenue, expenses, tasks, resources and time. Your team access level is per team: it decides whether you can see a teammate's profile, log time for them, approve their leave, or manage their assignments. Everyone can reach the Projects area now, but reaching it isn't the same as seeing everything in it: which projects and which rows you actually see still comes from the settings and grants described below. Your practice Role sets a sensible default for your account access level, and your account access level sets a sensible default for the project access level you get when you're assigned to work. A Role by itself never opens a project: someone still has to assign you, or a project rule has to match you, before any of that cascades down.

Account access levels: the nine capabilities

An account access level sets nine capabilities. Four run Hidden, View, or Edit. Three, the management capabilities, run Hidden or Edit only: their underlying reference lists (staff names, project names, and so on) are readable organisation-wide baseline data, so there's no separate View state to offer. A ninth, Override timesheet locks, is also Hidden or Edit only, for a different reason: there's nothing partial to view, only the ability itself. Reports runs View or Edit only: there's currently no way to fully hide reports from an active staff member using this switch alone.

Business finances (Hidden / View / Edit). The organisation's own sensitive money: salaries, overhead and operational costs, organisation-wide profitability dashboards and reports, and accounting connections. It also covers financial documents that aren't attached to any project, such as an invoice, quote, or purchase order raised with no project behind it, and the organisation's financial document templates. It does not cover project money. A project's revenue and expenses always come from that project's own access level, never from Business finances directly, though Business finances does put a ceiling on how much project money most people can reach automatically (more on that below).
Rates (Hidden / View / Edit). The organisation-wide rate catalogue: rate shells, versions, custom rate types, and the default rates set for staff, roles, and teams. It's deliberately its own switch, separate from Business finances, so someone can administer the rate catalogue without also being able to see salaries or organisation profitability. Rates also controls whether the Rates list in Resources shows up at all. Working with a billing or cost rate on an actual project still goes through that project's own Revenue or Expenses access, not Rates: a project team member can select an applicable rate without ever touching the organisation catalogue.
Override timesheet locks (Hidden / Edit). Whether this access level can waive an age lock on someone's time entry for a single edit, audited every time it's used. It never waives an invoiced lock; that's corrected through the invoice instead, and it doesn't reach an approved lock either, that's reversed by a reviewer rejecting the entry, not by overriding it. Built in to the Admin level by default, but it's an ordinary switch like any other on the role, not a fixed admin power: grant it to another level or remove it from Admin from this same screen. See Time entry locks and overrides for the override flow itself.
Create projects (Hidden / Edit). Whether you can start a brand-new root project. That's all it does: it has no effect on any project that already exists.
Project administration (Hidden / Edit). Edit access to every project's Tasks, Resources, and Time, no matter which projects you're actually a member of, plus shared configuration: task status and task type catalogues, project templates, and starting data imports. It never touches project money. Editing every project's tasks and editing every project's revenue are two different switches on purpose.
Staff & team management (Hidden / Edit). Create, update, and archive staff, practice Roles, disciplines, skills, teams, memberships, and who has which access assignment. On its own it doesn't unlock rates or salaries: changing someone's rate fields separately needs Rates Edit, and changing their salary fields separately needs Business finances Edit. Account access level definitions themselves and office financial configuration stay Admin-only regardless of this switch.
Expenses & claims (Hidden / View / Edit). The actual-expense ledger: staff claims, supplier invoices, and direct costs, including rows that aren't linked to any project. Edit adds submitting, updating, approving, and rejecting. Office scope (below) still narrows which offices' expenses you can see or touch on top of this.
Reports (View / Edit). View gets you into the report list: running reports, exporting, browsing fields and categories. Edit adds creating, editing, and duplicating report definitions, though editing someone else's saved report stays Admin or creator only even with Edit. There's no Hidden state here, so this switch alone can't lock someone out of reports entirely. What actually shows up inside a report always depends on your other permissions too: a revenue report is still empty for someone who can't see that project's revenue.
Contacts (Hidden / View / Edit). Contact records, contact types, and which contacts are linked to which project. Edit adds creating and editing contacts and contact types. Linking or unlinking a contact from a project needs Contacts Edit and, separately, Tasks Edit access on that project: Contacts Edit alone won't let you add a contact to a project you can't otherwise touch.

Project visibility and project access when assigned

Two more settings live on the account access level, alongside the eight capabilities. Sees all projects vs only assigned projects decides your starting point: "All projects" gives you a genuine, read-only floor on every project in the organisation (equivalent to the built-in project Viewer level), even on projects nobody ever added you to directly. "Only assigned projects" gives you no such floor: with no assignment, you see nothing. Access level when assigned is what an allocation or a matching project rule hands someone the moment they're staffed or matched: that project access level, on that exact task and everything beneath it, but only if nobody's already given them an explicit role on that same task. Set it to "No access level" and being allocated or matched grants no project access at all: the person can still be scheduled without being able to see or touch the project itself.

The four built-ins:

Admin runs the whole organisation. Every capability is Edit, sees every project, and administers settings and everyone's access. Admin can't be edited or deleted.
Project Manager creates and administers projects, manages staff and teams, and can view business finances, rates, and reports, without full Admin control.
Viewer sees business finances, rates, expenses, and reports, but can't create or change anything. Good for a principal who wants oversight without a hand on the plan.
Contributor only sees the projects it's assigned to, and can't create new ones. Business finances, rates, and contacts stay hidden, and it can only edit project work where its project access level allows. Contributor is the default access level for anyone newly added to the organisation.

Office financial access

If your organisation has more than one office, each account access level has an Office financial access setting, all offices or a hand picked list, and each individual person can additionally have their own office override. What someone actually sees is the intersection of both, not either one alone. Set the level to "selected offices" and pick none, and you've hidden all financial data for anyone on that level: that's a real, working lockout, not a bug. When scope is anything less than fully open, Monument doesn't just hide numbers: it redacts sensitive financial fields on records you can otherwise see rather than showing them. For a resource's own financial fields, like their pay rate or salary, this cuts even finer: only someone whose scope is completely unrestricted, all offices, sees them. Being scoped to "their office plus others" still gets you a redacted field, not the real one. This reach extends across invoicing, expenses, quotes, purchase orders, rates, financial reports, schedule financial totals, and the financial figures shown on tasks, whichever capability is gating the underlying data.

Viewing projects is universal now

Every active member with a permission-bearing role can now reach the Projects area, Schedule, task trees, and the staff and project reference lists they depend on. That's just reachability, not automatic visibility: which actual project rows you can see still comes down to Sees all projects vs only assigned projects, the specific access you've been given or matched to on that project, the branch you're scoped to within it, and office scope. Someone who used to be locked out of Projects entirely can now open the area and see exactly the rows their other settings admit, which for someone with no assignment and "only assigned projects" set is nothing.

The cascade: Role, account, project

This is the part that saves you from setting everyone's access by hand. Three things compose, in order:

A practice Role can carry a default account access level. Open a Role in Resources and set Default account access level. Leave it as Firm default and anyone following that Role falls through to the organisation's own default account access level instead.
A person's account access level can be explicit, or it can follow their Role. When sending an invitation, or setting someone's access before they've accepted it, the account access level picker offers Follow practice role / firm default alongside every named access level. Pick that, and the person's effective account access level is whatever their Role currently maps to (or the firm default, if the Role doesn't map to one). Give them an explicit access level instead, and that explicit choice always wins, even if their Role changes later.
An account access level's "Access level when assigned" cascades into project access. Once someone's effective account access level is resolved, that level's Access level when assigned setting is what they get the moment an allocation staffs them onto a task, or a project or task people rule matches them: team, role, discipline, skill, office, or a named person. A rule with a role term matches on practice Role and grants the matched person's own effective default, never a fixed level for the whole Role.

Setting someone's Role, or changing what a Role maps to, therefore flows sensible defaults all the way down to their project access, without anyone re-configuring individual people. But a Role alone opens zero projects. Nothing happens until an actual assignment or a matching project people rule brings that default into play on a specific task. If several rules match the same person at once, that's treated as one match: it still hands them their single effective default, never a summed or escalated level.

Creating a project makes you its Owner

If your account access level has Create projects set to Edit, starting a new root project (blank or from a template) automatically makes you its Owner, with the built-in Owner project access level, in the same action that creates the project. Creating from a template doesn't copy the template's owner across: you become the owner of your own new project regardless of who owned the template. Projects created by an import or an API key with no human behind them don't get an automatic owner; a trusted import can supply one deliberately.

If you later change who's set as a project's owner, the previous owner's automatic grant is removed. But if someone had separately, deliberately been given Owner access by hand, that grant stays: changing the owner field never takes away access that was assigned on purpose.

How project access is decided

When more than one thing could hand you access to the same task, Monument resolves it in a fixed order, most deliberate first:

A level set by hand. Someone added you to the project's Members tab and picked a level themselves. This always wins.
Project owner. You're the project's current owner, so you hold the built-in Owner level automatically.
A matching project or task people rule. A rule targeting that task matched you by team, role, discipline, skill, office, or name, and handed you your own effective account default.
Your assigned default. You were allocated to that exact task, and your account access level's "Access level when assigned" applied.
The all-projects Viewer floor. Nothing else applies, but your account access level has "Sees all projects" set, so you get the built-in Viewer level as a floor.
No access. None of the above applies.

A grant on one task always covers that task and everything under it, never anything above it: being scoped to a branch doesn't give you the project's own root-level records, like an invoice raised directly against the project rather than a task on it.

The project's Members tab shows how each person got their access, labelled Primary owner, Via filter, Allocated-default, or Manual. Only manually added people can be removed from that tab; the rest come and go automatically as ownership, rules, and allocations change.

Business finances caps automatic project money

Every path in that list except the first one, owner, a matching rule, your assigned default, and the all-projects floor, is capped by your account access level's Business finances setting. None of those automatic paths can hand you more revenue or expense visibility on a project than Business finances allows you organisation-wide. Only a level someone deliberately sets on you by hand, in step one, can exceed that ceiling. Business finances is a ceiling here, not a grant: it never hands you project money by itself; it only limits how far the automatic paths can reach. Project administration's Tasks, Resources, and Time override isn't money either, so it isn't capped by this rule at all.

Project access levels: the five dimensions

A project access level sets five permissions for that one project, each Hidden, View, or Edit: revenue, expenses, tasks, resources, and time.

Revenue. View shows you invoices, quotes, revenue entries, and the financial side of the schedule and reports, for the tasks you're scoped to. It also governs the charge-out rate on that project: selecting or resolving a billing rate for project work goes through Revenue, not Rates. One catch: invoices raised directly against the project root, rather than a specific task, need access to the root itself; being scoped to a branch underneath it isn't enough to see those. Edit adds creating, updating, and deleting revenue figures on tasks.
Expenses. The same shape as Revenue, and it's what governs the cost rate on that project: selecting or resolving a cost rate for project work goes through Expenses, not Rates. View shows project-linked expenses, purchase orders, and their figures in search, reports, and the schedule; Edit adds creating, updating, and deleting expense figures on tasks. This is a different switch from the account-level Expenses & claims capability: project Expenses Edit alone doesn't open the Expenses screen; that still needs Expenses & claims.
Tasks. Hidden means no project plan at all: there's nothing to look at. View gets you the task tree and its details, filtered to your branch. Edit adds actually changing that plan: task and project fields, notes, versions and baselines, attachments, allocations, schedule changes, contact links, and custom fields. Editing a whole project, rather than one branch inside it, needs full access on that project, not just a branch grant somewhere underneath it.
Resources. View lets you see who's on the project team and its resource filters. Edit lets you manage resource filters and assignment constraints, and it's half of what's needed to actually assign someone to the project: the other half is that the person you're assigning has assignments Edit on a team you share with them. Project Resources Edit alone won't let you staff someone who fails that second check.
Time. View filters which time entries, reports, and actuals you can see on the project down to your branch. Edit adds logging and editing time entries there. Both still depend on you being able to reach the project at all.

Team access levels: the four dimensions

A team access level sets four permissions for a team: profiles, time, leave, and assignments. You always see your own profile and can log and edit your own time and leave, no matter what access level applies. A team access level is what extends that reach to other people.

Profiles. View makes that person show up in profile-aware reports and other areas of Monument that need to know who's on your team. Edit is selectable, but it doesn't currently add anything over View for general resource details: sensitive fields like salary and rates are governed by Business finances and Rates instead, not by this switch.
Time. View or Edit both make that person's time show up in your reports; the difference between the two currently has no effect beyond reporting, since actually logging or editing someone else's time entries goes through the project's own Time permission, not this one.
Leave. View includes teammates' leave in your lists and schedule views; Hidden filters it out. Edit adds seeing pending leave requests and approving, rejecting, or deleting them. Your own leave requests are always yours to create and edit no matter what.
Assignments. View includes that person's allocations in your reports. Edit is required to actually create, change, or remove an allocation involving them, and it's the other half of assigning someone to a project, paired with that project's Resources Edit, above.

If someone belongs to more than one team, their resource permissions are the highest level granted by any team they're in, not just the last one you set.

Defaults

These are the exact built-in matrices.

Account access levels

Capability	Admin	Project Manager	Viewer	Contributor
Business finances	Edit	View	View	Hidden
Rates	Edit	View	View	Hidden
Override timesheet locks	Edit	Hidden	Hidden	Hidden
Create projects	Edit	Edit	Hidden	Hidden
Project administration	Edit	Edit	Hidden	Hidden
Staff & team management	Edit	Edit	Hidden	Hidden
Expenses & claims	Edit	Edit	View	Edit
Reports	Edit	View	View	View
Contacts	Edit	View	View	Hidden
Sees	All projects	All projects	All projects	Only assigned
Access level when assigned	Owner	Manager	Viewer	Viewer

Project access levels

Permission	Owner	Manager	Member	Viewer
Revenue	Edit	View	Hidden	Hidden
Expenses	Edit	View	Hidden	Hidden
Tasks	Edit	Edit	Edit	View
Resources	Edit	Edit	View	View
Time	Edit	Edit	View	View

Team access levels

Permission	Lead	Viewer	Member
Profiles	View	View	Hidden
Time	Edit	Hidden	Hidden
Leave	Edit	Hidden	Hidden
Assignments	Edit	Hidden	Hidden

Customising

Every access level, account, project, and team, lives in Resources > Access Levels, split into three tabs: Account Access Levels, Project Access Levels, and Team Access Levels.

The built-in levels on each tab can be edited, except Admin, which is locked and marked non-editable, but none of them can be deleted. New access level on any tab starts a custom one from scratch. Most firms never need one, but it's there for anything the built-ins genuinely don't cover.

An account access level can also be set as the default for new staff: open it, use its settings menu, and choose Default for new staff. You can't delete a level that's currently the default; set another one as default first. Deleting any other level is fine even if people are still on it: Monument reassigns its members to whichever level is currently the default as part of the delete.

Some patterns firms actually use:

Want project owners to control budgets without full Admin? Edit the built-in Owner project access level, or duplicate it, rather than making everyone an Admin.
Want nobody outside admins ever seeing money? Keep Business finances Hidden on every other account access level, and avoid handing out project access levels with Revenue or Expenses above Hidden by hand.
Want a bookkeeper who sees everything but changes nothing? That's exactly what the built-in Viewer account access level is for.
Want every Architect to start with the same account access, without touching each person? Set the Architect Role's Default account access level, and leave new staff on Follow practice role / firm default when you invite them.

Assignment rules. A task's Access levels tab has an admin-only Assignment section that narrows who's expected to be assigned to it, built from the same team, role, discipline, skill, office, and named-person terms used elsewhere. It's a guide rail, not a lock: assigning someone outside the rule doesn't get blocked. Monument warns you and asks you to confirm, and that confirmation is kept as a record.

Report sharing. Saving a report opens a Shared with field: leave it as Only you to keep it private, or share it with everyone, a specific team, a specific role, or a named person. Sharing a report only ever decides who can open it, never what data they see inside: someone you share with still only sees rows their own permissions allow. Only an Admin or the report's own creator can edit the saved definition itself, whatever their Reports capability says.

Time entry status eligibility. In Settings, you can limit which task statuses accept new time entries. Leave the list empty and nothing is restricted. The moment you add one status, only listed statuses accept time from then on, for everyone including administrators: an admin can't log time onto an ineligible status any more than anyone else can.

Time entry locks bind everyone too. Invoiced, aged-out, and approved time entries all lock, for admins the same as anyone else, and being an admin never bypasses one by itself. Only the Override timesheet locks capability above does, and only for the age reason, one edit at a time, always audited; an approved entry is corrected by a reviewer rejecting it instead. See Time entry locks and overrides.

Permission preview. From the Staff list, an admin can click Preview on anyone to see Monument exactly as that person does. A banner stays on screen the whole time naming who you're previewing as and confirming it's read only. It shows their real, server-resolved access, and Monument blocks any change while you're previewing: nothing you click can create, edit, or delete data. That's enforced on the server, not just hidden in the UI. See check a colleague's account access level for a worked example.

Offices are admin-managed. Any active member can see an office's name wherever offices show up, in staff records, project settings, and filters. Creating, renaming, archiving an office, and editing its billing or financial configuration stays under Settings and is Admin-only, whatever your own account access level says.