Skip to main content

Add a customer workspace

Add customers to the existing production SABLE service. The current architecture does not duplicate the app, database, docs site, or worker for each client.

Create the scoped client records​

Create the client through the governed account workflow so SABLE writes the client, initial project, memberships, operating profile, external references, idempotency record, and audit event together. Confirm the client and every project share the intended org_id.

Assign staff to exact projects​

Add consultants to the required projects through project_members. Keep project status active or current while the consultant needs portal access. Admin and lead access remains organization-wide.

Do not add a broad client membership to work around a missing consultant project assignment. The portal uses exact project scope for consultant requests, milestones, notifications, and owner choices.

Configure customer-ready source data​

Connect only the approved account and projects. Start each connector in its read or dry-run mode, then confirm external identifiers and match results before enabling writes.

Customer publication remains deliberate. A successful connector sync does not release a transcript, document, meeting summary, milestone, update, or deliverable to the portal.

Prepare the customer workspace​

Before inviting anyone:

  1. Open the staff portal launcher.
  2. Open the customer preview.
  3. Confirm project names, accountable contacts, and action ownership.
  4. Publish the first shared milestone and commitments.
  5. Open the publication inventory and review the source candidates and blockers.
  6. Publish curated document or meeting metadata and a direct update when the workspace needs them.
  7. Release the current deliverable version from Draft Workbench.
  8. Confirm that the launcher and preparation counts match the published records.
  9. Confirm internal notes, raw sources, and restricted records stay absent.
  10. Ask one synthetic question and inspect every citation.

Publish through the portal controls or /api/portal-publications. Do not edit release metadata directly as an activation shortcut.

Invite named customer members​

Invite each customer separately with client_viewer or client_reviewer. Choose activity email explicitly for each recipient. Do not infer review authority from job title or email domain.

Track invitation delivery, acceptance, resend, recovery, and revocation from Manage access. A membership is the authorization grant; an Auth identity alone does not provide workspace access.

Verify delivery before handoff​

Follow Release the customer portal. Complete cross-client isolation, role, exact-link, request, review, private-file, notification, and grounded-assistant checks with synthetic identities before sending a real customer invitation.