Softr portals whose permissions follow the data, and a way out when they do not fit
Softr portals and internal tools on top of Airtable or Softr's own database: user groups, page and record permissions, workflows, and the point where a custom build is the better answer.
Softr is the odd one in this group, and the difference is useful. It is not an AI tool that writes code for you to own. It is a no-code builder that turns a data source, most often an Airtable base, into a client portal, directory or internal tool, with user sign-in and permissions layered on top. The page is assembled from blocks, and Softr also offers its own database and workflows.
That makes it a good fit for a clear case: you already have the data in Airtable, you want clients or staff to see their part of it, and you do not want to build a login system. The thing to get right is permissions. Softr documents user groups and visibility rules at the page, block and record level, and those rules are the only thing standing between one customer and another customer's records.
We have not published a client engagement on Softr and hold no partnership with it. Softr's data usually lives in Airtable, which has its own page on this site, and the same modelling and permissions questions apply. This page is about building on it carefully, and about knowing when to stop.
What we build on Softr
A data model in Airtable that a portal can sit on
Linked records that express who owns what, a field that ties each row to a customer or a user, and views that stay stable when someone adds a column. A portal is only as sound as the base underneath it, so the modelling is done first, and it is the same discipline as our Airtable work.
User groups and rules that say what each person sees
Groups for the kinds of user you actually have, visibility set per page and per block, and record-level filters so a customer's list shows their rows and no others. We test it by signing in as each group, and as a user who belongs to two companies, which is the case that tends to break.
Actions that write back safely
Forms and buttons that create or update records, with the fields a user may change restricted to the ones they should, and status changes that only the right group can make. A form that writes to a table is also a way for a user to write to it, so each one is looked at as an input.
Workflows for what happens next
Notifications, approvals and hand-offs triggered from the portal, using Softr's workflows where they are enough and Make or n8n where the logic is more involved than a simple trigger and an action.
What goes wrong on Softr
The patterns that turn up on this platform specifically, and what we do about each one.
- 01
Hiding a block is not the same as protecting the data
A page can look correct for each group while the underlying data source returns more than the screen shows. We check what each user can reach, not just what they are shown, and prefer filters tied to the signed-in user's own record over rules that assume the layout.
- 02
A shared Airtable key that carries more than the portal needs
The connection between Softr and Airtable is authorised by a token with its own scope. We narrow it to the base and the tables the portal uses, so a mistake in the portal cannot reach the rest of the workspace.
- 03
Record and rate limits arriving after the portal is popular
A base that was comfortable at a few hundred records slows down as it grows, and both Airtable and Softr have limits that depend on the plan. The signs are slow page loads and a monthly bill that grows with users. We plan for it early: archive what is old, index what is searched, and move to a proper database when the numbers say to.
- 04
Custom behaviour bent out of blocks
Embedded code and workarounds can make a block do something it was not built for, and each one is a place where the next platform update breaks the page. When the list of workarounds is longer than the list of blocks, it is a signal about the tool, not about the page.
Where Softr is the wrong answer
Softr is the wrong answer when the logic stops being display and permissions and becomes a process: multi-step approvals with conditions, calculations across many tables, integrations that must be reliable and auditable, or data that is sensitive enough that you want the access rules in your own database rather than in a vendor's block settings. It is also the wrong answer when per-user pricing and record limits start to cost more than the thing would cost to own. Our alternatives pages are written for that decision. Many Softr portals should stay Softr portals, and we would rather tell you that than rebuild one that works.
Projects that did not use Softr
Here for the argument rather than as evidence of Softr work. Each one bears on a decision above, and the note says which.
The disciplines behind it
Related reading
Softr, specifically
It can be, if the permissions are set up deliberately and tested as each type of user. The risk is not that Softr is unsafe; it is that a portal can look right while the underlying records are reachable. We test what each user can reach, including a user who belongs to more than one company.
If the data already lives in Airtable and other things depend on it, connect to it and keep one source of truth. If you are starting fresh and the portal is the product, Softr's database removes a moving part. Whichever you choose, model the data first, because changing it after a portal is built on top costs more.
When the workarounds outnumber the blocks, when the cost grows faster than the value as users are added, when you need audit trails or logic that the blocks cannot express, or when the access rules matter enough that they belong in your own database. None of these is a failure of the tool, only a boundary of it.
Not primarily. It is a no-code builder that assembles pages from blocks over a data source, and it has added AI features alongside. We group it with these tools because the same question applies: a working demo and a safe production system are different things, and the gap is permissions, data and maintenance.
No. We hold no partnership, certification or endorsement from Softr, and nothing here should be read as one.
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no