Softr Review: Portal Roles, Preview Data and Running Costs

Start with the records each client should own

Softr connects AI app generation to a visual business-app editor. Its documented workflow covers pages, data and actions, with user groups and permissions around the resulting application.

This suits a client delivery portal or operations request queue. An operations owner can maintain forms, lists and status changes without taking over a conventional source repository.

For a client portal, identify the record owner before generating screens. For an internal queue, identify who can approve a request and which actions may trigger notifications.

Ordinary Softr blocks belong to a managed application model. A custom or vibe-coded block does not establish that the entire portal can be exported as an independently maintained app.

Use role preview for inspection; prepare the data before write tests

On October 28, I opened Softr’s official job-listing template preview and switched from a supplied talent user to a supplied recruiter user. I used the public demo’s existing samples, without creating an account or submitting a record.

Two details mattered:

• The talent view showed application, position and profile tabs. Switching to the recruiter sample changed the navigation to application management, positions and a talent pool, with a managed-position view in the main area.
• During the switch, the preview dialog said it included unpublished changes and warned that adding, editing or deleting data would modify the connected source. I acknowledged the notice and continued with read-only inspection.

Role preview is not an isolated data sandbox. This was a successful check of the supplied role-preview flow, not an independent test of authentication or record isolation.

The publishing guide documents role simulation and distinguishes preview from the published app. Subsequent layout or page changes need publishing to update the live version.

Separate the interface rehearsal from the data-write rehearsal

Use read-only navigation first. Before trying an approval, deletion or notification action, connect disposable test data or establish an appropriate recovery plan for the source being used.

Do not plan a data rollback around closing a preview window. Record which system receives each write and how the test record will be restored.

The demo observations cover its supplied template and preview interface. No AI generation, production-data mutation, paid-plan workflow or separate-account security test was performed.

Check record restrictions separately from a hidden button

Softr’s permissions documentation separates interface visibility from data permissions. A page, block or action button can be visible to one group while record access needs its own rule.

A client-shaped navigation menu is not evidence that another client’s records are denied. Match the record owner to the intended user, then check the underlying view and action under separate accounts.

For a proposed two-client request portal, keep Client A’s request and Client B’s request easy to distinguish. Check the direct record URL, the editable fields and the result of a prohibited action, as well as the list each client sees.

That is a suggested acceptance exercise for an owned test app. The public demo role switch did not complete it.

Check current entitlements by feature. The pricing page now uses Pro, listing granular permissions there and global data restrictions under Business. Some documentation still uses the older Professional label; do not assume a name match establishes the entitlement.

Use the Airtable migration copy as a verification target

Softr’s October 20 announcement describes two different operations. Import base brings Airtable data and automations into Softr Database; Migrate app makes an app copy connected to Softr Database so it can be tested before switching.

For an existing client portal, inspect that copy against the original user journey. Check record relationships, owner fields, filters and the actions that depend on them before changing the live workflow.

The useful decision is whether the copied workflow behaves correctly with its new source. The presence of a migration command does not complete that acceptance check. No Airtable migration was performed for this review.

Budget for the audience and repeated workflow actions

The current pricing page separates builders from app users and distinguishes team users from client users. It also lists database records, workflow actions and AI allowances.

Its user-counting FAQ uses unique emails across published apps. A small editing team can therefore serve a much larger audience, while that audience still needs to fit the chosen allowance and user category.

For an operations queue, estimate actions per request, including retries. The current pricing FAQ says workflows pause when the monthly execution allowance is reached; an attractive form does not keep a downstream approval running after that limit.

The October 20 update adds workflow usage history under Settings > Plan & billing. It describes the last 90 days of runs, steps and credits. Use actual history to revise the estimate after a pilot; no usage history from a paid workspace was inspected here.

Next step: rehearse one request before inviting a client

Use a two-client, one-team-member pilot with a status and due date for each request. This retains the portal’s core workflow while keeping mistakes easy to identify.

1. Write the roles, record owner field and permitted actions.
2. Build the intake-to-resolution journey, then inspect the data relationships and visual blocks.
3. Use role preview for a read-only interface check before preparing disposable data for writes.
4. Test separate client accounts, including a direct-record request that should be denied.
5. Change a test source field and inspect the app result. Run the workflow twice and check duplicate updates or notifications.
6. Record the required plan, source owner, recovery method and workflow-action budget before publishing the pilot.

Continue when the intended maintainer can repeat the permitted and denied cases and account for the connected services. For a public content site, evaluate publishing and search requirements separately from the private portal.

If an independent source handoff is central, compare Lovable or Replit. Consider Base44 for a prompt-led managed business app, and verify its particular export and backend boundaries.