Choose an agency client portal by testing a deliverable, its approval record and the separation between two client accounts. The client should see the right version and next action while unrelated work stays inaccessible. A progress dashboard is useful, but it does not establish approval authority or prove that account boundaries work.
Begin with a specific agency exchange: a draft is ready, the client reviews it, someone requests a change and an authorised person accepts a revision. Write down the participants and the records they need at each step. This gives your portal brief a practical shape and makes approval requirements visible before a platform demonstration starts.
What should the portal organise around a deliverable?
ERPNext projects can be divided into multiple tasks. ERPNext allows assignments at task level and project level. The ERPNext project documentation provides a starting point for organising agency work. Use a project for the overall engagement and propose tasks for identifiable deliverables. Ask the demonstrator to distinguish the person doing the work from the client responsible for responding to it.
An ERPNext project can be associated with a customer. Record the intended client relationship explicitly. A project title containing a client name is a convenient label, but your acceptance exercise should inspect the actual customer and access relationships. Include a project with a similar name under a different fictional customer so the test can reveal assumptions hidden by a tidy demonstration dataset.
Propose a deliverable card with a stable identifier, revision label, submission note, requested response and responsible reviewer. The card should make the next action understandable without opening a separate email chain. Treat these as requirements to demonstrate, not as features established by the existence of a project screen.
Who may view, comment and approve?
Website Users can be added to an ERPNext project to grant access. ERPNext documents attachment-viewing permissions for individual project users. These project access controls make it sensible to test both the project view and its attachments. A client who can open a task may still encounter an unexpected attachment permission, and a hidden task does not by itself establish that a copied file link is inaccessible.
Frappe users can hold multiple roles. Frappe roles describe permitted actions on a document type. The Frappe permission model means that the relevant question is the effective action available to a user, including their combined roles. Ask the administrator to explain each test account’s permissions. Then inspect the portal using that account rather than accepting an administrator’s view as representative.
Separate review from approval in the written requirement. A person may provide useful comments without authority to accept the agency’s work on behalf of the client. Define what acceptance means, whose identity is recorded and how a later revision affects the earlier decision. Request evidence for the proposed workflow; a generic edit permission is not an approval process.
| Participant | Proposed access | Evidence required in the rehearsal |
|---|---|---|
| Agency contributor | Prepare the assigned deliverable | Correct task and revision appear |
| Client reviewer | Read and comment on authorised work | Comment attaches to the intended version |
| Client approver | Record the acceptance decision | Identity and revision remain distinguishable |
| Other client | Access only its own work | Direct link to unrelated work is denied |
| Former participant | Follow the agreed removal policy | Previous access no longer grants the tested action |
| Anonymous visitor | Follow the intended public boundary | Private test attachment cannot be opened |
How should account separation be demonstrated?
Frappe permission levels can separate field groups by role. This documented mechanism can inform the requirement for internal-only fields, but request a test of the actual configured portal response. Decide whether the client should see an internal note, a staff assignment or a working attachment. Inspect each deliberately; do not assume that a field’s position on an internal form determines its external visibility.
Frappe User Permissions can restrict documents by a Link field value. Use the documented per-user restriction model as a discussion point for customer-linked records. Ask which link defines the intended boundary and how it applies to the portal’s tasks, attachments and related records. Record the answer in the permission matrix instead of assuming that assigning a customer automatically secures every route.
Frappe assigns its Guest role to unauthenticated users as well as other visitors. Include an anonymous visitor test alongside the signed-in client accounts. Sign-out and restricted-account checks answer different questions. Retain the tested route and observed result so the configuration can be rechecked when a new page, download or portal function is introduced.
Original two-client rehearsal: a draft, a revision and an approval
This hypothetical exercise uses fictional Clients Cedar and River. Cedar has a landing-page draft labelled C-LP revision A; River has an unrelated campaign brief R-CB revision A. Prepare ordinary client accounts, a Cedar approver and an agency contributor. Use non-sensitive sample files in a separate test project.
Baseline card. List every test account and the project it should reach. Record the expected deliverable, attachment and available action. Have the project owner confirm this list before testing. An expectation written after seeing the application is a weak basis for deciding whether the original requirement was met.
Review card. Submit Cedar’s revision A with one clear requested response. Ask Cedar’s reviewer to open it and add a fictional change request. Inspect whether the message is attributable to the reviewer and recognisably connected to revision A. Ask the contributor to find that request using the proposed normal workflow.
Revision card. Prepare revision B with a short explanation of the change. Ask the client to distinguish the current version from the earlier one without relying on the contributor’s memory. Retain the relationship between the old comment and the new version. Overwriting the original file may make a demonstration look simpler while leaving the approval history unclear.
Approval card. Ask the designated approver to record acceptance of revision B. Then ask the ordinary reviewer to attempt the same action. Record both outcomes and the configuration responsible. If the product has no distinct approval function in the proposed scope, describe the missing requirement explicitly rather than renaming a comment as approval.
Isolation card. While signed in as River, attempt Cedar’s project route and a previously copied Cedar attachment link. Repeat the relevant checks anonymously. Record the route, account and observed response, with sensitive content excluded from the evidence pack. A denied navigation menu item is insufficient if a direct route remains available.
Departure card. Apply the proposed removal process to a test participant. Recheck the intended access boundary using an ordinary session and previously recorded routes. Ask what ongoing checks belong to the agency administrator. Keep any unresolved session or link behaviour visible in the decision record rather than claiming that removing a project label settles access.
What should be ready before a portal rollout?
Produce a short acceptance record containing the client boundary, deliverable structure, approval rule, attachment policy and account owner. Give every unresolved item a responsible person and a required demonstration. Keep the decision to accept a portal design separate from permission to import real client files or invite actual participants.
Prepare a controlled migration plan for any later rollout: identify existing records, preserve the source files, agree visibility and rehearse the transfer on a test copy. The portal should make the client’s next decision easier while preserving a clear boundary around unrelated agency work.
Connect the matrix to your business systems requirements and any custom portal development brief. To discuss the intended workflow, get started with the two-client rehearsal, the approval rule and the access questions still awaiting evidence.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.