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.
Project updates
Share a consistent project update with exactly the audience that should receive it.
PortalProject.Project IN (current user's PortalUserAccess)OccurredAt >= today − 90 days
- AF-69608 · DocumentPublished af-12423 JunDocumentPublished
- AF-73970 · StatusUpdatePublished af-13620 JunStatusUpdatePublished
- AF-50740 · ApprovalRequested af-74924 JunApprovalRequested
- AF-11708 · ApprovalDecided af-84710 AugApprovalDecided
- AF-91127 · CommentPosted af-10904 JulCommentPosted
Status updates
Project Manager publishes a StatusUpdates row per Project (Title, BodyMarkdown, HealthFlag: OnTrack / AtRisk / OffTrack / Complete, Audience: AllProjectClients / ApproversOnly / NamedRecipients). On an authorized transition to Status: Published, the status-update-publish workflow fires via the configured record event. A configured workflow service resolves the audience (all ClientUsers with PortalUserAccess to the update’s PortalProject, optionally filtered to Approvers-only), record service bulk-creates an ActivityFeed row plus per-recipient MagicLinks rows, and notification service fans out the branded status-update email to all subscribed ClientUsers.
PublishedAt >= today − 30 days
| Update Number | Title | Portal Project | Health Flag | Published By |
|---|---|---|---|---|
| SU-62280 | Draft su-268 | PP-7900 | OnTrack | PB-138 |
| SU-21300 | Published su-283 | PP-7523 | AtRisk | PB-696 |
| SU-33183 | Archived su-769 | PP-2335 | OffTrack | PB-510 |
| SU-40488 | Draft su-968 | PP-3746 | Complete | PB-139 |
| SU-69407 | Published su-369 | PP-8994 | OnTrack | PB-612 |
| SU-70214 | Archived su-951 | PP-6269 | AtRisk | PB-739 |
Engagement watch and digests
Account Managers monitor own-account engagement via the Client Engagement Summary report and the Inactive Client Users view; Portal Managers watch the Portal Adoption Funnel and the Active Magic Links queue. The client-activity-digest workflow runs weekly Monday 09:00 local-time via the configured schedule, aggregates the trailing-7-day ClientActivities rollup per own-account ClientUser, and notification service delivers the branded digest with the per-account engagement summary and inactive-user callouts. The inactive-user-reminder workflow runs monthly on the first business day via the configured schedule, finds every ClientUsers row where Status = ‘Active’ AND LastLoginAt < now − 60 days, notification service delivers a branded re-engagement reminder with a fresh magic-link, copies the Account Manager + Portal Manager, and writes a ClientActivities row with ActivityType: ReminderSent.
Keep the decision trail useful
Draft updates stay internal. Validate NamedRecipients within the project before publication and recheck audience permissions for the activity feed, direct links and outgoing notifications. PortalSites, PortalProjects and ClientUsers establish separate tenant and project boundaries. Bind each external login to ClientUsers.PrincipalID; shared email addresses and Account text do not grant membership. Effective access is the intersection of active site, active ClientUser, active PortalProject and active PortalUserAccess. The role and grant must both permit the action. Every list, export, attachment, notification and direct API request rechecks this scope; hiding a card is insufficient. Decision callbacks use an allowlisted integration and an idempotency key. Record local decision and CallbackStatus separately: Pending, Failed or Unknown means the source application has not been confirmed updated. Retry the same command identity and reconcile unknown results before a replacement. NotificationDeliveries keeps event/recipient/template identity and provider receipts; an email open or send receipt is neither approval nor acknowledgment. Document acknowledgment requires an explicit authenticated action.
Modules
-
Portal branding and access
Create a recognizable client workspace with explicit access to each shared project.
-
Project documents
Publish the right version of a document and see whether its intended recipients have acknowledged it.
-
Client decisions
Ask a named client approver for a decision with the relevant evidence and a traceable outcome.
-
Project updates
Share a consistent project update with exactly the audience that should receive it.
-
Conversations
Keep feedback attached to the document, request or update the conversation is about.
-
Engagement and audit
Find stalled approvals and inactive client accounts while preserving a useful decision trail.
Roles and permissions
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.
Related processes
Portal setup to client access
Give clients a branded entry point and the specific project access their work requires.
3 stages · 1 approval
Document publishing to acknowledgment
Make a protected project document available to the intended client audience and record explicit acknowledgment.
3 stages · 0 approvals
Project update to client follow-up
Keep project communications relevant and follow up using permitted engagement evidence.
4 stages · 0 approvals