Collaboration And Project Access
Share projects with people and groups using explicit roles
Archflow supports direct project sharing and reusable groups. Project collaboration is separate from sharing a published documentation link.
Self-Hosted Organizations
In a single-org installation, administrators create accounts under Settings → Organization before granting project or group access. Members do not use public signup. Organization membership alone does not grant access to every project, and organization administrator/member roles are separate from the project roles below. See organization administration for provisioning, password resets, and offboarding.
Roles
| Role | Typical responsibility |
|---|---|
| Owner | Own the project or group and its highest-risk administration |
| Admin | Manage membership and access; ownership authority depends on the owning account or group |
| Editor | Change architecture content and participate in reviews |
| Viewer | Inspect project evidence without editing it |
Some high-risk settings remain limited by ownership, plan, or the specific resource even when a user has broad project access.
Share A Project
Open Project Settings → Sharing. You can:
- Share directly with an existing user by email
- Invite an email address that has not registered yet
- Share with a group you manage
- Choose an appropriate role
- Change a user or group's role later
- Remove access
Pending email invitations expire after seven days. Send a new invitation if the original expires.
Groups
Groups are useful for architecture guilds, platform teams, product areas, or recurring reviewers. A group contains members and can be granted access to several projects, avoiding repeated one-person shares.
Review group members, pending invitations, and shared projects regularly. A group's project role and a person's membership role are separate decisions.
Sharing And Ownership Are Separate
A share gives a person or group a project role. Ownership determines who controls the project and can transfer or delete it. Members of an owning group inherit access through their group roles.
Use Transfer ownership when ownership itself should change. Review the new owner and access consequences before confirming: the previous owner or owning-group members can lose inherited access, while explicit shares remain. Group ownership administration follows the group's roles, so do not treat every project Admin as an owner.
Invitations can target groups, including through supported batch-invitation flows. Review each recipient's group and role before sending. The project's share list and the group's member list answer different access questions.
Review Practice
- Give viewers access early enough to inspect evidence before a review.
- Reserve editor access for people expected to change the model.
- Use versions before parallel or experimental changes.
- Use private publication links for external readers who should not enter the project workspace.
- Remove obsolete group and direct shares rather than relying on institutional memory.