Practical guide

Give clients platform access without exposing other work

Client seats require a least-privilege role, project scope, onboarding note, data definitions, support boundary, and offboarding trigger. Test the exact client view before inviting anyone. Record who can invite users, export data, change targets, or alter scheduled delivery. Use current primary documentation, a representative project, explicit definitions, and a recoverable operating plan before scaling the workflow.

Last materially reviewed 2026-08-28

Quick answerClient seats require a least-privilege role, project scope, onboarding note, data definitions, support boundary, and offboarding trigger. Test the exact client view before inviting anyone. Record who can invite users, export data, change targets, or alter scheduled delivery.
Direct answer

Client access: define the job first

Client seats require a least-privilege role, project scope, onboarding note, data definitions, support boundary, and offboarding trigger. Test the exact client view before inviting anyone. Record who can invite users, export data, change targets, or alter scheduled delivery.

Treat client access as a controlled information path. Data enters with a source and scope, passes through settings and definitions, becomes a report or alert, and reaches a person who must decide. The weakest definition or handoff controls the result even when every chart looks polished.

  • Define what success means for client access.
Working method

Configure the repeatable sequence

Pilot client access on one representative project. Record setup time, missing inputs, quota use, manual corrections, export quality, recipient questions, and the first decision the output changed.

Only clone the workflow after the pilot has an acceptance test and a documented fallback.

  • Name the source and scope.
  • Assign the workflow owner.
  • Record the fact that would reverse the decision.
Decision framework

Test the weakest handoff

Stress-test the failure path: a disconnected integration, exhausted quota, changed site, renamed project, missing teammate, client offboarding, delayed data, or conflicting source.

Keep a manual recovery route for client-critical delivery and never automate destructive or public changes without the required review.

  • Compare the same operating job.
  • Keep cost and review effort in the model.
  • Preserve a recoverable fallback.
Final check

Commission the workflow

Write the operating statement in one sentence: “For ___, we collect ___ every ___, review it with ___, act when ___, and verify with ___.” If the blanks cannot be filled, client access is not production-ready.

Use current primary documentation again before purchase or migration because plans, limits, integrations, and controls change.

  • Save settings and definitions.
  • Test one complete cycle.
  • Schedule the next review.
Continue when useful

Next: Guest links

Guest or shared access should expose the right project and period without granting broader account control. Review links, recipients, expiration behavior, revocation, and client offboarding. Test the experience in a signed-out browser and verify that unrelated projects and settings remain inaccessible. Use current primary documentation, a representative project, explicit definitions, and a recoverable operating plan before scaling the workflow.

Open Guest links →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Account and project settings FAQ — DOCUMENTATION · checked 2026-08-28
  2. Agency Pack overview — DOCUMENTATION · checked 2026-08-28