Comment Thread Activity
Per PortalProject in the trailing 30 days: open threads, replies, ClientUser participants, internal participants, mean time-to-first-reply. Surfaces stalled threads and disengaged projects.
Conversations
Keep feedback attached to the document, request or update the conversation is about.
ActivePostedAt >= today − 14 days
| Posted At | Parent Type | Portal Project | Author Client User | Author Internal User |
|---|---|---|---|---|
| DocumentShare | PP-2886 | GK | AIU-378 | |
| ApprovalRequest | PP-4603 | LR | AIU-370 | |
| StatusUpdate | PP-1143 | WZ | AIU-379 | |
| DocumentShare | PP-5825 | NN | AIU-639 | |
| ApprovalRequest | PP-5299 | UD | AIU-496 | |
| StatusUpdate | PP-1444 | EC | AIU-571 |
Comment threads
ClientUsers (Approver / Collaborator tier) and internal users (Project Manager, Account Manager, Internal Collaborator) post Comments rows on a DocumentShare, an ApprovalRequest, or a StatusUpdate — the ParentType enum routes the anchor. Replies write to CommentReplies line items in chronological Sequence. On each new Comment or CommentReply, the comment-thread-notify workflow fires via the configured record event. A configured workflow service resolves thread participants (the original Comment author plus everyone who has replied plus any @email-mentioned ClientUsers parsed from the body), and notification service notifies each participant once per thread per hour (debounced) with the branded comment template and a deep-link back to the thread. Mention parsing only resolves to ClientUsers within the same PortalUserAccess scope; cross-account mentions are silently dropped.
Client lifecycle and deactivation
When a client engagement winds down or a ClientUser leaves the customer side, Portal Manager flips ClientUsers.Status: Active → Suspended (temporary) or Deactivated (permanent). On Suspended, the auth handler refuses login and refuses magic-link redemption; on Deactivated, all outstanding MagicLinks flip to Status: Revoked and PortalUserAccess rows flip to Status: Revoked. Historical DocumentShares, ApprovalRequests, ApprovalDecisions, Comments, ActivityFeed, and ClientActivities retain the decision history under the configured retention policy; access is removed immediately and sensitive fields follow that policy.
Keep feedback in the right audience
A collaborator may participate in a project without being allowed to approve a deliverable. Keep these actions separate. The comment can explain a concern and mention an eligible participant, while the formal approval remains addressed to the named approver on ApprovalRequests. A favorable comment does not close that request and a negative comment does not change the recorded decision.
If a document is shared with a limited set of clients, its thread follows that same audience. A reply cannot make the discussion visible to every project member. Check the parent record and current grant when reading a thread, posting a reply or sending a notification. When a participant loses access, old notification links must no longer open the discussion for that person.
Follow up without duplicating the conversation
Keep replies in sequence under the original comment. Notifications should bring eligible participants back to that thread, rather than creating a second decision record. Review an interrupted submission using its original command identity so a retry does not post the same response twice. An internal collaborator can help explain the shared work within their project assignment, while a client Viewer continues to read without gaining comment permissions.
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.
Reports
All reportsRoles and permissions
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.
Related processes
Document publishing to acknowledgment
Make a protected project document available to the intended client audience and record explicit acknowledgment.
3 stages · 0 approvals
Approval request to source update
Capture the named client’s decision and reconcile the result with the originating application.
3 stages · 1 approval
Project update to client follow-up
Keep project communications relevant and follow up using permitted engagement evidence.
4 stages · 0 approvals