Client decisions

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 approval requests row: picks Type, requested from client (a named client user with role Approver), related document if applicable, source table + source record for the callback, optional requires signature and expires at. The approval-request-routing workflow fires via the configured record event on record.created. A configured workflow service creates a magic links row with Purpose: Approval action and expires at 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 client user clicks the link, the magic-link auth handler redirects to the approval action page, the client picks Approved / Rejected / requested changes, optionally adds Comments and a captured signature blob, and on submit an approval decisions row writes (Sequence, Decision, Comments, signature blob if captured, from IP, user agent, signed at). The request Status flips to the matching enum and decided at stamps.

On approval request status: Pending → Approved or Rejected, the approval-decision-callback workflow fires via the configured record event. A configured workflow service reads source table + source record, resolves the appropriate integration endpoint (Project Management Tasks for Deliverable / Milestone types, Project Billing Invoices for Invoice type, an org-defined change orders endpoint for change order), and posts the decision back to the source — typically setting a client approval status enum and a client approval at date on the source record. notification service notifies the internal requested by Project Manager + the project’s Account Manager with the decision, the comments captured on approval decisions, and the link back to the request thread. A re-decision (e.g. Approver flips Rejected → Approved after a resubmit) writes a new approval decisions 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. 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. Magic link 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. Approval action 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.

• My Pending Approvals (Client) — Review the current requests addressed to the authenticated client approver.