Roles and permissions

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

Project managers can read their assigned projects and the subcontractors, documents, dashboard status, and scoped reports connected to those projects. They cannot read organization-wide reports or other projects. Their action permissions remain narrower than an office administrator's.

Subcontractors do not need a workspace role or login. They use the scoped upload link sent by the contractor, so they do not appear in the team invite list.

What nobody can do

Workspace roles cannot edit existing audit rows. The database revokes update and delete on that table from the ordinary tenant-facing role; Sealinn's restricted maintenance role remains able to administer the database, and an audit insert can fail independently of the product action.

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.

Sealinn attempts to write those changes — an invitation sent, a role changed, somebody deactivated — to the audit log with a name and a timestamp. Canceling a pending invitation returns the seat immediately. So does deactivating somebody who has left — previously recorded approvals remain separate from current access. 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.