What contractors can see

A contractor's role in GIG is view-only, everywhere, by design. Whatever project, gig or budget they're put on, they can look at it and comment on it, but they cannot change it — that boundary is enforced on the server, not just hidden in the interface, so it holds even if someone calls up an editing action directly.

Attempting a blocked edit doesn't fail silently or throw a generic error: it shows "Your access to this organization is view-only — contractors don't edit org data." That message deliberately does not say to ask an admin. There is no edit right an admin could hand a contractor to fix it — read-only is what the role is, not a permission that happens to be switched off — so pointing someone at an admin would send them to make a request nobody can grant.

Why the line sits here

Contractors never take a team seat, on any plan, and everything contractors use is included on every plan — there is nothing extra to buy for them. A plan's seat limit counts team seats, so letting contractors edit organization data would give an organization an editing team that sits outside that limit entirely. Editing requires being staff instead, a role that does take a team seat. If you need someone to be able to make changes, change their role to staff rather than adding them as a contractor.

What they can still do

Everywhere, a contractor can leave a comment and answer an approval request they've been sent — both are treated as replies, not edits to the underlying record, so they stay open even though everything else is closed. Outside of org data entirely, they can also sign their own contractor agreement, mark their own notifications read, and edit their own GIG profile — none of that is org data changing hands, so none of it needs the staff role.

What "assigned" gets them

Being put on a project, gig or budget only ever grants read access to it, never write:

• Architect boards — any assignment (lead, coordinator or viewer) resolves to view-only. A contractor named the lead on a board sees the same read-only chrome as one who was only asked to review it.
• Gigs and rosters — visible for the gigs they're rostered onto.
• Finance budgets — visible only for a budget they're the named lead on, and even then, read-only: no line item can be added, edited or removed by a contractor.
• Their own person record — a contractor can always see their own entity, plus the records of people they share a gig roster with.

What they never see, even when granted the module

Staff-authored material about a person stays staff-only, regardless of what modules the contractor can otherwise open: notes on a person record, working groups, and the per-person activity timeline. This is deliberate, not an oversight — a contractor may themselves hold a person record in the same organization, and staff need to be able to write candidly about a contact ("unreliable with call times, book a backup") without the subject reading it back if that subject happens to also be a contractor.

The same logic closed a real gap: contractors could generate a self-update link for another person's record purely because the underlying table doesn't carry an organization id the general contractor sweep could key on, so it was missed rather than deliberately allowed. That's fixed — see Ask someone to update their own details — and the general rule it illustrates holds everywhere: "assigned reader" is not the same permission as "can write," even indirectly, through a feature that was built for staff.

Modules are opt-in, not just capped

A contractor sees nothing beyond the command menu until an admin grants a module to them individually, under Settings → Permissions. This is different from every other role, which sees a sensible default set of modules automatically — a contractor's whole module list starts empty and is built up one grant at a time. Architect, Finance and Docs are the modules organizations most commonly grant this way. A grant only ever widens what a contractor can read; it never grants write access, which stays closed everywhere per the rule above.