What your clients see in the portal

What the portal is

The client portal is the white-labelled surface your clients sign into. It lives at /portal under your agency's custom domain (for example, https://automations.agency.com/portal) and shows each client only the workspace they belong to, branded as your agency, never as TaskJuice.

The agency app at /dashboard and the portal at /portal are the same product, gated to different audiences. You and your team see the builder, integrations, and analytics. Your clients see a focused subset: the workflows you've published for them, the runs those workflows produce, the connections their workflows depend on, the forms they can fill out, and the invoices they need to pay.

A client never sees the workflow editor, never sees other clients' workspaces, and never sees the TaskJuice brand. If you've set up a custom domain, the portal's address bar reads as your agency too.

Who sees the portal

Anyone whose effective role on a workspace is workspace-client sees the portal when they sign in. The role is granted when you invite a client to a workspace from your agency dashboard — see Invite a client to a workspace.

The portal layout enforces this in one place. If a user with an account role visits /portal, they are redirected to your agency dashboard. If a workspace-client member visits any agency route, they are bounced back to the portal. A user who has been removed from every workspace lands on the home page, never on a stale portal.

When a single user is a client on more than one of your workspaces (rare but supported — agencies running multi-brand or franchise models hit this), the portal sidebar surfaces a workspace switcher. The last visited workspace is remembered through a cookie so a client always lands where they left off.

What the portal contains

The portal sidebar has seven entries. Each one maps to a real route under /portal.

Dashboard

/portal

The landing page. It shows three things: the count of active workflows in the workspace, a list of recent runs across all of those workflows, and a row of one-click trigger buttons for any workflow you've flagged as client-triggerable.

Client-triggerable is a per-workflow setting you control from the agency side. When it's on, the workflow shows up as a button on the client's dashboard so they can fire it themselves (for example, "Sync HubSpot now" or "Generate this month's report") without having to navigate into the workflow detail page.

Workflows

/portal/workflows and /portal/workflows/[workflowId]

A read-only list of the published workflows in the client's workspace. The detail page shows the workflow's purpose, current status, and recent run history. Clients cannot edit the workflow graph, change triggers, or rewire nodes. The editor is yours.

When a workflow is client-triggerable, the detail page also shows a Run now button that posts to the workflow's manual trigger.

Runs

/portal/runs

Every run produced by the workspace's workflows, sorted newest first, with status (succeeded, failed, running), duration, and a link into the run timeline for that workflow at /portal/workflows/[workflowId]/runs/[runId].

Clients see status, timestamps, and a high-level summary of which steps ran. They do not see internal step payloads that might leak sensitive integration tokens.

Connections

/portal/connections and /portal/connections/[connectionId]

The OAuth and API key connections their workflows depend on. The list shows which third-party accounts (Salesforce, HubSpot, Google Drive, and so on) are wired up and whether each connection is healthy. The detail page lets the client reauthorize a connection that has expired or had its credentials rotated.

This is the core of the "clients keep their own credentials" model. The client owns the connection. You build the workflow. Neither side is blocked on the other for a token refresh.

Forms

/portal/forms and /portal/forms/[formId]

Any forms a workflow has published for the client to fill out. A form might collect intake information, gather approval before a workflow proceeds, or capture data the workflow needs at a specific step. Each form lists when it was last submitted and links to the submission history.

Billing

/portal/billing, /portal/billing/invoices, /portal/billing/invoices/[invoiceId], and /portal/billing/payment-methods

Everything the client needs to pay you. The billing overview summarizes active subscriptions and outstanding invoices. The invoices page lists every invoice with status (open, paid, void) and a Pay now button that opens the Stripe-hosted payment page. The payment methods page lets the client add or update a card through the Stripe Customer Portal.

Payment collection happens entirely on Stripe-hosted pages. The portal never touches a card number. See Bill your clients for how the agency side of this works.

Account

/portal/account

The client's own profile: name, email, password, and notification preferences. Account-level changes here only affect the client's own user record, never your agency or other clients.

What clients cannot do

The portal is intentionally narrower than the agency app. Things that live on the agency side and are never exposed to clients:

• Workflow editing. Clients cannot open the visual builder, add nodes, or change triggers. They can only run workflows you've published.
• Other workspaces. A client only sees workspaces they are a member of. Cross-workspace queries return zero rows by access control, not by UI omission.
• Agency settings. Branding, custom domains, team members, plan, and integrations belong to your agency. Clients never see them.
• Other clients. A client has no way to enumerate other workspaces under your agency, view their workflows, or see their invoices.
• The TaskJuice brand. The portal renders your logo, your colours, and your custom domain. The word "TaskJuice" appears nowhere in the chrome.

How clients arrive

Clients reach the portal one of two ways:

• Invite link. You invite the client from the agency dashboard. They receive an email, sign up (or sign in if their email already has an account), complete a short client-side onboarding, and land on /portal.
• Direct sign-in. A returning client visits your agency's custom domain and signs in. The portal layout reads their role and sends them to /portal automatically.

Either way, the first thing they see is your brand, not TaskJuice's.

Next steps

• Invite a client to a workspace — wire a client into a workspace and send them the welcome email.
• Connect Stripe to bill clients — complete Stripe Connect onboarding so you can charge clients through the portal.
• Set up a custom domain — serve the portal at your own hostname so the address bar reads as your agency.