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
- Project updates
Project updates
Share a consistent project update with exactly the audience that should receive it. Draft updates stay internal. Validate named recipients within the project before publication and recheck audience permissions for the activity feed, direct links and outgoing notifications.
OverviewRecent Status Updates (Internal)×
Client Collaboration Portal · Project updates
New
Recent Status Updates (Internal)
Status updates
| Update number | Title | Portal project | Health flag | Published by | Published at | |
|---|---|---|---|---|---|---|
| SU-62280 | East Hall demolition complete | Reception desk redesign | On track | Tessa Moreno | 07 Oct | |
| SU-21300 | Atrium fixtures ready for review | Atrium lighting upgrade | At risk | Arun Sethi | 05 Oct | |
| SU-33183 | Courtyard planting on schedule | South wing signage | Off track | Dalia Brooks | 06 Oct | |
| SU-40488 | Lobby access review underway | Reception desk redesign | Complete | Kenji Rahman | 01 Oct | |
| SU-69407 | Level two framing complete | Level two workspace fitout | On track | Nora Castillo | 01 Oct |
6 of 6 records
East Hall demolition completeStatus updates · SU-62280
On trackPortal projectReception desk redesign
Published byTessa Moreno
Published at07 Oct
What you can do
Status updates
Project Manager publishes a status updates row per Project (Title, body markdown, health flag: On track / at risk / off track / Complete, Audience: All project clients / approvers only / named recipients). 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 client users with portal user access to the update’s portal project, optionally filtered to Approvers-only), record service bulk-creates an activity feed row plus per-recipient magic links rows, and notification service fans out the branded status-update email to all subscribed client users.
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 client activities rollup per own-account client user, 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 client users row where Status = ‘Active’ AND last login at < 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 client activities row with activity type: Reminder sent.
Keep the decision trail useful
Draft updates stay internal. Validate named recipients within the project before publication and recheck audience permissions for the activity feed, direct links and outgoing notifications. Portal sites, portal projects and client users establish separate tenant and project boundaries. Bind each external login to client user principal ID; shared email addresses and Account text do not grant membership. Effective access is the intersection of active site, active client user, active portal project and active portal user access. 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 callback status 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. Notification deliveries 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.
What your team sees
- Portal Home (Client) — Read the project updates and activity allowed by current project access.
What it keeps track of
Data model- 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.
- Activity feed
- The chronological feed of portal-relevant events shown to client users on the portal home — published documents, new status updates, approval requests, recent comments. One row per event per portal project.
- Client users
- The external client user master — every person on the customer side who logs into the portal. Two-namespace separation from internal Users keeps the auth surfaces and audit logs clean.
- Portal user access
- Junction granting a client user visibility into one or more portal projects on a portal site. The portal-scope access pattern reads this table on every page render.
- Notification deliveries
- Delivery receipts for branded notifications; providers report delivery independently of client actions.
Who uses it
Permissions- Project Manager
- Publishes project updates.
- Account Manager
- Follows engagement. client roles read the audience permitted by their project grants.
Set up Client Collaboration Portal your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.