Portal Adoption Funnel
Per PortalSite: total invited, activated, active-30-day, active-7-day, with invite-to-activate and activate-to-engaged conversion rates. The Portal Manager's adoption KPI.
Portal branding and access
Create a recognizable client workspace with explicit access to each shared project.
Approval conditions
When a client engagement winds down or a ClientUser leaves the customer side, Portal Manager flips ClientUsers.Status: Active → Suspended (temporary) or Deactivated (permanent).
Active
| Portal Code | Name | Account | Subdomain Slug | Custom Domain | OAuth Provider |
|---|---|---|---|---|---|
| PC-539 | Site 281 | ACC-549 | SS-294 | CD-543 | None |
| PC-803 | Site 504 | ACC-389 | SS-446 | CD-382 | |
| PC-628 | Site 498 | ACC-775 | SS-270 | CD-689 | Microsoft |
| PC-341 | Site 146 | ACC-163 | SS-796 | CD-264 | Okta |
| PC-352 | Site 528 | ACC-598 | SS-591 | CD-439 | OneLogin |
| PC-886 | Site 577 | ACC-840 | SS-422 | CD-345 | None |
Brand and site setup
Admin configures the foundation: BrandThemes (color palette, logo, typography defaults — one per customer brand or per delivery-team brand), EmailTemplates (per-event branded templates for invitation, document notification, approval request, decision callback, status update, comment notification, weekly digest, and inactive-user reminder), and the PortalSites master (one row per Account tenant — PortalCode, Account, BrandTheme, SubdomainSlug, optional CustomDomain, OAuthProvider if SSO, MagicLinkEnabled, DefaultEmailTemplate, Owner Portal Manager). Brand changes that affect a live PortalSite flow through the MDM approval workflow with Admin sign-off; email templates preview-render against a fixture row before publish.
Project exposure
Portal Manager picks which internal Projects (read from Project Management) to expose on each PortalSite via the PortalProjects line items: snapshots the ProjectName, sets DisplayOrder, marks Status: Active. A Project hidden mid-engagement flips to Status: Hidden rather than being deleted, so historical DocumentShares, ApprovalRequests, and ClientActivities keep their referential anchor for audit.
Client user invitation
Portal Manager creates a ClientUsers row (FullName, Email, PortalSite, Account, ClientRole: Approver / Collaborator / Viewer) and grants per-project access via PortalUserAccess rows (one per PortalProject with AccessLevel: View / Comment / Approve). On Status: Invited set, the client-user-invite workflow fires via the configured record event. A configured workflow service provisions the OAuth / SSO entry when PortalSite.OAuthProvider is set, generates a MagicLinks row with Purpose: InviteSetup and ExpiresAt: now + 7 days, and notification service delivers the branded invitation using the PortalSite’s themed EmailTemplates row. The client clicks the link, completes setup (password or SSO bind), and the magic-link auth handler flips ClientUsers.Status: Invited → Active and stamps ActivatedAt.
Keep the decision trail useful
An active client role does not grant every project. Check the site, user and project grant together. Suspending a user or hiding a project must also close access through existing links. 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.
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 reportsBranded Email Send Volume
Per EmailTemplate per PortalSite per week: sends, opens (via DigestOpen MagicLinks redemption), bounces (via integration callback). Surfaces template fatigue and deliverability issues.
Roles 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