Clients and portals overview

The mental model behind clients, portals, projects and requests — what each one is, what it controls, and where in the admin you change it.

Four things sit behind every customer you run in Zyan: the client record, one or more client portals, the projects you deliver, and the requests and approvals that flow between you. They are separate on purpose, and knowing which one you are looking at saves most of the confusion people hit in their first week.

Before you start

Clients need the Clients permission and the crm_clients plan feature. Portal work needs Client Portals (edit). The portal's Access and Sections tabs are owner-only — team members with the Client Portals permission see only Overview and Billing.

The Clients list with portal state, project counts, billing and onboarding columns — The Portal column is the one people look for: None means the client has no login yet, and Invited means one was sent and not yet accepted.

Client record

Internal only. No login exists yet

Portal

One login, per project or account-level

Invite

Email, with an optional onboarding pack

Discovery

Only where a pack carries a form. Per project

Live portal

Sections, services and billing you control

Five separate actions. Creating the client does none of the four that follow it.

A client is your internal record: name, company, email, phone, notes and a status of active, lead or archived. Creating one creates nothing else — no portal, no invite, no login. The New client dialog says as much.

A client portal is the login. It lives under the client, and one client can hold several:

One portal per project or website, each with its own sections, services and billing.
Optionally one account-level portal with no project linked. The project scope picker labels it Account access. A client may only ever hold one of these — a second attempt is refused.

What a portal controls

Everything the client experiences is decided on their portal, not on the client record.

Control	What it decides	Where you set it
Kind	Full portal, Leads, SEO, Backlinks or Ads. Minimal kinds land the client on their product surface and hide agency-workflow navigation	Settings → Sections
Sections	Which of the eleven portal areas are visible	Settings → Sections
Status and role	Whether the login works, and whether it is a client or admin role	Settings → Access
Seats	Extra logins on the same portal, up to five beside the primary	Settings → Access
Notification emails	Which categories of email this client receives	Settings → Access
Billing	Subscription, plan cards, payment links, invoices	Settings → Billing
Services (add-ons)	Which purchased or granted services appear, per website	Client visibility

Where each control lives

Open a client from DeliveryClients and you land on a page split into section pills:

Overview — portal access card, the onboarding timeline, billing summary and plan-change requests.
Client visibility — the add-on queue and a per-service, per-website matrix that answers "what does this client actually see".
Projects, Activity, Schedule — the work, the interaction history and scheduling. Growth is owner-only.
Settings — the portal settings panel (Overview, Access, Sections, Billing), the portal lifecycle actions and the danger zone.

Check your work without logging in as the client

Use Client visibilityPreview as client for a read-only snapshot of the client's portal under their own permissions. Open live portal takes you to the real thing. Check the preview before you send an invite.

Projects and portals are linked, not the same

A project is your delivery record. A portal is a login. Linking them is what makes several features work at all:

Approvals are project-scoped. A portal with no linked project cannot receive one.
The client's Discovery Interview is per project.
Reports, checkpoints and client tasks hang off the project and surface in the linked portal.

You can create a project first and attach a portal to it later, or create the portal and link it when the project exists.

Requests and approvals

Two different directions of travel:

A request comes from the client — a revision or change they ask for. They raise it in their portal, and it lands in your Requests inbox.
An approval goes to the client — work you need signed off, with an optional checklist. They answer Approve or Request Changes.
A client task also goes to the client, but it is a to-do rather than a sign-off.

The client's side in one paragraph

Your customer opens the invite, sets a password, and — if you attached an onboarding pack with a discovery form — answers the questionnaire. They land on Home with a to-do card and recent activity. Their left navigation is whatever your section toggles allow: Home, Projects, Tasks, Strategy Center, Requests, Messages, Announcements, Analytics, Advertising, Plan & Billing and Settings. Reviews (your approvals) live under Tasks → Reviews. The whole thing carries your logo, colour and legal links.

Troubleshooting

Symptom	Cause	Fix
A new client has no portal	Creating a client never creates a login	Use Create portal on the client's Overview tab
"This client already has an unassigned portal"	A client may hold only one account-level portal	Link the next portal to a project instead
Access and Sections tabs are missing	Those tabs are owner-only	Ask a workspace owner to make the change
The client sees a section you turned off	Section flags hide surfaces, not the records behind them	Turn the matching notification category off under Settings → Access too
Request Approval is disabled	The portal has no linked project	Link a project to the portal first