Collaboration
A workspace can hold more than one person. Everyone you invite works on the same apps, and what they are allowed to do is decided by one thing: their role.
Inviting people is part of the larger plans — see pricing for how many seats yours includes. A workspace on a solo plan is refused at the invitation, with the plan it would need.
Roles
| Role | Can do |
|---|---|
| Owner | Everything, including workspace settings and handing ownership on. Exactly one person. |
| Admin | Invite people, change roles, remove members; everything an editor can do. |
| Editor | Build and change apps, publish them, export them. |
| Viewer | Look, and nothing else. |
Owner is the person who created the workspace. It is not an invitable role: it moves only by being transferred, and only to someone who is already a member. The moment it moves, the previous owner stays on as a member.
Inviting someone
Owners and admins invite by email address and choose the role at the same time. An invitation to an address that has no PhiWebs account still works — the account is created when it is accepted.
A workspace can only invite as many people as its plan carries — and an outstanding invitation already occupies a seat, before anyone accepts it. A team of four with two invitations pending has six seats in use and cannot invite a seventh on a six-seat plan. Withdraw an invitation that is not going to be accepted and the seat comes back.
When the last seat is taken, the next invitation is refused and says so, rather than quietly adding someone you are not entitled to.
Managing people day to day — the member list, changing a role, removing someone — lives in Account & billing.
Working on the same app
Members of a workspace share its apps; there is no per-app membership list. The practical division is the role: editors change and publish, viewers read.
Publishing is worth calling out because it is the one action with an audience. Any editor can publish, and publishing is always deliberate — an app in front of customers does not change because a colleague opened the editor. See Publishing your app.
Seeing what changed
Changes are recorded as receipts, and a receipt names both the change and the person who accepted it. That makes the history of an app something you can walk rather than something you have to remember: open its version history and read back through the receipts.
How far back that history reaches depends on your plan.
See also
- Team management — the member list and its controls
- Publishing your app — who can put an app in front of people
- Visitor sign-in — your app’s own users, who are not workspace members