Workspace and collaboration
Invite people to a Delegate workspace, understand seats and the plan, choose roles, grant access per project, and know what each role can and cannot do.
- Availability: Experimental
- Evidence: Read from source
- How-to guide
Before you start
- To invite, remove, change roles or grant project access you must be an Administrator of the workspace. Everyone else reads this screen.
- The Free plan carries one person. Inviting anyone needs the Paid plan, which only the person who operates the installation can record. No price exists: see the plan.
- A Beyond Accounts organization gives nobody a seat here. Delegate does not read Accounts organizations at all.
Open the workspace
Choose Workspace settings in the sidebar. The page shows the workspace name, "Projects, the people who work on them and what each of them may do.", and Your seat: with your role. It has four panels: People, Project access, Workspace name (administrators) and Plan.
If you see "This workspace cannot be read." with "Your credential does not belong to a workspace. Sign in with your account to see yours.", you are signed in with a server-configured access key, which has no workspace.
Invite someone
- In People, check the line "{taken} of {limit} seats taken". An invitation needs a free seat.
- Fill in Email address. The hint is the rule: "The seat becomes theirs when they sign in with this address verified by their provider."
- Choose a Role: Administrator, Member or Viewer. The default is Member.
- Choose Send invitation.
Expected outcome: "Saved.", and the address appears in People with the state Invited. The seat is taken from this moment.
| You see | Meaning |
|---|---|
| "The free plan carries one person. Adding collaborators needs the paid plan." | The workspace is on Free and its seat is taken |
| "That address already holds a seat or an invitation." | The address, or the person behind it, already has a seat or an open invitation here |
| "Check the required fields and their formats." | The address is not a valid email address |
A newly invited Member or Viewer sees no project until you grant access.
Roles
A seat has one of three roles. The person who operates the installation and the agents are not seats; they are listed because you will see their labels.
| Label | What it is |
|---|---|
| Administrator | A seat that administers the workspace and holds every permission in every project of it, with no grant needed |
| Member | A seat that can act only in the projects it was granted, and only with the permissions of that grant. In a project it acts as Manager, which is the label its profile menu shows |
| Viewer | A seat that only reads the projects it was granted, whatever permissions the grant records |
| Owner | Not a seat: the person who operates the installation, signed in with a credential configured on the server |
| Agent | Not a person: a machine credential bound to one project |
What each one can and cannot do
This table is built from the rule table the server applies to every action, not from what the screens happen to show. "Granted" means a Member needs that permission in that project.
| Action | Administrator | Member | Viewer | Agent |
|---|---|---|---|---|
| Read a project | Every project of the workspace | Granted projects | Granted projects | Its own project |
| Register a request, edit your own request | Yes | With Register requests | No | Registers requests when configured to submit; never edits |
| Comment on a request | Yes | With Comment | No | Yes |
| Answer an intake question; approve or return a proposed requirement; dismiss or separate a request; group requests into a batch | Yes | With Take decisions | No | Never |
| Set priority; create, order and approve a planned release; launch development | Yes | With Take decisions | No | Never |
| Answer a blocker; accept or return a result; authorize correction work; resolve an uncertain dispatch | Yes | With Take decisions | No | Never |
| Create a version; request a test deployment; accept or reject a test; approve for production | Yes | With Take decisions | No | Never |
| Propose a refinement or a domain change | Yes | With Take decisions | No | When configured to submit |
| Import records from the source system | Yes | With Configure the project | No | No |
| Analyze a request, ask a question, propose a requirement, claim work, report progress, report a blocker, resume, submit a result | No | No | No | Yes, within its configured capability |
| Register a project; rename the workspace; invite, remove, change roles; grant and revoke project access | Yes | No, whatever is granted | No | No |
| Record the plan; configure agent triggers | No: only the Owner | No | No | No |
Two consequences are worth stating plainly:
- An agent can never approve, accept, launch or publish anything. Every row marked "Never" is a human decision, and the server refuses an agent that tries.
- The settings under Infrastructure (environment references, delivery configuration, agent triggers, resource inspection) are offered only to the Owner. A Member with Configure the project can use Manual import and nothing else of the configuration.
Give someone access to a project
"Holding a seat is not permission to act. Administrators already hold every permission in the workspace's projects."
- In Project access, choose the Project and the Person. Only people whose seat is Active are listed; an invited person must sign in first.
- Under Permissions, tick any of Register requests, Comment, Take decisions and Configure the project. Read comes with any grant.
- Choose Grant access.
Expected outcome: "Saved.", and a row with the project, the person and their permissions. Granting again to the same person replaces their permissions in that project.
To withdraw it, choose Revoke on the row. The person loses the project immediately, not when their session would have expired: what someone may do is rebuilt on every request. The record of the grant is kept.
Change a role or remove someone
- Change a role: open Change someone's role, choose the Person and the Role, then Save role.
- Remove: choose Remove on the person's row. Their seat and every project access it carried are withdrawn together, and the row stays with the state Removed, so who worked in the workspace remains readable.
| You see | Meaning |
|---|---|
| "A workspace needs at least one administrator." | You tried to remove, or change the role of, the last Administrator |
| "The person who owns the workspace cannot be removed from it." | The person who started the workspace can neither be removed nor stop administering it |
| "That person does not hold a seat in this workspace." | You tried to grant access to someone without an active seat |
The plan
Plan shows Free or Paid, the sentence that explains it, and always this: "No price, subscription or payment exists in Delegate. The plan records which seat limit applies; nothing is charged."
| Plan | Seats | Cost |
|---|---|---|
| Free | One person | Nothing. No price exists |
| Paid | No limit is decided; the screen shows "unlimited" | Nothing is charged. No billing exists |
Only the Owner sees the form that records a plan (Plan, On whose authority, Record plan). A plan that carries fewer seats than the workspace already uses is refused with "The workspace has more people than that plan carries."
When access is denied
Delegate answers a project you may not see exactly as it answers a project that does not exist: "That record does not exist or you cannot access it.", under "This project could not be loaded." with Try again. It never confirms that a project of another workspace, or one you were not granted, exists. If you expected to see it, ask a workspace administrator for a grant.
An action your role or grant does not allow answers "Your role does not allow this action." Most such controls are disabled before you try. The screens also say why: "You do not have permission to register requests in this project.", "You do not have permission to comment in this project."
Limits
Next action
Granted someone Register requests? Point them to Requests.
Related: Identity and resource permissions · Account, organization and product workspace · Delegate recovery