Inkpilots

Collaboration and Roles

Operations

Collaboration in Inkpilots is managed through three connected layers: workspace membership, permission structure, and author identity. Together they decide who can enter the workspace, what they are allowed to do, and how contributors appear across published content.

This page explains the current collaboration model in the product and how teams should use it operationally.

What this area is for

Use collaboration and role settings when your team needs to:

  • invite people into a workspace,
  • assign workspace-level authority,
  • create custom editorial capability roles,
  • remove members when access is no longer needed,
  • manage each member’s public author identity.

There are three default roles which are member, editor and admin. You can create default roles and assign roles to your team members.

This is not only an access-control layer. It is also a workflow-governance layer.

The current collaboration model

Inkpilots currently separates collaboration into three practical parts.

Workspace members

The members tab manages who belongs to the workspace. The current member flow supports:

  • inviting a member by email or user identifier,
  • assigning a base workspace role,
  • optionally attaching a custom editorial role,
  • viewing joined or invited members,
  • removing non-owner members.

Workspace roles

The base workspace role determines broad authority. The current member UI works with the familiar workspace role levels:

  • owner,
  • admin,
  • member.

These roles are the coarse-grained authority model for the workspace itself.

Editorial roles

Inkpilots also supports custom editorial roles built from capability sets. The current editorial roles tab lets teams:

  • create a custom role,
  • name and describe that role,
  • choose capabilities by group,
  • list existing custom roles,
  • delete roles that are no longer needed.

This is where the system becomes more precise than a simple owner-admin-member split.

Why custom editorial roles matter

Not every contributor should have the same authority just because they share the same workspace.

Custom editorial roles are useful when a team wants to separate responsibilities such as:

  • planning,
  • assignment management,
  • editing,
  • approval,
  • publication-related actions.

In practice, this helps teams avoid two common mistakes: granting too much power to people who only need a narrow capability, or forcing multiple different jobs into one generic role.

Member author identity

Inkpilots also includes a member author identity surface. This is distinct from access control.

The current author identity flow lets a member maintain:

  • display name,
  • role title,
  • profile image,
  • social links such as Twitter, LinkedIn, GitHub, and others.

This matters because the person who can edit content is not always the same as the identity the workspace wants to present publicly. Author identity gives each member a deliberate publishing profile instead of leaving attribution undefined.

How to think about the three layers together

These three layers answer three different operational questions:

  • Membership: who is inside the workspace?
  • Permissions: what can they do?
  • Author identity: how should they appear publicly?

Good collaboration design keeps those questions separate. A person can be powerful internally without needing a strong public author profile. Another person can have a clear author identity without needing broad administrative rights.

Recommended operating practice

Use base roles for broad authority

Reserve owner and admin privileges for people who actually govern the workspace.

Use editorial roles for workflow precision

If the team needs more granular control, define custom capability-based roles instead of overloading the base workspace roles.

Keep author identity deliberate

If published work should carry a real contributor profile, maintain the member’s author identity properly instead of leaving attribution inconsistent.

Remove access when it is no longer needed

Workspace membership should reflect the active operating team, not historical convenience.

Common mistakes to avoid

  • Treating all contributors as identical workspace members.
  • Granting admin-level power when a custom editorial role would be enough.
  • Ignoring public author identity until after content is already attributed.
  • Letting old members keep access after their role in the workflow has ended.

How this page connects to the rest of the handbook

Use this page together with:

Related guides