Stakeholders
The Stakeholders tab of a project's People pages: the client's sponsor, product owner and approvers, Zuse's own leads and third parties, each with a side, a role, a weight and the approvals that name them; adding, editing and removing them, and what a guest sees.
By the end of this page you will have written down who a project answers to, know every field a stakeholder carries and what reads each one downstream, know how the four approval flags steer the approvals, sign-offs and reports to come, and know what a client guest is shown of the record.
A stakeholder is a person the project answers to: the client's sponsor who pays for it, the product owner who ranks the backlog, the people who sign off requirements, UAT runs and releases, Zuse's own account manager or architect, and third parties such as an auditor or a vendor. A stakeholder is a row on the record, not an account; the sponsor is on it whether or not they ever sign in, and when they do sign in as a guest the row is linked to their account so the approvals that name them reach the person who decides.
The Stakeholders tab is the first of the project's People pages; the second is Personas, who the project is built for.
Before you begin
| You want to | You need |
|---|---|
| Open the Stakeholders tab | stakeholder:view-any on the project. Every staff role has it; a client guest has it through their project membership. |
| Add a stakeholder | stakeholder:create, through your role on the project or your team role, or to own the team. Business analysts and project managers have it by default. |
| Edit one | stakeholder:update. |
| Remove one | stakeholder:delete. |
| Link a stakeholder to an account | The person to be a member of the team already, usually a guest invited to the project. |
The page lives under a project: open the project from the selector or the registry and choose People in the sidebar's Selected Project group. The entry is badged with the number of stakeholders on the record, and the tab strip above the table switches between Stakeholders and Personas.
Read the stakeholders
The table lists one stakeholder per row, in the project's order:
| Column | What it shows |
|---|---|
| Stakeholder | The name, with the title and the organisation beneath it. Press the name to open the detail flyout. |
| Side | Whose side they speak for: client, Zuse or a third party, as a coloured badge. |
| Role | What they do for the project: sponsor, product owner, architect and so on, with its icon. |
| Weight | How much their word carries and how closely they follow the project, as two badges, and their default RACI letter. Staff only. |
| Approves | Which approvals name them: Requirements, UAT and Releases, or Nothing. |
| Updated | How long ago the record last changed. |
| Row menu | View Stakeholder, Edit Stakeholder, Activity, Remove Stakeholder. |
Sort by stakeholder, side, role, weight or updated by pressing a column heading; press it again to flip the direction. Above the table, narrow the list with the search box (words in the name, the email, the organisation or the title), the side list, the role list and the approval list, which keeps only the people that approval names. The filters travel in the page address, so a filtered list can be shared; Clear Filters on the empty state drops them all.
Add a stakeholder
- Press New Stakeholder.
- Type the Name, and the Title and Organisation if you know them.
- Pick the Side: Client for the people who commissioned the project, Zuse for the people on your own side who speak for it, Third party for everyone else.
- Add the Email and the Phone under Contact. The email is unique among the project's stakeholders and is where approvals and reports will reach them.
- Under Role and Weight, pick the Role, rate their Influence and Interest, and set a RACI Default if they will have a standing letter on the project's epics.
- Under Approvals, switch on what they decide: Approves requirements, Signs off UAT, Approves releases, and whether they Receive status reports.
- If they already have an account, pick it under Linked Account.
- Put what the team should know in the Notes: how they like to be reached, what they care about, what to avoid. A guest never sees them.
- Press Add Stakeholder.
The stakeholder appears in the table at once and stakeholder.created goes out to every endpoint
subscribed to it.
A name is all it needs
The side defaults to the client, the role to Other, both ratings to Medium and the three approval flags to off; status reports are on. Fill in the rest as the intake proceeds, and let Heimdall propose the sponsor, the product owner and the approvers from the brief.
Open a stakeholder
Press a stakeholder's name, or View Stakeholder in its row menu, to open the detail flyout: the side and role badges, the name with the title and organisation, the four Approves lines with a tick on each that applies, then for staff the Email and Phone, the Influence, Interest and RACI Default badges, the Linked Account and the Notes, and the created and updated stamps. From the flyout, Edit, Activity and Remove are one press away.
A link such as /projects/<project>/people?show=<id> opens the tab with that stakeholder's flyout
already open; notifications and Heimdall's buttons use it.
Edit a stakeholder
- Press Edit Stakeholder in the row menu, or Edit in the flyout.
- Change what you need. The same rules as adding apply: the email stays unique within the project, and a linked account must be a member of the team and linked to one stakeholder only.
- Press Save Changes.
Every change travels as stakeholder.updated with its old and new values. An edit that changes
nothing announces nothing.
Remove a stakeholder
Remove Stakeholder in the row menu, or Remove in the flyout, opens a confirmation. Removing takes the stakeholder and their activity history off the record; there is no undo. Approvals that will name stakeholders are not here yet; once they are, a stakeholder with decisions on the record will be kept rather than removed.
What a guest sees
A client guest invited to the project sees the Stakeholders tab with every stakeholder on it, because the client knows who speaks for them: the name, title and organisation, the side, the role and the four approval lines. The email and phone, the influence and interest, the RACI default, the linked account and the notes are not shown, and the guest's own API token leaves those fields out of the payload rather than nulling them.
All the fields
What happens next
- Every add, edit and removal is written to the stakeholder's activity history with who did it and where from.
- The
stakeholder.created,stakeholder.updatedandstakeholder.deletedevents go out to every endpoint subscribed to them. - The approval policies, the RACI on each epic, the status reports and the digests will read the flags, the ratings and the RACI default as those modules land, which is why they are captured now.
Heimdall on this page
Heimdall reads the stakeholders through the same tools the MCP server offers and carries the open project as its context.
Adding and shaping stakeholders is a person's work: Heimdall and an agent over MCP read the record and never write to it.
From the API and MCP
Stakeholders API
List, get, add, change and remove stakeholders over REST.
list_stakeholders and get_stakeholder
The two MCP tools that read a project's stakeholders as the token sees them.
Permissions
| Action | Permission |
|---|---|
| See the stakeholders | stakeholder:view-any; a guest sees them without the internal fields |
| Open a stakeholder | stakeholder:view |
| Add a stakeholder | stakeholder:create, or owning the team |
| Edit a stakeholder | stakeholder:update, through a project role or a team role |
| Remove a stakeholder | stakeholder:delete |
| Read or restore its versions | stakeholder:view to read, stakeholder:update to restore; never a client guest |
Frequently asked
Related
- Personas — who the project is built for
- Members and guests — inviting a stakeholder as a guest
- Status reference — sides, ratings and RACI letters
- Revisions and versions — every save kept, any version put back
stakeholder.*webhook events
How is this guide?
Last updated on
Environments
The Environments page of a project: development, staging, UAT and production with their addresses, branch and flags; the scheduled health check; freezing changes; and what a client guest sees of it.
Personas
The Personas tab of a project's People pages: the archetypal users the project is built for, with their goals, frustrations, habits, proficiency and devices; adding, editing, archiving, restoring and deleting them.