Help
Roles and permissions
Four roles you can hand out, and the useful decisions are two: who may approve a document, and who may change the rule it is approved against. Those are deliberately not the same person.
The two questions worth asking
Ignore the role names for a moment. Almost every access decision in a small contractor's office comes down to two questions, and they have different answers.
- Who may accept a certificate? This is a judgment about a document in front of them. A site manager or an office administrator can reasonably make it.
- Who may change what a certificate is measured against? This is a judgment about your risk position across every job. Handing it out with the first one means a requirement can be lowered until a document passes, and the record will show a clean approval.
Sealinn keeps those separate on purpose. The practical shape is that several people can work the review queue while one or two decide what the rules are.
The 4 roles you can assign
| Role | Can approve documents | Can change requirements | Also |
|---|---|---|---|
| Owner | Yes | Yes | Billing, inviting people, the audit log. The account holder. |
| Compliance manager | Yes | Yes | The audit log. The role for whoever actually runs this day to day. |
| Office admin | Yes | No | Works the queue and chases documents; cannot move the goalposts or read the log. |
| Project manager | No | No | Scoped to their own projects. Sees who is short on their jobs without the whole book. |
A project manager is the one worth explaining, because the restriction is the feature. They see the subcontractors assigned to their own projects and not the rest, which makes it a safe account to hand a superintendent who needs to know whether a crew can start on Monday and has no reason to see your whole book or your billing.
Two more roles exist in the data model and neither one appears in the invite list. Super admin is Sealinn's own support access across organizations — it is not something you assign, and everything it does is written to your audit log the same as anyone else. Subcontractor is reserved for the upload portal, where people send you documents without an account at all, so no login is ever created with it.
Your broker cannot be given an account
The broker role exists in the data model and carries no permissions at all, so inviting one would create a login that can see nothing. It is reserved for later work rather than switched off, and saying otherwise here would send somebody to try it. If your agent needs to see a subcontractor's status today, generate a report and send it — the four reports cover the shapes that question usually takes.
What nobody can do
No role can edit the audit log. Approvals, overrides and the reasons given are append-only from the application's side — the database revokes update and delete on that table from the role the app connects as.
That is a narrower claim than "nobody can change it", and the narrower claim is the true one. The security page states it precisely, including what it does not cover, because a security promise worth making is one somebody can check.
Adding someone, and taking access away
Invitations go by email and the person picks their own password; you never handle a credential. Change somebody's role at any time and it applies immediately rather than at their next sign-in.
Deactivating removes access and keeps history. That is the correct behavior for a compliance record and occasionally a surprise: a person who left last year still appears against the approvals they made, because deleting them would quietly rewrite who decided what. The one thing the app will not let you do is remove the last owner — an organization with nobody who can invite or pay is an account nobody can recover.
What actually holds a seat
Your plan's limit is counted in people who can sign in (what each plan number counts covers the subcontractor half), and an invitation that nobody has accepted yet counts as one of them. So an organization one seat from its limit, with an unanswered invite sitting in somebody's spam folder, is already full — and the team page shows a number one lower than the one being enforced, because it is listing members and the check is counting members plus invitations.
Every one of those changes — an invitation sent, a role changed, somebody deactivated — is written to the audit log with a name and a timestamp. Two things follow from that, and both are the answer to "we are at the limit and I need to add someone today". Canceling a pending invitation returns the seat immediately. So does deactivating somebody who has left — their approvals stay in the record exactly as before, because history and access are separate things here. Sealinn's own support access does not occupy a seat either.
If the person accepting an invitation is told the workspace is full, that is the same check running a second time at the moment they click, which catches the case where the plan changed between sending and accepting. They cannot resolve it themselves — the message points them back at you, because the person accepting an invitation is not the person who can change the plan.
Still stuck? Tell us what happened.
A person reads every message. Free for up to 10 subcontractors — no card.