Inviting your team
Adding a colleague, what a seat is, and why a job title and a set of permissions are two different things.
4 min read
On this page
Who appears here
Settings → Staff is everyone at your own company who can sign in to work quotes, bookings and invoices. It is not your customers and it is not your partners — those have their own directory and their own portals.
Reading the page needs the staff permission; changing anything on it needs the update half of it, and inviting needs the create half. A role with only read sees the same list without the controls.
Inviting a colleague
Two fields: their work email, and the job they are being hired into. Each role explains itself in a line under the picker, which changes as you change the selection — the six labels alone do not say what a person will be able to open.
They are emailed a link that lets them set their own password. The link is also shown to you as a field you can copy, for the case every email system has — it did not arrive — and it is good for seven days.
There is no separate confirmation step afterwards. Receiving the invite at that address is the proof, so somebody who accepts is signed in and working immediately.
Seats, and who counts
Your plan allows a number of staff seats, and the meter in the panel's header is there to answer the question the whole form depends on: is there room for one more?
An active login takes a seat. Two things do not:
- A pending invite. Somebody stays out of the count until they accept, which is also why an invite can be created and then fail at acceptance if the last seat went to somebody else in between.
- A deactivated colleague. Switching somebody off gives their seat back immediately.
At the ceiling there is no form at all — only the two ways out of it, which are to free a seat below or to move to a larger plan. A disabled form with an explanation underneath asks you to work out why the button is dead.
A job title and a set of permissions
This is the one thing on the page worth reading twice. A staff member has two things that both look like a role:
- their job title — Manager, Sales Agent, Accounting — which is what this table's picker shows, and
- the permission role of the same name, which is what actually decides what they can open. That one is the subject of its own article.
They are separate records that happen to share a vocabulary, and they are set together: accepting an invite assigns the seeded permission role matching the job title, and changing the picker here writes both. Promoting a Sales Agent to Manager changes their access along with their title.
Where the two have come apart — an account that was moved by some other route, or one that never got a permission role at all — the row says so underneath, with what its permissions currently come from. Re-picking the role in that row lines them back up.
Switching somebody off
Deactivate asks first. The person is signed out and cannot log in again until somebody reactivates them; everything they made — their quotes, their bookings, their invoices — stays exactly where it is, attributed to them.
The sting is in the way back: reactivating takes a seat, checked at that moment. If you free a seat and fill it with somebody else, the colleague you switched off cannot simply be switched back on.
Reactivating does not ask. It restores access, and the button that did it is still there to undo it.
Two things you cannot do to yourself
You cannot change your own role, and you cannot deactivate your own account. Both are refused by the server, not merely hidden here.
It is the same reason twice. The only account guaranteed to be able to undo either of those is the one doing it: a sole administrator who demotes or switches off themselves has given away the permission needed to put it back, and nobody else in the company has it. So your own row shows your title as a fact, and says that another administrator has to change it for you.