A permission policy is a named set of things a person may or may not do in your workspace, such as Invite members, Approve vendors or Disburse requisitions. Roles give everyone a sensible starting point. Policies let you adjust that for one person, a whole role, a department or a job title, without inventing a new role for every combination.
Who can do this: The workspace owner, and anyone with Manage permissions. By default that is Super admins and Org admins.
Where: Settings > Permissions. From Settings > Members you can also open one person’s access with their Permissions action.
How access is decided
Every time someone does something, ModulawAI works out whether they may, in this order. The first rule that applies decides.
- The workspace owner can always do everything. A policy can never take that away, so the firm always has someone who can fix permissions.
- Members who are not active, such as archived members, can do nothing, whatever their role or policies say.
- A deny anywhere wins. If any policy or override denies an action, it is denied, even if something else allows it.
- An allow from a policy or an override grants the action.
- The role decides everything else. If nothing allows or denies an action, the person gets what their role gives by default.
So a person with no policies works exactly as their role always has. Policies only change something once you add them.
The built-in roles
Settings > Permissions lists each role as a read-only policy, so you can see exactly what it allows. Select View to open one, or Clone to start a new policy from it. Built-in roles always match what the role gets, so they cannot be edited or deleted.
| Role | What it can do by default |
|---|---|
| Super admin | Everything in the workspace, including finance, payment accounts and every requisition and approval. |
| Org admin | Runs the workspace: members, settings, templates, integrations and the rest of administration. Finance and the firm-wide requisition and approval lists need a grant. |
| Case manager | Works on cases and manages them: restricting cases, case approval policies, intake, and other members’ case expenses and time entries. |
| Team member | Works on cases: creates and edits cases, clients and documents, sends documents for signing, and handles vendors, bills and purchase orders. |
| Auditor | Opens the case manager and reads what they can see. Changing records needs a grant. |
| Client | Sees only the cases they are on. Clients are not listed on the Permissions screen. |
Create a policy
- Go to Settings > Permissions and select New policy.
- Give it a Name, for example Finance reviewer, and say What it is for so other admins know when to use it.
- Under Statements, find the actions you want. Search by name, or open an area. Set each one to Allow or Deny, or leave it Not set to let the role decide.
- To cover a whole family at once, use a wildcard such as Every requisitions action, or Everything. Actions added to ModulawAI later are covered by the same wildcard.
- Under Given to, add any groups that should hold the policy: a role, a department, a job title or a named person.
- Select Create policy. It applies straight away to everyone it reaches.
An action that is not set shows what it would get anyway, through a broader action or a wildcard. If a deny in the policy cancels an allow, the editor flags it, because the deny wins.
Give a policy to people
There are two ways, and you can use both.
- To a group: in the policy, under Given to. Everyone in that role, department or job title holds it, including people who join the group later.
- To one person: in the People list on the Permissions screen, choose the policy next to their name. Choose Role default to take it away.
A person can hold several policies at once: their own, plus any given to their groups. ModulawAI combines all of them, and any deny still wins.
Check someone’s access
Select Access next to a person. You see every action, whether they can do it, and what decided it, in words:
- Allowed by policy “Finance reviewer”
- Denied by policy “Partners” (Every requisitions action)
- Their role (Case manager)
- Allowed by an override on this person
- Workspace owner
This is the quickest way to answer “why can’t they approve this?” without reading every policy.
Overrides for one person
An override is a one-person allow or deny, set from that person’s Access view. It can be a single action or a wildcard. Use it for exceptions, such as screening one person from finance, and use a policy when the same rule applies to several people.
Examples
Let case managers invite new members
Create a policy that allows Invite members and give it to the role Case manager. Every case manager can now invite people, and the invitation still counts against your seats.
Stop one job title from inviting
Create a policy that denies Invite members and give it to the job title Managing Partner. An Org admin with that title can no longer invite, even though their role normally allows it, because the deny wins.
Give auditors the requisitions
Create a policy that allows Every requisitions action and give it to the role Auditor. Auditors can now see every requisition, manage other members’ requisitions and disburse them, without any other administration rights.
Allow a group of actions except one
Allow the broad action and deny the one you want to keep back. For example, allow Administer the workspace and deny Plan and seats: the person can run the workspace but cannot change your subscription.
Safeguards
A few rules keep permissions from being used to take more access than someone should have:
- You can only grant actions you hold yourself. If you try, the error names the actions you don’t have.
- You cannot change your own permissions, or edit a policy that applies to you. Ask the workspace owner.
- You cannot change or deny actions to someone whose role is above yours. Only the owner can do that for a Super admin.
- A policy that denies anything can never apply to the workspace owner.
- Deleting a policy asks first and tells you how many people hold it. They fall back to what their role gives.
- Every change to a policy, an assignment or an override is recorded in the audit log, with what it was before and after.
Permissions apply everywhere you use ModulawAI: the web app, the desktop app, the AI assistant, connected AI assistants, workflows and AI employees. The assistant acts as you, so it can never do something you are not allowed to do. API keys and connected assistants also have their own, narrower permissions on top; see Permissions for API keys and AI assistants.
Every action you can allow or deny
There are 68 actions, grouped by area as they appear on the Permissions screen. “Who has it by default” is what the role gives before any policy. The workspace owner always has every action.
People and access
| Action | What it covers | Who has it by default |
|---|---|---|
| View members | See the member list and member profiles | Super admins, Org admins |
| Invite members | Invite people, resend and revoke invitations | Super admins, Org admins |
| Manage members | Change title, office and reports-to; archive, remove or reactivate members | Super admins, Org admins |
| Assign roles | Change a member’s role, or choose it when inviting | Super admins, Org admins |
| Manage permissions | Create and assign permission policies, groups and per-person overrides | Super admins, Org admins |
| Manage org structure | Departments, offices and job titles | Super admins, Org admins |
| Member bio data | Read and edit other members’ bio data | Super admins, Org admins |
| Manage leave | Leave policy and members’ leave allocations | Super admins, Org admins |
| Approve leave | Approve or reject leave when no approver is named | Super admins, Org admins |
| Members’ work reports | See another member’s work report | Super admins, Org admins |
Workspace settings
| Action | What it covers | Who has it by default |
|---|---|---|
| Manage settings | General settings, logo, delegations, lifecycle stages and booking settings | Super admins, Org admins |
| Numbering | Case and document numbering and series | Super admins, Org admins |
| Single sign-on | Configure single sign-on | Super admins, Org admins |
| Plan and seats | Seats, plan and subscription | Super admins, Org admins |
| Allocate credits | Assign workspace credits to members | Super admins, Org admins |
| Audit log | See the audit log and calendar event audit | Super admins, Org admins |
| All activity | See other members’ activity in the firm feed | Super admins, Org admins |
Money
| Action | What it covers | Who has it by default |
|---|---|---|
| Payment accounts | The firm’s bank accounts and its own Paystack, Stripe and M-Pesa connections | Super admins, and anyone given Manage financials |
| Financial reports | Financial and reporting pages | Super admins, and anyone given Manage financials |
| View billing figures | Per-document billing, employee performance and dashboard revenue | Super admins, Org admins |
| Record invoice payments | Record or edit payments against invoices | Super admins, Org admins |
| Firm invoices | Create firm-level invoices | Super admins, Org admins |
| Manage vendors | Create, import and edit vendors | Super admins, Org admins, Case managers, Team members |
| Approve vendors | Approve or reject vendors for payment | Super admins, Org admins |
| Manage bills | Add and change vendor bills | Super admins, Org admins, Case managers, Team members |
| Decide and pay bills | Approve, reject and record payment of vendor bills | Super admins, Org admins |
| View purchase orders | See purchase orders | Super admins, Org admins, Case managers, Team members, Auditors |
| Manage purchase orders | Create, send, sign and receive purchase orders | Super admins, Org admins, Case managers, Team members |
| Others’ payment requests | Manage other members’ payment requests | Super admins, Org admins |
| Others’ requisitions | Edit, cancel or nudge other members’ requisitions | Super admins, Org admins |
| Disburse requisitions | Disburse, return and receive requisitions; close retirements | Super admins, Org admins |
Cases, clients and documents
| Action | What it covers | Who has it by default |
|---|---|---|
| Open the case manager | Reach the case manager at all | Super admins, Org admins, Case managers, Team members, Auditors |
| Create cases | Open new matters | Super admins, Org admins, Case managers, Team members |
| Edit cases | Edit matters | Super admins, Org admins, Case managers, Team members |
| Delete cases | Delete matters | Super admins, Org admins, Case managers, Team members |
| Restrict cases | Restrict a matter and screen people off it | Super admins, Org admins, Case managers |
| Case approval policy | Set a matter’s approval policy | Super admins, Org admins, Case managers |
| Others’ case expenses | Manage other members’ case expenses | Super admins, Org admins, Case managers |
| Manage intake | List, update and comment on intake submissions | Super admins, Org admins, Case managers |
| Others’ time entries | Edit or delete other members’ time entries | Super admins, Org admins, Case managers |
| Others’ contracts | Manage contracts other members own | Super admins, Org admins |
| Send for signing | Send documents for signature, remind, withdraw and share signer links | Super admins, Org admins, Case managers, Team members |
| Create documents | Create Library and matter documents | Super admins, Org admins, Case managers, Team members |
| Administer the Library | Open and manage the whole Library (sealed folders stay sealed) | Super admins, Org admins |
| Emergency Library access | Break-glass access to sealed Library items | Super admins, Org admins |
| Manage clients | Create and edit clients, notes and client login links | Super admins, Org admins, Case managers, Team members |
| Delete clients | Delete clients, one or in bulk | Super admins, Org admins, Case managers, Team members |
| Import clients | Import, enrich and sync clients from other systems | Super admins, Org admins, Case managers, Team members |
Content and automation
| Action | What it covers | Who has it by default |
|---|---|---|
| Templates | Document, email and invoice templates, clauses and the letterhead | Super admins, Org admins |
| Playbooks | Playbooks and clauses | Super admins, Org admins |
| Processes | Processes and the process gate | Super admins, Org admins |
| Forms | Create, publish and govern forms and shared forms | Super admins, Org admins |
| All form entries | See every form submission, not only their own | Super admins, Org admins |
| Share forms publicly | Email public form links to people outside the firm | Super admins, Org admins |
| Manage workflows | Create, change, pause and share workflows | Super admins, Org admins |
| Run workflows | Run the workspace’s workflows | Super admins, Org admins, Case managers, Team members, Auditors |
| Pipelines | Create and run pipelines | Super admins, Org admins |
| Integrations | Connect and configure integrations, SharePoint and MCP servers | Super admins, Org admins |
| Webhooks | Outbound and inbound intake webhooks | Super admins, Org admins |
| AI agents | Clerks, agent hooks, The Floor agents and AI employee subscriptions | Super admins, Org admins |
| Publish skills | Share a skill into the firm library | Super admins, Org admins, Case managers, Team members, Auditors |
| Others’ artifacts | Change or delete artifacts other members made | Super admins, Org admins |
| Sites | Build and publish customer sites | Super admins, Org admins |
Calendar, calls and chat
| Action | What it covers | Who has it by default |
|---|---|---|
| Others’ calendar | Edit, reassign, approve or reject other members’ events and bookings | Super admins, Org admins |
| Outbound calls | Place outbound voice calls | Super admins, Org admins |
| Moderate calls | End a call room someone else started | Super admins, Org admins |
| Call recordings | Delete call recordings | Super admins, Org admins |
| Moderate chat | Delete team chat channels | Super admins, Org admins |
Questions
Do policies replace roles?
No. The role is still the starting point. A policy adds to it with allows, or takes away from it with denies. Someone with no policy works exactly as their role does.
What happens when two policies disagree?
The deny wins. It does not matter which policy it comes from, or whether the allow comes from a policy, an override or the role.
When does a change take effect?
Straight away, for everyone the policy reaches. Nobody has to sign out. Buttons and menus catch up the next time their page loads.
Can a policy give someone access to a restricted case?
No. A restricted case is open only to the people allowed on it, and to the workspace owner. No policy, role or override adds someone to it, and someone screened off a case stays off it. Manage this from the case’s own access settings. A policy can close every case to someone, by denying Open the case manager.
Why are clients not on the Permissions screen?
A client’s access comes from the cases they are on, not from a role or a policy.
Is this the same as API key permissions?
No. Policies decide what a person may do. API keys and connected AI assistants carry their own narrower permissions as well, and both must allow an action. See Permissions for API keys and AI assistants.