These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Client Collaboration Portal
- Features
- Conversations
Conversations
Keep feedback attached to the document, request or update the conversation is about. Every thread and reply inherits its parent’s project and audience. Mentions cannot expand access, and deleted or hidden comments remain subject to audit and retention rules.
OverviewOpen Comment Threads (Internal)×
Client Collaboration Portal · Conversations
New
Open Comment Threads (Internal)
Comments
| Posted at | Parent type | Portal project | Author client user | Author internal user | |
|---|---|---|---|---|---|
| Document share | Reception desk redesign | Nolan Okeke | Tessa Moreno | ||
| Approval request | Atrium lighting upgrade | Nolan Okeke | Arun Sethi | ||
| Status update | Atrium lighting upgrade | Leila Watanabe | Dalia Brooks | ||
| Document share | Courtyard landscape refresh | Jasper Haddad | Kenji Rahman | ||
| Approval request | Lobby accessibility works | Leila Watanabe | Nora Castillo |
6 of 6 records
Tessa MorenoComments · CMM-43373
Document sharePortal projectReception desk redesign
Author client userNolan Okeke
What you can do
Comment threads
Client users (Approver / Collaborator tier) and internal users (Project Manager, Account Manager, Internal Collaborator) post Comments rows on a document share, an approval request, or a status update — the parent type enum routes the anchor. Replies write to comment replies line items in chronological Sequence. On each new Comment or comment reply, 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 client users 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 client users within the same portal user access scope; cross-account mentions are silently dropped.
Client lifecycle and deactivation
When a client engagement winds down or a client user leaves the customer side, Portal Manager flips client user status: Active → Suspended (temporary) or Deactivated (permanent). On Suspended, the auth handler refuses login and refuses magic-link redemption; on Deactivated, all outstanding magic links flip to Status: Revoked and portal user access rows flip to Status: Revoked. Historical document shares, approval requests, approval decisions, Comments, activity feed, and client activities 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 approval requests. 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.
What your team sees
- Open Comment Threads (Internal) — Follow unresolved project conversations within the permitted account audience.
What it keeps track of
Data model- Comments
- Discussion threads on shared artifacts — a document share, an approval request, or a status update. One Comment is the root of one thread; replies live in comment replies.
- Comment replies
- Reply lines within a Comment thread — append-only chronological list. Mention captures handled inline in the body via
@emailsyntax. - Document shares
- A document published from an internal source system (workflow-dms, Project Billing Invoices, Project Management deliverables) to the portal. The publish record points at a file URL and tracks the audience scope, acknowledgment requirement, and lifecycle.
- Approval requests
- A request for a client decision — a deliverable sign-off, a change order, an invoice approval, a milestone confirmation. Routed to a named
RequestedFromClientClient user; resolves into one or moreApprovalDecisionsand triggers the source-record callback. - Status updates
- A published status update from the internal team to the client side of a Project. Carries Title + Body + Audience scope + publish metadata; fans out to subscribed client users via portal feed and email on publish.
Who uses it
Permissions- Internal Collaborator
- And Client User — Collaborator participate within assigned projects.
- Client User — Approver
- Can also comment. Viewer remains read-only.
Set up Client Collaboration Portal your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.