Chapter · Company Admin Edition

Members, invitations, and capabilities

The welcome chapter called the company-vs-project invitation the one distinction that governs everything. This chapter is its operating manual.

The two invitations, mechanically

  • Company invitation (company settings → members): creates a company user in your workspace. They see company tools, can be granted capabilities, and can then be added to any project. One company per person - an invitation to someone already in another company will be refused, not merged.
  • Project invitation (project → team): creates a collaborator on that project only, with a per-tool permission grid. It never creates company membership, and no amount of project work promotes anyone - promotion is always an explicit company invite from you.

When in doubt: is this person's relationship with the company, or with a project? Employees and long-term contractors → company. Clients, vendors, venue staff, one-project partners → project.

What a project-only collaborator actually sees

Their projects' contents per their grid, plus the cross-project pages those feed (their tasks, flags, schedules), Pocket, and the Field Guide. They do not see: program names, status vocabulary, company contacts, company Sparks, or your company's name and branding surfaces. If a collaborator reports "missing" tools, check membership before permissions - it is the answer far more often.

Per-member capabilities

Company membership is the floor; capabilities are the individually granted extras: create projects, manage templates, manage the company library, manage permission templates, contacts (view - on by default - edit, and manage), and explicit Sparks participation where you run Sparks opt-in. Grant by role-in-fact, not title: capabilities describe what someone does, and they compose - a studio lead might hold templates and library; an office manager, contacts and nothing else.

Permission templates

⚙ Make it yours - the per-project grid (tool-by-tool: none / reviewer / view / edit / admin) is powerful and tedious, which is why permission templates exist: define "Client," "Fabricator," "Full team" once, and stamp new project members instead of hand-setting ten switches. Templates are a starting stamp, not a live link - adjusting one member afterward never rewrites others.

Rule: invite to the narrowest true relationship; widen on evidence.

Cost of choosing wrong: the over-invited vendor browses your idea pipeline and client list; the under-invited employee works for months not knowing half the platform exists. The first is a disclosure you cannot un-ring; the second is capability you paid for and never used.

Mechanics - invitation flows, grids, and templates: Field Guide → Team & permissions.