Build a Client Portal in Asana Without Buying Client Seats (2026)

A client portal in Asana is not a project you share. It is a second, thin layer that shows a client their own work and hides everything else. Get that distinction wrong and you either leak internal data or you buy client seats you did not need to buy.

This guide builds the four-part version that works on a paid Asana plan without purchasing client seats: a guest-enabled delivery project, a portfolio roll-up for the client’s cross-project view, a form for intake, and a reporting mirror you own. Everything below is drawn from Asana’s published documentation and pricing, plus what paying teams report in Asana’s own community forum about the places this design breaks.

TL;DR

Guests are included in the seat price on Starter and above. Asana’s plans include “unlimited free guests” from Starter upward (Starter is $10.99 per user per month billed annually, $13.49 monthly). Guests are not free on Personal, which caps at 2 seats per project.
A guest sees the task, not the context. Guest access is scoped to what you explicitly grant: the project, task, portfolio or goal they were invited to. There is no view-level hiding inside that scope by default, so anything living in the project is visible to the guest — including the fields your team uses to decide things.
So the portal gets its own project. Delivery work stays internal; the client-facing project carries a curated subset. The cost is duplication, and the payoff is that a status field called “At risk — do not bill” never appears in a client’s browser.
Portfolios are the portal’s home page. A portfolio shared with the guest shows multiple projects in one place with their status and progress, which is exactly the “where does my work stand” question a portal exists to answer.
Forms are the intake surface, and they have their own limits. Asana forms submit into a project you choose, so point them at the client-facing project, not the delivery one — otherwise every submission lands in a workspace the client cannot see and someone has to triage by hand.
The billable-client trap: inviting the client’s team as members instead of guests is one permission-setting away, costs a seat per person, and Asana users describe the reverse error (never being able to remove an extra seat) in the forum.

What the pricing actually says

Asana’s published plans, per user per month, billed annually:

Plan	Price	Guest access	Notes for a client portal
Personal	$0	Not included	2 seats per project, no guest sharing path
Starter	$10.99 (monthly $13.49)	Unlimited free guests	Unlimited automations, forms, timeline
Advanced	$24.99 (monthly $30.49)	Unlimited free guests	Portfolios, goals, approvals, branching forms
Enterprise	Quoted	Unlimited free guests	SSO, SCIM, guest controls at org level
Enterprise+	Quoted	Unlimited free guests	Governance, data residency

Verified against Asana pricing on 2026-11-07.

The relevant fact for a client portal is the middle column: from Starter up, guests do not cost anything to invite. So the question “how do I build a client portal without buying client seats” has a boring answer — invite them as guests — and a more interesting one, which is how to invite them as guests without giving them your workspace.

Two pricing consequences that shape the build:

Advanced is where portfolios live, and portfolios are the portal’s index page. At $10.99 Starter you can share a single project with a guest. At $24.99 Advanced you can share a portfolio, which is the difference between a client clicking into four separate project links and a client opening one page that shows four projects and their status. For a portal serving one client with one project, Starter is enough. For a client with multiple concurrent projects, Advanced is doing real product work for you and the $14/seat gap is the cost of it.

AI is now metered on top of seats. Asana includes “5 requests per user per month, up to 250 requests per account” on paid plans, plus AI Studio credits (50,000 per billing account per month on Starter, 75,000 on Advanced, 200,000 on Enterprise). Additional AI requests are $0.50 prepaid or $0.60 on demand. None of that has anything to do with your guests — guests do not carry AI allowances — but if your portal design includes an AI-generated client summary, the requests come out of the seat-holders’ pooled budget. Budget it in the same place you budget seats.

Before you build: the four layers

Say a client, Northwind, has three live projects and one person who wants a weekly view. The portal is four things:

A client-facing project per client, where client-visible work lives.
A portfolio containing those projects, shared with the guest as the portal home.
A form that submits intake requests into the client-facing project.
A reporting mirror — a dashboard or a scheduled export — that your team controls and the client reads, so metrics move without you editing tasks.

The internal delivery projects do not change. Everything in this guide is additive, which is why it is reversible: if the portal proves unnecessary, archive the client-facing project and revoke the guest, and nothing about how your team works has altered.

Layer 1: the client-facing project

Create a new project called {Client} — {Year} Client Portal, in a team the client will never see, and add only the fields a client should read:

Status (a status-type field, not free text)
Deliverable (task name)
Due date
Owner (assigned to a workspace member)
Client-visible notes (rich text, written for the client)

Do not add: internal priority, margin, hours burned, risk rating, internal RACI. A guest with project access sees project content. Asana’s access model grants visibility at the object you shared and the objects nested under it; it does not offer a per-field “hide from guests” switch inside a shared project. The safe assumption when designing the portal is that anything in the project is client-visible, so the project should contain nothing else.

The sync decision you have to make

The client-facing project now duplicates tasks that already exist in delivery. There are three ways to keep them in step, and only one of them is honest about its cost:

Approach	How	Cost	Risk
Manual mirroring	Your PM copies milestones into the portal weekly	15–30 min per client per week	Stale between updates; the client notices before you do
Rules-based mirroring	Asana rules or an automation in the delivery project that creates a task in the client project when a condition is met	Setup time, plus automations against your monthly cap	Rule edits silently change what the client sees
Delivery-in-portal	Move the work into the client-facing project and keep internal detail in subtasks	No duplication	Subtasks are visible to guests on the parent task, so this only works if the internal detail lives in fields instead

The middle option is the one most teams settle on, and the one that bites. Asana’s rules are transparent in configuration but not in effect: a rule that adds a section, changes an assignee or posts a comment fires for every task that matches, and the guest sees the result. Name every rule that writes to a client-facing project with the word CLIENT at the front, and put them in one place, so a teammate editing automation cannot quietly widen what a client sees.

Layer 2: the portfolio that becomes the home page

On Advanced, create a portfolio and add the client’s client-facing projects to it. Share the portfolio with the guest.

This is the single highest-leverage step in the build, because it changes the client’s experience from “I have links” to “I have a page.” A shared portfolio shows the projects it contains along with their status and progress, which is the question a client portal exists to answer — and because the status comes from the projects’ status fields, updating a project status updates the portal with no extra work.

Constraints to design around:

A portfolio shows what its projects show. If the portfolio contains a delivery project by mistake, the client can reach that project’s content. Treat portfolio membership as a publication decision, not an organisational one.
Status is the only thing you should have to maintain. Give each client-facing project one clear status definition list (On track / At risk / Off track / On hold) and agree the meaning with the client in writing at kickoff. Every “the portal is useless” complaint traces back to a status vocabulary that means something different inside your team than outside it.
Starter has no portfolio. If you are on Starter and the client needs one page, the substitute is a task in the client-facing project whose description contains the project links. It works; it is just maintenance you have accepted.

Layer 3: intake through a form

A portal without an intake path becomes an email inbox with extra steps. Asana forms fix that by routing submissions into a project, but the destination choice is a classic mistake:

Point the form at the client-facing project. Asana forms submit into a specific project you select when building the form, and submissions appear there as tasks. If you point a client form at your delivery project, the client submits into a workspace they cannot see — which is fine for them and bad for you, because you now have two intake streams (their form and their email) and no single queue.

Forms on Starter are unlimited. Advanced adds branching, which is worth $14/seat if your intake has more than one path: a branch that asks “is this change within scope?” before it asks anything else saves a scope conversation per submission. If your intake is genuinely two or three questions, Starter’s flat form is sufficient.

Two form settings to get right on day one:

Hide the submitter field if the client’s team changes; otherwise every submission creates a new “requester” identity.
Do not auto-assign to the client. Form submissions should land unassigned or assigned to your delivery lead, because the client is the requester, not the owner — and an assigned task in a client-facing project shows the client as the owner of work they asked you to do.

Layer 4: the reporting mirror

The last layer is the one that makes the portal stop being maintenance: a dashboard or scheduled export that you own, that the client reads.

On Advanced, build a dashboard at the project level and share it with the guest through the project they already have access to. Keep the charts to what a client cares about: completion over time, upcoming milestones, open requests by age. Do not include anything that measures your team’s internal performance — hours, cycle time per assignee, reopened count — for the same reason you would not put them in a shared deck.

On Starter there is no project dashboard, so the mirror is an export. Asana’s CSV export from a project has a documented ceiling of 140,000 rows, and the live Google Sheets sync is capped at 500 rows per project — a number that surprises teams who build their client reporting on the sync. If your client-facing project will ever exceed 500 tasks, the sync is the wrong tool and a scheduled export is the right one. The export ceilings, the sync limit and the guest-related limits are worth reading before you promise a client a live spreadsheet; we cover them in detail in who owns your PM data.

The permission boundaries, in one table

This is the part of the build that decides whether the portal is safe. Each row is a decision you make once and live with.

Question	The safe answer	Why
Is the client a guest or a member?	Guest, always	A member consumes a seat and sees the workspace; a guest sees only what you grant
What is the guest invited to?	The portfolio (Advanced) or the client-facing project (Starter)	Grant scope is the object you invite them to plus what is nested under it
Can a guest see other projects?	No — unless granted	Guest access is scoped per object; a guest in one project is not a guest in the workspace
Can a guest see internal fields?	Yes, if the field exists in the project they can see	There is no field-level hiding inside a shared project; this is why the portal project is separate
Can a guest see subtasks?	Yes, on tasks they can see	Never put internal war-room notes in subtasks of client-visible tasks
Can a guest see comments?	Yes, on tasks they can see	Comment-based internal discussion is a leak; use a separate internal task
Can a guest create tasks?	Depends on what you grant	Grant it deliberately for the intake project, not for the delivery project
What happens when the engagement ends?	Revoke the guest, don’t archive in a hurry	Removing access is the control; archiving is housekeeping

The two rows worth pinning to a wall are “internal fields are visible if they live in the shared project” and “comments and subtasks are visible on shared tasks.” Almost every client-portal embarrassment in a PM tool is one of those two, not a permissions bug.

What paying users actually run into

Asana’s community forum is the best available record of where this design fails in production, because the failures are reported by the people operating it.

Client visibility collides with internal data — and the answer is structural. A user asked the exact question this guide answers: how to invite a client to approve and comment “but don’t want them seeing certain internal information like budget, cost, time tracked, time estimated,” adding “I don’t want to create a parallel project each time and double book-keep, that’s a no-no. I want a single project, with the client invited, but being able to hide internal information.” The accepted answer was the workaround this tutorial builds on: “the only option is to create an additional dedicated shared project where you have only the custom fields you want them to see. The tasks can be automatically multi-homed in that shared project… if the shared project does not feature your ‘tracking’ Custom Fields, they won’t see them.” (Asana Forum — “How to work with external clients you don’t want to see everything?”)

The same thread contains a warning that upgrades the automation advice above. The original poster tried exactly the rule-based mirroring and found the maintenance cost moves rather than disappears: “I have to re-write the rule for each section, each time I create a pair of projects from templates.” Multi-homing is cheaper than copy-pasting tasks, and still costs you a rule per section per template — which is why the rule-naming convention matters more than the rule itself.

Seat management is where guest/member confusion shows up. A 2026 feature request makes the operational risk explicit: the author asks that when “a user adds another person to a project, I believe that person should be added as a GUEST by default… only an Administrator or Super Admin should be able to upgrade that person from Guest to MEMBER, therefore assigning them a paid seat,” citing “cost control and governance” and that “regular users should not be able to unintentionally increase a company’s subscription costs.” (Asana Forum — “Seat management”)

Read that as an admission of the default: anyone who can invite can turn a client into a seat. For a portal build, that means the invitation is a governance step, not a courtesy. Note also the reply noting that on Enterprise and Enterprise+ “you can make new signups start as Viewers (no seat required)” — a platform-level control that does not exist on Starter or Advanced, where the discipline has to be human.

Guest access does not always behave as intended. A 2025 thread reports the failure mode most damaging to a client portal: a client added as a guest “use[s] the url we shared” and is “redirected to a page asking them to upgrade their account,” while “other people in their organization are accessing the project as guests, with no issue at all.” Removing and re-adding the guest did not fix it. (Asana Forum — “Guest user lost access”)

The practical consequence for your build: test the guest link with the actual client account before you announce the portal, and keep a fallback — a shared status page or a weekly PDF — for the week the invitation misbehaves.

The pattern across all three: Asana grants access to objects, teams grant meaning. The product will do exactly what you configure; it will not infer that “the client probably shouldn’t see this column.” That is the work the separate portal project does.

One caution about forum evidence: these threads describe real friction for real paying teams, but they are reports, not a laboratory test, and Asana changes access behaviour between releases. Read them as a list of things to verify in your own workspace, not as a defect list.

Team-perspective judgement

Under 10 people, one or two clients. Build the Starter version: one client-facing project per client, one flat form, no portfolio, no dashboard. Invite the client as a guest on that project only. Total setup is under an hour per client, and the maintenance is a weekly 15-minute milestone pass. Do not upgrade to Advanced for this — the portfolio saves you a link list, and $14 per seat per month is a poor trade for a link list. If you want the wider picture of small-team tooling, see best PM software for small teams.

10–40 people, agency or consultancy with concurrent client work. Advanced, and build the portfolio. This is the configuration where the portal earns its keep, because a client with four live projects needs one page and you need one status field to maintain. Pair it with the delivery-side setup in build an Asana workflow for agencies and the reporting rhythm in client reporting workflow in a PM tool.

Any size, clients who ask for a login to “their own system.” Be honest that this is a shared view, not a client extranet. If a client needs per-user logins, their own SSO and their own document store, that is a different product class — client-delivery platforms rather than PM tools. The comparison in best PM software for agencies covers where that line sits.

Any size, procurement or legal involvement. Before you invite the first guest, get two answers in writing from whoever owns data protection: where guest-authored comments are retained, and what happens to guest data when the engagement ends. Revoking a guest does not delete their comments from your project history, and the retention question is the one a client’s counsel asks.

The build checklist

Paid plan confirmed (Starter or above) — guests are not free on Personal.
Team created that the client will never be invited to.
Client-facing project created with a published field list, and nothing else.
Internal delivery project untouched; the portal is additive.
Sync mechanism chosen (manual, rules, or delivery-in-portal), and every rule writing to the portal named CLIENT — ….
Portfolio created and shared (Advanced), containing only client-facing projects.
Status vocabulary agreed with the client in writing.
Form pointed at the client-facing project, submitter field hidden, no auto-assign to the client.
Dashboard or export built by you, containing no internal performance metrics.
Guest invited to the portfolio/project — not to the team, and not as a member.
Weekly 15-minute milestone pass on the calendar with a named owner.
Revocation step written down, including who does it when an engagement ends.

The tool itself: Asana review 2026, and how it compares at the top: Asana vs ClickUp vs monday, Asana vs monday.com.
Agency-side builds that pair with this portal: Asana workflow for agencies, client onboarding workflow in a PM tool, client reporting workflow in a PM tool, set up Asana for consultants.
Alternatives built for client delivery: Rocketlane review, Kantata review, Avaza review, best PM software for consulting firms.
The pricing and cost context behind the seat decisions: Asana new features and pricing 2026, Asana vs ClickUp vs monday pricing, migrate from Asana to ClickUp.

How this content was prepared

Transparency note: This tutorial draws on three sources. (1) Vendor primary documentation, read on 2026-11-07 and linked at each claim: Asana’s public pricing page for every plan price, the guest-seat inclusion and the AI request rates and AI Studio credit allowances, plus Asana’s documented export ceilings and Google Sheets sync limit. (2) Real-user evidence from the Asana community forum, cited inline with links: three threads from 2024–2026 on client visibility versus internal data, seat management confusion and guest access behaviour that differed from expectations. (3) Editorial judgement, expressed as the four-layer build, the permission-boundary table and the team-size recommendations — this is design work, not a vendor claim.

We have not independently built and run this portal end to end on a live Asana account for this page, and we make no claim to have done so. The field lists, rule naming convention and revocation step are a design we would ship, with assumptions visible above (client-facing work mirrored into a separate project; guests invited at the portfolio or project level only). Asana’s permission behaviour and plan boundaries change between releases — when your build contradicts a row in the boundary table, the vendor documentation and your own test invite are authoritative, not this page.

The claim we will stand behind: if a field must never be seen by a client, it must never live in a project the client can reach. Every other safeguard in this guide is convenience. That one is the design.