Team, clients, organization, account, and admin settings

Simple terms

These settings decide who can access Apex, which clients exist, and how workspace-level administration works.

Manages who can access work, which clients belong to an agency, account-level preferences, integrations, and organization-level configuration.

Routes

• /team
• /clients
• /org/settings
• /settings/account
• /settings/integrations

Implementation behavior

• Store team membership and organization membership are separate so client access can be scoped.
• Agency workspaces expose client management and workspace settings beyond single-store company workflows.
• Account settings manage personal user profile and account-level state.
• Integration settings manage Shopify, profit analysis, and external platform health.

How to use it

• Invite teammates at the store or organization level depending on the access they need.
• Use Clients for agency workspace client setup.
• Use Organization Settings for workspace ownership and defaults.
• Use Integrations when Shopify or profit-analysis data needs reconnection.
• When inviting people, choose Editor or Viewer on the role cards. A store-level invite applies the role to that store only; an organization-level invite applies the default role to every store in the organization.

Client roles

• Editor — For people who actively manage experimentation. Can create, edit, launch and stop tests; work with backlog ideas; manage settings, integrations and installation; invite people; report bugs and request help. Cannot manage billing, remove people or delete the shop.

• Viewer — For people who need visibility without editing access. Can open tests, results and the pipeline, report bugs and request help, and approve designs when the per-person Can approve designs switch is enabled. Cannot change content or see research notes, feature flags or internal tasks.

• Owner — For the person accountable for the store. Can do everything an Editor can, plus manage billing, remove people, change roles and approve designs. Cannot delete or transfer the shop. DRIP sets the single Owner for each shop.

• Admin client preview (release 874e528): An admin-only client preview is available at Settings → Team that renders the dashboard as a client viewer or client approver. The preview is gated server-side and read-only, and lets admins confirm the client-facing view without granting client credentials.

The invite screen

The store invite screen shows the roles as cards, not as a dropdown. Each card carries the role name, what the role can do, and what it cannot do, so the choice is explained before it is made. Owner is not on the cards: each store has one Owner, set when the store is created or onboarded.

One line above the email field names the store's plan and says who to invite. The plan changes the recommended role and that line, and nothing else: a Viewer on one plan can do exactly what a Viewer on another plan can do.

• Self-Managed — the client runs everything themselves. Editor is recommended.
• Apex Managed — the client builds and launches tests while DRIP delivers research and scored ideas. Editor is recommended.
• Drip Managed — DRIP builds and launches tests. Viewer is recommended; design approval is switched on from the team list once they accept.

The Viewer card carries a note instead of a switch: design approval is a per-person right, so it is switched on from the team list once the person has accepted the invitation.

A DRIP address (dripagency.de, dripagency.dev) cannot be invited into a client store: the screen says that DRIP staff get access from Admin, and the send button stays off until the address changes.

The member list

Every member row names the role. Hover, focus or tap the role to open the same card the invite screen shows. People who hold DRIP platform access carry a DRIP badge instead of a role, because that access comes from Admin and is not a shop role to change here.

The invitation email carries the same card, so an invited person reads what the role can and cannot do before accepting.

When not to use it

• Do not invite users at the organization level when they only need one store.
• Do not change ownership or leave a workspace without confirming another admin remains.
• Do not use account settings for store or workspace configuration.

Implementation source

• Pages live under src/app/(dashboard)/team, clients, org, account, and settings routes.
• Handlers include /api/team/*, /api/orgs/*, /api/account/profile, and invitation endpoints.
• Membership and role models in Prisma separate organization access from shop access.

Data and API

• Models include Organization, OrgMember, Shop, ShopMember, invitations, account/user profile records, and integration records.
• APIs under /api/team, /api/orgs, /api/account/profile, and invitation endpoints.
• Active shop and active organization state determines what settings are visible.

Failure modes

• User cannot see a shop: they may be in the organization but not assigned to the store.
• Wrong client edited: switch active workspace/shop before changing settings.
• Ownership transfer or leave-workspace actions should be checked carefully because they affect access.