Evaluate active site, client identity, project visibility and project grant together.
Roles and permissions
Separate portal administration, publishing, client decisions and read-only access.
How permissions work
5 rulesApply role, row, field and audience restrictions to APIs, downloads, feeds and notifications.
Only the named Client User — Approver can decide an addressed request.
External viewers cannot post comments or decisions.
Keep token hashes, signature evidence and internal activity logs restricted.
The roles
Owns the ClientUsers list and access grants for one or more PortalSites. The day-to-day operator of the external user lifecycle — invitations, role changes, suspensions, access reviews.
Internal Project owner. Publishes DocumentShares, ApprovalRequests, and StatusUpdates for own projects; reads ClientUser engagement on own projects.
Customer-success operator. Watches client engagement across an account portfolio, follows up on inactive clients, escalates disengagement risk to Project Managers and Portal Manager.
Limited internal contributor — a designer, engineer, analyst, or specialist who needs to participate in client conversations on own projects but not publish artifacts.
External client user with approval authority. Acts on ApprovalRequests routed to self; reads own portal content; participates in comment threads.
External client user with comment + read access. Same scope as Viewer but can post Comments and CommentReplies.
External client user with read-only access. The default tier for client stakeholders who need visibility but no contribution rights.