A useful client portal shows clients enough to participate without exposing every draft, internal discussion, or operating detail. That balance does not come from one “client access” switch.
Client portal permissions belong to the work they protect. Account membership controls entry. Tasks, Files, Live Chat, custom pages, and Deliverables each apply their own visibility rules.
Start with the client’s job
Before changing a setting, write down what each client contact needs to do. One person may upload source files. Another may review progress. A third may only need the final delivery.
This follows the principle of least privilege. The National Institute of Standards and Technology definition of least privilege says access should be limited to what someone needs for assigned tasks.
Apply that principle as an operating decision. Define what this person needs to see or change to complete their part of the engagement.
Review account membership before module settings
An account is the workspace for one client relationship in Sydnee’s client work platform. Team members work inside it, while portal users enter its client-facing experience.
Start your visibility review with the people list:
- Confirm that every portal user still belongs to the client relationship
- Remove access for contacts who no longer participate
- Add only the team members who need the account
- Check which client contact owns each request, task, or review step
Account access does not mean every member sees every item. It establishes who can enter the account. Each module still decides what appears after entry.
Treat navigation as orientation, not authorization
Portal navigation helps clients understand where to go. Built-in modules and custom pages can appear, hide, and change order based on current account settings and available content.
Hiding a navigation item is not the same as defining access to every record behind it. Review the module’s own rules as well. A clean sidebar should reflect the client’s workflow, but it should not become your only permission test.
The portal dashboard follows the same principle. Widgets appear only when the module, data, and visibility conditions support them. Do not assume that every client sees the same dashboard.
Check Tasks at the board, section, and task levels
Task visibility can change at several layers. A board can be available to everyone, limited to the team, or restricted to selected people. Sections and Tasks add their own client visibility and editability rules.
Review each layer in order:
- Confirm that the client should have access to the Task board
- Check whether any section contains internal stages or notes
- Review the visibility of each client-facing Task
- Decide whether the client can edit the Task or only follow it
- Sign in through a portal-user test account with the intended access and test the result
Read-only needs a precise meaning. A read-only Task prevents the client from changing the Task itself, but the current portal still allows comments. If the client should not participate at all, hide the Task instead of assuming read-only removes every interaction.
Keep internal planning, staffing decisions, and draft work on team-only boards, sections, or Tasks. Give clients access to the actions and progress that help them participate.
Review Files from the parent folder down
Files uses hierarchical access. A parent folder can limit what clients may do below it, so a child item cannot restore access that the parent removed.
Use the folder’s purpose to choose the right access:
- Full access: Clients can view and make permitted changes, including uploads and file management
- View only: Clients can browse and download without changing folder contents
- Hidden: The folder does not appear to that portal user
- Custom access: Selected people receive full or view-only access, while unselected people cannot see the folder
Comments and client versioning also depend on workspace, account, folder, and file settings. Review those controls when a visible file contains internal revisions or discussion.
Do not describe a hidden folder as encrypted or deleted. Hidden means the folder does not appear in that person’s portal. It remains part of the account for people who retain access.
The file review workflow shows how visibility, versions, and feedback work together during review.
Check who belongs to each conversation
Live Chat has separate membership rules for account conversations, channels, and direct messages.
An account conversation serves participants in one client account. Channels can include selected team members and client contacts. Direct messages connect two eligible people, and portal users cannot message one another.
Review client participation by conversation:
- Keep internal team discussions in team-only channels
- Add clients only to the focused channels they need
- Confirm that the team member still has access to the client’s account before relying on a direct message
- Review archived and active conversations when roles change
Calling a channel private describes its discovery and membership rules. It does not make a compliance, encryption, or retention claim.
Treat embedded tools as a separate access boundary
A custom portal page can display compatible third-party content inside the branded portal or open an external link. Sydnee controls the portal navigation item, but the provider controls its own sign-in, sharing rules, cookies, data, and availability.
Account-specific pages and Global pages require different checks. Account-specific means the navigation item belongs to one client account. Global means it appears across accounts. Neither setting creates matching permissions inside the embedded tool.
Before publishing an embedded page, sign in through a portal-user test account and confirm the provider shows the correct content to the correct person. Do not place a private editing URL, administrator page, credential, or unrestricted client data in embed code.
Understand what publishing a Deliverable changes
A Deliverable is a client-facing, view-only presentation created from an existing Files folder. Publishing changes the folder and its nested folders to view-only client access, replacing custom client permissions throughout that hierarchy.
That makes Deliverables useful for a final handoff, but unsuitable for ongoing private drafts. Prepare the folder, remove internal material, and confirm the hierarchy before publishing.
Clients can browse and download the finished work. A recorded view means the client opened the Deliverable. It does not mean approval, acceptance, or proof that every file was read.
Run a client portal visibility review
Review permissions whenever people, responsibilities, or engagement stages change. Use one named portal user as your test case and check the experience in this order:
- Account membership and portal entry
- Navigation items and dashboard widgets
- Task boards, sections, Tasks, and read-only behavior
- Files folders, individual access, comments, and versions
- Account conversations, channels, and direct messages
- Custom pages and the provider’s own audience settings
- Deliverable folders before publication
Record the reason for each visible surface in your operating checklist. “The client needs this to complete the review” is more useful than “this module is visible by default.”
Design access around real client roles
Good client portal permissions do not expose the whole workspace or hide every sign of progress. They give each person enough context and control to complete a defined job.
Book a Sydnee demo to review a real client access model. Bring the roles, working files, internal stages, and final handoff from one engagement so you can test each visibility boundary in context.
