For Clients
The guest's view of a project: the approved record, the approvals assigned to you, and what stays on the team's side of the line.
By the end of this page you will know what a client guest account is, what it shows you, what it asks of you, and what it keeps from you on purpose.
A client guest is a stakeholder of one or more projects with an account of their own. Zuse Technologies invites you by email; you sign in with a password or a passkey, and you land on the projects you were given, nothing else. The team sees the same application; you see its client face.
What you see
- The approved record of each project: epics, requirements, business rules and use cases from the moment the team approved them, the stakeholders and personas, the glossary, the data dictionary and the design references. Drafts and work in review stay on the team's side until they are approved.
- The baselines of each project from the moment the team froze them, with the records each holds at the version that was frozen, and the change requests you raised or asked for, with their impact level and schedule once the team wrote them.
- The documents the team shares with you: the final business requirements document and software requirements specification of each project, exactly as the project manager approved them, and the copies they superseded.
- The approvals assigned to you: when a policy names your stakeholder seat and the team submits a record for review, or sends you a scope baseline to sign, it appears under Approvals in your sidebar with what the team wrote for you.
- Your notifications: an approval that waits on you, the decisions made on what you signed, and later the releases, incidents and tickets of your projects.
What you do
- Approve, request changes or reject what names you, with a reason where the project asks for one; every verdict is signed and kept. See approving as a client.
- Sign the scope: a frozen scope baseline comes to you for signature like any approval, and stands signed when every stakeholder asked has agreed. See signing off the scope.
- Raise a change request against a signed baseline in your own words, and co-sign its impact when the team sends it to the approvers.
- Comment where the team let clients comment; your comments are visible to everyone on the project.
- Read the documents shared with you: the final BRD and SRS of each project, under Documents in the project's sidebar. See documents shared with you.
- Later in the programme: sign off UAT runs, follow releases and incident status, and raise and follow support tickets.
What stays with the team
Estimates, time logs, internal comments, repositories and environments other than the UAT and production addresses, every AI control, the drafts behind an approved record, and the approvals that do not name you. These are hidden in the application's services, not merely on the screen, so an API token minted for a guest sees exactly what the guest sees.
Approving as a client
The approval that names you, the three verdicts, and what each does.
Signing off the scope
What a frozen baseline is, how the sign-off reaches you, and how you ask for a change afterwards.
Documents shared with you
The final BRD and SRS of your projects, where they appear and what their statuses mean.
Notifications
Where the approvals class and the rest are delivered to you.
Invitations
How the team invites you and how you accept.
How is this guide?
Last updated on
Permissions & Safety
Who may use Heimdall, how a team member's role bounds what it can do, the confirmation gate on anything that changes what exists, what the activity log records, what the model is shown and what it is never shown, and the models behind it.
Approving as a Client
What an approval that names you looks like, how to approve, request changes or reject it with a reason, what your verdict does, and what the team sees afterwards.