Document Acknowledgment Rate
Per RequiresAcknowledgment DocumentShare in the trailing 90 days: recipients, downloaded count, acknowledged count, percent acknowledged. Surfaces shares not landing with the right audience.
Project documents
Publish the right version of a document and see whether its intended recipients have acknowledged it.
PortalProject IN (current user's PortalUserAccess)Published
| Share Number | Document Name | Category | Portal Project | Published At | Requires Acknowledgment |
|---|---|---|---|---|---|
| DS-96451 | Document 896 | Deliverable | PP-3433 | 05 Sep | ✓ |
| DS-43860 | Document 501 | Invoice | PP-2327 | 27 Sep | ✓ |
| DS-34124 | Document 895 | Contract | PP-3562 | 21 Sep | no |
| DS-11286 | Document 572 | Report | PP-8855 | 14 Sep | no |
| DS-38888 | Document 756 | Reference | PP-9641 | 08 Sep | ✓ |
| DS-95682 | Document 373 | Other | PP-5005 | 20 Sep | no |
Document publishing
Project Manager publishes a document to the portal: creates a DocumentShares row pointing at the source document store FileURL (workflow-dms, Project Billing Invoices, or a Project Management deliverable), picks the PortalSite + PortalProject, sets Category (Deliverable / Invoice / Contract / Report / Reference / Other) and RequiresAcknowledgment. On Status: Published, the document-publish-notification workflow fires via the configured record event. A configured workflow service resolves every ClientUser with PortalUserAccess to the PortalProject, record service bulk-creates an ActivityFeed row plus per-recipient MagicLinks rows with Purpose: DocumentView, and notification service notifies each recipient with the branded template and the magic-link deep-link. ClientUsers click through, the magic-link auth handler resolves to the document viewer, the streamed download writes a DocumentDownloads row plus a ClientActivities row with ActivityType: DocumentDownloaded, and (when RequiresAcknowledgment = true) the client confirms via an in-portal action that flips DocumentDownloads.Acknowledged: true.
Magic-link lifecycle
Every fan-out workflow that needs a one-click email-to-portal entry generates a MagicLinks row with a server-side-only Token, a Purpose enum, optional TargetTable + TargetRecord deep-link, an IssuedAt, and an ExpiresAt. The inbound URL handler resolves the Token server-side, validates Status: Active AND ExpiresAt > now, flips Status: Used immediately on first redemption, stamps UsedAt + UsedFromIP, writes a ClientActivities row with ActivityType: MagicLinkRedeemed, and redirects to the deep-link. The magic-link-expiry workflow runs hourly via the configured schedule, finds every MagicLinks row where ExpiresAt < now AND Status = ‘Active’, and bulk-flips Status: Expired. Reissue is a Portal Manager action that generates a new row rather than extending the prior one.
Keep the decision trail useful
Keep source files protected and generate a short-lived download only after an access check. A notification or download event does not supply an acknowledgment. Scheduled withdrawal and revoked membership apply to old links too. 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. MagicLinks.Token stores only a one-way hash of a high-entropy token. Tokens are purpose, recipient, project, target and expiry bound, redeemed atomically once, and revoked on access removal. Opening an email link displays a confirmation page; link previews and GET requests cannot approve a decision. ApprovalAction requires a verified session and an explicit confirmation POST with expected request revision. Tokens and signatures never appear in analytics, application logs or audit exports. DocumentShares FileURL identifies a protected source; the backend obtains a short-lived scoped download URL only after access checks. Scheduled publication respects PublishStart and PublishEnd; archived or hidden content remains unavailable through old links. Only published documents and updates create client activity-feed entries. NamedRecipients contains validated active recipients within the project. Thread parents and every reply inherit the exact same audience; notifications and mentions cannot widen it.
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
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