Ask a named client approver for a decision with the relevant evidence and a traceable outcome.
When the internal team needs a client decision (sign off a deliverable, accept a change order, approve an invoice, confirm a milestone), Project Manager creates an ApprovalRequests row: picks Type, RequestedFromClient (a named ClientUser with role Approver), RelatedDocument if applicable, SourceTable + SourceRecord for the callback, optional RequiresSignature and ExpiresAt. The approval-request-routing workflow fires via the configured record event on record.created. A configured workflow service creates a MagicLinks row with Purpose: ApprovalAction and ExpiresAt matching the request, notification service delivers the branded approval template with the rendered Subject + Description and the magic-link URL to the confirmation page. The ClientUser clicks the link, the magic-link auth handler redirects to the approval action page, the client picks Approved / Rejected / RequestedChanges, optionally adds Comments and a captured signature blob, and on submit an ApprovalDecisions row writes (Sequence, Decision, Comments, SignatureBlob if captured, FromIP, UserAgent, SignedAt). The request Status flips to the matching enum and DecidedAt stamps.
On ApprovalRequests.Status: Pending → Approved or Rejected, the approval-decision-callback workflow fires via the configured record event. A configured workflow service reads SourceTable + SourceRecord, resolves the appropriate integration endpoint (Project Management Tasks for Deliverable / Milestone types, Project Billing Invoices for Invoice type, an org-defined ChangeOrders endpoint for ChangeOrder), and posts the decision back to the source — typically setting a ClientApprovalStatus enum and a ClientApprovalAt date on the source record. notification service notifies the internal RequestedBy Project Manager + the project’s Account Manager with the decision, the comments captured on ApprovalDecisions, and the link back to the request thread. A re-decision (e.g. Approver flips Rejected → Approved after a resubmit) writes a new ApprovalDecisions line with a higher Sequence and stamps the prior line Superseded: true.
Require the named approver, active project approval access, an unexpired request and the exact request revision. Keep a local decision distinct from the source application’s callback acknowledgment. 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.
Create a recognizable client workspace with explicit access to each shared project.
Publish the right version of a document and see whether its intended recipients have acknowledged it.
Ask a named client approver for a decision with the relevant evidence and a traceable outcome.
Share a consistent project update with exactly the audience that should receive it.
Keep feedback attached to the document, request or update the conversation is about.
Find stalled approvals and inactive client accounts while preserving a useful decision trail.
Per ApprovalRequest type (Deliverable, ChangeOrder, Invoice, Milestone): mean and p90 hours from RequestedAt to DecidedAt, broken down by PortalProject and RequestedFromClient. Surfaces slow approvers and slow approval categories.
Every ApprovalDecision in the period with ApprovalRequest, Type, ClientUser, Decision, SignedAt, FromIP, and the source-record callback status. The auditable decision register.
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.
CRUD on ClientUsers, PortalUserAccess, PortalProjects (add / hide / archive), and MagicLinks (reissue)Read on PortalSites, BrandThemes, EmailTemplates, DocumentShares, ApprovalRequests, StatusUpdates, Comments, ActivityFeed, ClientActivities for owned PortalSitesView ClientUsers.Email and ApprovalDecisions.SignatureBlobTrigger the client-user-invite workflow and issue ad-hoc magic-linksInternal Project owner. Publishes DocumentShares, ApprovalRequests, and StatusUpdates for own projects; reads ClientUser engagement on own projects.
CRUD on DocumentShares, ApprovalRequests, StatusUpdates, and Comments where the PortalProject.Project is one this user owns or is assigned to in Project ManagementRead on ClientUsers and ClientActivities scoped to own projectsRead on DocumentDownloads and ApprovalDecisions for own projectsCannot CRUD PortalSites, BrandThemes, EmailTemplates, or PortalUserAccess (Admin / Portal Manager own those)Customer-success operator. Watches client engagement across an account portfolio, follows up on inactive clients, escalates disengagement risk to Project Managers and Portal Manager.
Read on ClientUsers, ClientActivities, DocumentDownloads, ApprovalRequests, ApprovalDecisions, StatusUpdates, and ActivityFeed for ClientUsers within owned accountsReceive the client-activity-digest weekly email and the inactive-user-reminder ccCRUD on Comments and CommentReplies on own-account threadsCannot modify ClientUsers (Portal Manager owns), cannot publish documents or status updates (Project Manager owns)Limited internal contributor — a designer, engineer, analyst, or specialist who needs to participate in client conversations on own projects but not publish artifacts.
Read on DocumentShares, ApprovalRequests, StatusUpdates, and ActivityFeed for own projectsCRUD on Comments and CommentReplies on own-project threadsCannot publish DocumentShares, StatusUpdates, or ApprovalRequests (Project Manager owns)Cannot view ClientUsers.Email or ClientActivities| Posted At | Parent Type | Portal Project | Author Client User | Author Internal User |
|---|---|---|---|---|
| DocumentShare | PP-2886 | GK | AIU-378 | |
| ApprovalRequest | PP-4603 | LR | AIU-370 | |
| StatusUpdate | PP-1143 | WZ | AIU-379 | |
| DocumentShare | PP-5825 | NN | AIU-639 | |
| ApprovalRequest | PP-5299 | UD | AIU-496 | |
| StatusUpdate | PP-1444 | EC | AIU-571 |
External client user with approval authority. Acts on ApprovalRequests routed to self; reads own portal content; participates in comment threads.
Read on own PortalSite's exposed PortalProjects (via PortalUserAccess), DocumentShares, StatusUpdates, ApprovalRequests where RequestedFromClient = self, and ActivityFeed scoped to accessible projectsCRUD on ApprovalDecisions for own pending requests, Comments, CommentReplies, and DocumentDownloads (write on download)View MagicLinks issued to self via the inbound URL handler onlyCannot view other ClientUsers' email, cannot view ClientActivities, cannot access projects not granted via PortalUserAccessExternal client user with comment + read access. Same scope as Viewer but can post Comments and CommentReplies.
Read on own PortalSite's exposed PortalProjects, DocumentShares, StatusUpdates, ApprovalRequests, and ActivityFeed scoped to accessible projectsCRUD on Comments, CommentReplies, and DocumentDownloads (write on download)Cannot decide on ApprovalRequests (Approver only)Cannot view other ClientUsers' email or ClientActivitiesExternal client user with read-only access. The default tier for client stakeholders who need visibility but no contribution rights.
Read on own PortalSite's exposed PortalProjects, DocumentShares, StatusUpdates, ApprovalRequests, and ActivityFeed scoped to accessible projectsWrite only on DocumentDownloads (system-recorded on download)Cannot post Comments, cannot decide on ApprovalRequests, cannot view other ClientUsers' email or ClientActivitiesGive clients a branded entry point and the specific project access their work requires.
3 stages · 1 approval
Make a protected project document available to the intended client audience and record explicit acknowledgment.
3 stages · 0 approvals
Capture the named client’s decision and reconcile the result with the originating application.
3 stages · 1 approval
Create your ERP.AI account and get started with Proto.
We use essential cookies to run the site and optional cookies for features, analytics, and relevant content. See Cookie policy
We use cookies to enhance your experience, analyze site traffic, and serve relevant content. By clicking "Accept All," you agree to our use of cookies. You can customize your preferences at any time.
Learn more about how we use cookiesThese 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.
These cookies enable additional features that enhance your experience, such as live chat, video playback, personalized content recommendations, and remembering user preferences.
These cookies help us understand how visitors interact with our site by collecting anonymous usage data. This allows us to measure performance, detect issues, and continuously improve the user experience.
These cookies allow us and advertising partners, including X, to deliver ads tailored to your interests. They track browsing habits across sites to provide relevant advertising and measure ad effectiveness.