Users, roles, and who sees what
Inviting people, choosing roles, scoping access to specific entities, and the difference between workspace users, firm staff, and portal clients.
How-toFor Business owners, Firm staff
Three kinds of people
Access in Books is not one flat list. Three populations use the system for different reasons and get different doors.
| Population | Signs in to | Typical access |
|---|---|---|
| Workspace users | The accounting workspace | The organization's books, scoped to the entities they are granted. |
| Firm staff | The firm console | Many client organizations, plus firm-level work queues and engagements. |
| Portal clients | The client portal | Their own reports, documents, and requests — read-focused, no posting. |
Inviting someone
- 1
Open Settings and go to the users area.
- 2
Invite by email address.
Use the address they actually read. The invitation carries the sign-in link, and Books does not maintain a separate password for them to forget — sign-in is handled by the identity provider.
- 3
Choose a role.
Start narrow. Widening access later is a one-click change; discovering that a temporary contractor could post journal entries is not.
- 4
Scope them to entities.
If your organization has more than one legal entity, grant only the ones they work on.
- 5
Send it, and confirm they arrived.
The users list shows pending invitations separately from active members.
Choosing the right level of access
The useful question is not how senior someone is, it is which of four things they need to do: look at numbers, prepare documents, approve documents, or change how the system behaves.
Separate these deliberately:
- Preparing and approving should not be the same person for anything material. That separation is what the approval matrix exists to enforce.
- Changing approval policy is an administrative act, not an accounting one. Very few people need it.
- Read access to reports is cheap to grant and rarely regretted. Posting access is the opposite.
- API keys act with the access they are issued under — treat issuing one as granting a user.
Common questions
Yes, and you should. Grant read access to the entities and reports they need. If they need to post adjusting entries, grant that for the engagement and review those entries in Approvals — every entry they post is attributed to them in the audit trail either way.
Their own reports, transactions, reconciliations, invoices, bills, payroll summaries, documents, and open requests. They cannot post, cannot see other clients, and cannot change settings.
See alsoThe client portal
Check the users list — a pending invitation can be resent from there. If it still does not arrive, the usual cause is a mail filter quarantining the sign-in link; ask them to check quarantine before you troubleshoot further.
Was this useful?