How do you build a client-facing project status page in Airtable?

How do you give a client a live view of project status without handing over your base?

Build a filtered view containing only what they should see, then share that single view by link rather than inviting them into the base. They get a page that is always current, and you keep your notes, rates and internal fields private.

I moved to this instead of weekly status emails and the number of "just checking in" messages dropped immediately. Not because clients became less curious, but because the answer was already available at a URL they had bookmarked.

What follows is the exact setup for one situation: you run projects in Airtable, you have one client who wants visibility, and you do not want them seeing everything in the table.

Why is a shared view better than a weekly update email?

Because the email is stale the moment you send it and the view never is. A status email describes Tuesday afternoon, which means every question arriving on Thursday is asking you to re-do the report conversationally, one message at a time.

There is a quieter benefit too. A live view removes the temptation to smooth things over. When the client can see that a task has been sitting in the same status for eleven days, you deal with that in a scheduled conversation rather than discovering they had been quietly worrying about it.

It also removes you as a bottleneck on your own good news. Work that finished on Friday is visible on Friday rather than in Monday's summary. If you already send recurring reports, the same reasoning applies to building a weekly report nobody has to assemble.

What should the client actually see?

Task name, current status, who it is waiting on, and the date it last changed. That is nearly always enough. What they are really asking is whether the project is moving and whether anything is waiting on them, and four fields answer both.

The "waiting on" field is the one that earns its place, because it converts a status page into a prompt. A client who can see that three items are blocked on their feedback will usually send the feedback, which no amount of chasing achieves as reliably.

What I keep out is anything about effort or internal reasoning. Hours, costs, my own notes about the work, and any field where I have written candidly about a decision. Those exist for me, and I keep them in the same base but outside this view. That separation is part of why I keep a written record of every project decision in the first place.

How do you create the shared link?

Airtable's documentation gives the sequence plainly. Open your Airtable home screen, open the base with the view you want to share, click Share and sync in the top-right corner, click Create link to view, then click Copy link. That is the whole mechanism.

Do the filtering before you create the link, not after. Build a dedicated view for this client, hide every field they should not see, and filter to their records only. The share link exposes that view as configured, so the view is your security boundary and it needs to be right before anyone has the URL.

Name the view something unmistakable, like "SHARED to client" rather than "Client view". Six months from now you or someone else will be reorganising fields in a hurry, and a view whose name shouts that it is public is far less likely to get a sensitive field dragged into it by accident.

Which permissions should you turn on, and which should you leave off?

Airtable's documentation lists a toggle called "Allow viewers to copy data out of this view", described as permitting anyone with access to the link to copy data from the shared view. For a status page I leave that off, because there is no reason for a project tracker to be exportable.

The one to be most careful with is "Show all fields in expanded records". Airtable's documentation says this setting will give end users with the appropriate access sight of all the data stored within any field. That is the opposite of what a curated view is for, so it stays off.

The general principle is the same one I apply to any shared surface: start with everything off and turn on only what the client needs to do their job. Convenience toggles enabled during setup have a habit of never being reviewed again, and nobody audits a share link they configured last year.

Can you restrict who opens the link?

Partly, and the limitation matters. Airtable's documentation states that its shared view links support domain-level access restrictions but do not support individual email address allowlists, and that it is not possible to restrict a shared view link to specific individual email addresses.

So you cannot say "only this one person". You can say "only people with an address at this company". Airtable's documentation describes a "Restrict access to an email domain" setting that allows access only to end users associated with a specific email domain, noting it is available on paid plans only.

There is also a password option. Airtable's documentation describes "Restrict access with a password" as securing access to the share view via password-protected access only, again on paid plans only. A further setting for restricting access to enterprise email domains is documented as available on Business and Enterprise Scale plans only. Check which of these your own plan includes before you promise a client anything about access control.

What will leak if you are careless?

Field names, mostly, and they say more than people expect. A hidden field is hidden, but a field you forgot to hide called "Client is difficult" or "Margin" is visible to anyone with the URL, and you will not get a warning.

The other leak is scope. A filter that selects by client name will quietly include new records matching that name, which is usually what you want, but a filter built on something fragile can start including other clients' rows after a schema change. Test the view by opening the link in a private browser window and reading it as a stranger.

Treat the URL itself as semi-public. Anyone the client forwards it to can open it, subject to whichever restrictions your plan supports, and clients forward things. Nothing should be in that view that would be a problem in the wrong inbox.

How do you keep it accurate without extra work?

Make the status page a byproduct of how you already work rather than a thing you update. If you move a task when you actually do the task, the view is accurate for free. If keeping it current is a separate chore, it will be wrong within a fortnight and worse than nothing.

That is the real test of this setup. A status page that is out of date is actively harmful, because the client trusts it and acts on stale information. I would rather show four fields that are always true than twelve that are usually stale.

I run automations on Airtable with WhaleSync for Ajust, and the same rule holds at much larger volume: the data people rely on has to be written as a side effect of the work, not maintained alongside it. Anything else decays. The same thinking applies when you eventually hand a finished project over to a client.

What should you do next?

Build it for your most communicative client first, the one who messages most often, because that is where you will feel the benefit within a week. Four fields, one filtered view, both risky toggles off, and the link sent with one sentence explaining what it is.

Then open the link yourself in a private window before you send it. Read every visible field and ask whether you would be comfortable with that row appearing in a forwarded email. That check takes two minutes and is the only part of this people skip.

Across 70+ projects for 25+ clients, the single change that improved client relationships most was making status visible rather than reported. I work on fixed fees, and transparency costs nothing while chasing updates costs both of us. If your clients keep asking where things stand, reach out and let's build you one of these.