User roles and permissions

A user role is a named set of permissions. Everyone in your workspace holds one, and it decides which modules they see and what they can do in each of them.

Most teams never need to build one. JomeInvoice creates four roles for you when your workspace is created, and for a small team those four are usually enough. Build a custom role when none of them fits the job, for example someone who needs to export but should not change anything.

The four built-in roles

Every workspace starts with these, under Settings → Workspace Settings → User Roles:

These four cannot be changed or removed. On the User Roles list they offer only View Role, so you can open one and read what it grants, but there is no Edit or Delete. A role you create yourself offers Edit Role and Delete Role instead.

Editor is for colleagues who work on documents every day. It has every option on the Sales, Self-billed, and Purchase rows and on Customers Management and Suppliers Management, so an Editor can create, edit, delete, and export there. It also has every option the Activity Trail, Consolidation Log, Import Log, and Email Logs rows offer. In Settings it can view Workspace Setting but not change it, and it has no access to People, API Credentials, or Webhooks, or to Integrations. Open it with View Role to see exactly what it grants.

Owner is a special case. It cannot be given to a colleague, and an Owner's own role cannot be changed - which is why Owner does not appear in the Role dropdown when you edit someone. There is exactly one ownership path per workspace, so for day-to-day administrative access give a colleague Admin instead. If ownership genuinely has to move, for example because the Owner is leaving the company, contact JomeInvoice to arrange the transfer.

How a custom role is put together

The Edit User Role screen is a long list of permission rows. Each row is one area of JomeInvoice, and the rows are grouped by module: Sales, Customers, Suppliers, Self-billed, Purchase, Activity Trail, Consolidation Log, Import Log, Email Logs, Integrations, and Settings.

For each row you choose what the role can do there. Most rows offer these options:

Throughout the rest of this guide, the full set means exactly those seven options. Some rows offer fewer, and those are listed explicitly below.

Picking more than one

View, Create, Edit, Delete, and Export combine. Choose any mixture of them on a row - View and Export together for someone who reports but never changes anything, or View, Create, and Edit for someone who works on records but should not delete them.

None and All do not combine, because each is a statement about the whole row. Choosing either replaces whatever else you had selected.

Every permission row

Some rows deliberately offer fewer options, and it is worth knowing why before you plan a role around them:

• Sales → Request and Purchase → Request have no Create or Edit. Requests are created by your own customers on your public request page, so creating and editing them is always open to the people submitting them rather than something you grant to your staff. Sales → Request adds Export; Purchase → Request is View only.
• Import Log and Email Logs offer only None and View. Both are logs of what already happened, so there is nothing to create or edit - and no Export, which means a read-and-export role still cannot export from them.
• Activity Trail displays Create, Edit, and Delete, but they are greyed out and cannot be selected. It is an audit log, so the choices that mean anything are None, View, and Export.
• Consolidation Log has Create greyed out. Consolidations are produced by running a consolidation, not by adding a log entry by hand, so the choices are None, View, Edit, Delete, and Export.
• Workspace Setting, People, and Webhooks show Export greyed out, so it cannot be selected on them.
• Settings → API Credentials covers the API sources in Settings → Workspace Settings → API Keys & Webhooks, and shows Regenerate where other rows show Export. View shows the API Credential section, Create allows Add API Source, Edit allows editing a source and the Purchase Module ERP Secret, Regenerate issues a new Client Secret for a source, and Delete allows Activate and Deactivate. A role cannot hold any of these without View. See Organisation, Main HQ and branches for what each action does.
• Settings → Webhooks covers the Webhook Subscription section of the same tab. View lists your webhooks, Create allows Add new webhook, Edit allows Edit, Rotate, and switching a webhook on or off, and Delete allows Delete.

Create a user role

1. Go to Settings.
2. Find Workspace Settings, then click View.
3. Click on User Roles.
4. Click on Create User Role.
5. Fill in Name, Description, and select the appropriate permissions for this Role.

Give the role a name your colleagues will recognise, such as "Finance" or "Purchasing", and a description that says who it is for. Both appear on the User Roles list, so a vague description makes the list harder to maintain later.

Deleting a role you no longer need

A custom role can only be deleted once nobody holds it. If anyone is still assigned to it, Delete Role stops and tells you:

This role is currently assigned to users. Please reassign or remove users before deleting.

Move those people to another role first - or remove their access if they are leaving - then delete the role. Nobody loses access silently because a role disappeared underneath them.

Give someone a role

A role does nothing until someone holds it. People are managed in Settings → People, which lists everyone in your workspace with their name, email, contact, job title, role, and status.

Invite someone

1. Go to Settings → People.
2. Click Add User.
3. Enter their email address and choose the role they should hold.
4. Click Invite.

They receive an invitation by email and appear on the list once they have accepted and verified.

Change someone's role, or remove them

Open a person from the People list to reach their Edit User page. There you can change their Role, set a Job title and Contact, and save.

The Role dropdown offers Admin, Member, Editor, and every custom role you have created. Owner is not on the list, because ownership cannot be handed over this way.

Remove access on the same page takes someone out of your workspace. Use it when a colleague leaves. Their role is not deleted - only their access.

If your workspace uses single sign-on, see Set up Enterprise SSO for how a new SSO user gets their first role.

Choosing a role shape

Start from the job the person actually does, then grant only the rows that job touches. Every row not mentioned should stay at None.

The built-in Member role already covers the plainest read-only case, but its description is explicit that it excludes Activity Trail and Settings. If someone needs to read the Activity Trail, they need a custom role.

Before you grant Settings access

Four permissions deserve a second thought, because their blast radius is the whole workspace rather than one record.

Settings → Workspace Setting grants access to settings that change how invoices behave for everyone, not just for that person. Submission address, submission date type, calculation-mismatch validation, and the customer and supplier matching rules all live there. See Workspace Settings and How JomeInvoice matches buyers and suppliers for what those settings do.

Settings → People covers managing people and user access, so a role holding it can invite colleagues, change their roles, and remove their access.

Settings → Webhooks with Create or Edit lets a role decide where JomeInvoice sends your invoice status updates. Grant it only to whoever owns the receiving system. See Receive invoice status updates with webhooks.

Related articles

• Workspace Settings - every settings tab at a glance
• Create your JomeInvoice account - inviting colleagues to the workspace
• Set up Enterprise SSO - corporate login, and the default role new SSO users receive
• Export invoices - what the Export permission lets someone take out
• API submission errors - authentication failures after API credentials change
• Activity Trail - the log a role needs an explicit permission to read