A client portal is the single most common thing people hire me to build in Softr — and for good reason. It's the fastest way to give your customers a secure, branded place to log in and see their data: projects, documents, invoices, requests. This guide walks through how to build one properly, the way I build them for clients, so you end up with a real product rather than a fragile prototype.
I build portals on Softr for a living, so I'll be honest about the parts that matter and the parts people get wrong. If you'd rather have it built for you, that's what I do — but everything you need to do it yourself is below.
What a client portal actually is
Strip away the jargon and a client portal is three things:
- A login — each customer has their own account.
- Their data, and only theirs — a customer sees their projects, not everyone's.
- A branded interface — it looks like your business, on your domain.
That third point is where Softr shines and why it beats a generic tool. But the second point — showing each person only their own records — is where most DIY portals quietly leak data. We'll spend real time there.
What you'll need
- A Softr account (the paid plans unlock user authentication and custom domains).
- An Airtable base to hold your data (Softr can also use Google Sheets or a database, but Airtable is the natural pairing).
- Your logo, colours and a domain — for the branded finish at the end.
That's it. No code required, though a little custom CSS or JavaScript helps for the last 10% of polish.
Step 1 — Model your data in Airtable
Everything good about a Softr portal starts with a clean Airtable base. Get this right and the rest is easy; get it wrong and you'll fight the tool forever.
The key idea: you need a way to tell which records belong to which customer. In practice that means:
- A Clients (or Users) table — one row per customer, with their email address. The email is what links a logged-in user to their data.
- One or more data tables — Projects, Documents, Invoices, whatever your portal shows.
- A link field from each data table back to the Client, so every project "belongs to" a client.
Take your time here. A portal is only as trustworthy as the data model underneath it. If a project isn't clearly linked to exactly one client, Softr can't reliably decide who's allowed to see it.
Step 2 — Connect Airtable to Softr
In Softr, add your Airtable base as a data source. Softr reads your tables and fields directly — no import, no syncing to manage. When someone updates a record in Airtable, the portal reflects it. This is the quiet superpower of the Softr + Airtable pairing: your team keeps working in a familiar spreadsheet-like tool, while your customers get a polished app on top.
Step 3 — Turn on user accounts
This is where a website becomes a portal. In Softr, enable user authentication and point it at your Clients table. Softr uses the email field to create accounts — each client signs in with their email, and Softr knows who they are.
You have options for how people get in: magic links (a login link sent to their email — the smoothest for non-technical clients), passwords, or Google sign-in. For most client portals, magic links are the least-friction choice.
The important part: once authentication is on, Softr knows the logged-in user's email on every page. That's the key you'll use in the next step to show each person only their own data.
Step 4 — Build the portal pages
Now the visible part. A typical portal has:
- A dashboard — a friendly landing page after login ("Welcome back, {name}") with a few summary cards.
- List pages — e.g. a list of the client's projects, shown with Softr's list or table blocks.
- Detail pages — click a project, see everything about it on its own page.
You build these by dropping in Softr blocks and pointing each at the right Airtable table. Softr's blocks are responsive and look professional out of the box, which is why portals built this way don't look homemade. Add forms if clients need to submit things — a request, a file, an update — and those write straight back to Airtable.
Step 5 — Lock down access with permissions
This is the step that separates a real portal from a data leak, so don't skip it.
By default, a list block shows every record in the table. In a client portal that's a disaster — client A would see client B's projects. You have to filter every data block so it only shows records belonging to the logged-in user.
Softr does this with logged-in user conditions: you tell each block "only show records where the Client's email equals the logged-in user's email." Do this on every list, every detail page, every block that touches customer data.
Two rules I follow on every build:
- Filter at the data level, not just by hiding UI. Hiding a button isn't security; filtering the records is.
- Test as a real client. Log in as an actual test customer and try to reach another client's data by guessing URLs. If you can't, you've done it right.
Row-level permissions are exactly the kind of thing that's easy to get almost right and dangerous to get slightly wrong. It's the number-one reason people hand a half-built portal to a certified Softr expert to finish.
Step 6 — Brand it and add your domain
Now make it yours. In Softr, set your logo, brand colours, and fonts so the portal looks like your business, not like a template. Then connect your custom domain — portal.yourcompany.com — so clients never see a Softr URL. This is a paid-plan feature and it's worth it: the difference between "a tool my supplier uses" and "my supplier's professional portal" is almost entirely this finish.
A little custom CSS goes a long way here for the final polish — matching a specific brand font, tightening spacing, adding a touch that's unmistakably yours.
Step 7 — Launch, then maintain
Before you send the first login link:
- Test the whole journey as a real client — sign up, log in, view data, submit a form, log out.
- Re-check permissions one more time. Always.
- Add a couple of real clients and get their feedback before rolling out to everyone.
And remember a portal isn't "done" at launch — it's a living tool. Clients will ask for a new view, a new field, an extra table. Softr makes those changes fast, which is the whole point: you can keep improving it without a rebuild.
Common mistakes to avoid
- Skipping the permissions filter. The big one. Every data block, every time.
- A messy Airtable base. If your data model is unclear, no amount of Softr polish will save the portal.
- Over-building v1. Ship the core — login, see my data, one action — then expand. Portals grow best in use.
- Forgetting the custom domain. A Softr-branded URL undercuts an otherwise professional portal.
Frequently asked questions
Can you build a secure client portal in Softr?
Yes. Softr has built-in user authentication and row-level permissions ("logged-in user conditions") that restrict each customer to their own records. Security depends on filtering every data block correctly — which is the step that most needs care.
Do I need to know how to code to build a Softr portal?
No. A functional, branded client portal can be built entirely without code. A little custom CSS or JavaScript helps with final polish and edge cases, but it isn't required to launch.
How long does it take to build a client portal in Softr?
A defined portal typically takes days to a couple of weeks, depending on how many data types and actions it includes — far faster than custom development, because authentication, permissions and responsive layout come solved.
What data source should I use with Softr for a portal?
Airtable is the natural pairing — it's easy for your team to manage and links cleanly to Softr's permissions. Google Sheets and databases also work; Airtable is usually the smoothest for client portals.
Want a secure, branded client portal without the risk of getting permissions wrong? I'm a certified Softr expert — I build production-ready portals on Softr + Airtable, shipped in weeks and kept running. Tell me about your project → — no obligation, reply within one working day. (Still deciding on your tool? See Softr vs Bubble.)