Engagement and audit

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.

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.

Every client-side action — login, login-failed, magic-link redemption, document download, approval submission, comment post, profile update, reminder sent — writes a client activities row with occurred at, from IP, and user agent. The Client Activity Audit view + the Approvals Decision Audit report give Portal Manager, Account Manager, and Admin an auditable ledger that answers “what did this client see, when, and from where” for any external data-subject request. Client users themselves never see client activities (the audit log is internal-only by design).

Count distinct eligible recipients and actions at the correct scope. Keep provider delivery receipts separate from authenticated client activity. Restrict IP addresses and signatures to the approved retention and access policy. 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. Audit client activities is append-only and restricted to authorized internal roles, with configured retention for IP addresses, signatures and user agents. Reports count eligible recipients and distinct actions at the correct project scope. Revoke outstanding links and membership on deactivation while preserving historical decisions. Expected revisions protect edits and command keys protect retries. These controls supply evidence for customer policies; no regulatory certification is asserted.

• Client Activity Audit (last 30 days) — Inspect recorded client actions within the authorized audit scope.