Custom Web Applications
Client Portal Builders: Compare and Test Record-Level Permissions
Compare documented permission models in Noloco and Softr, then use a practical worksheet to test client records, staff access, files and account removal.
Choose a portal builder around the records each person may access
The best client portal builder for record-level permissions depends on your data relationships and the actions each user must perform. Start with a rule such as “a client can see projects belonging to their organisation, while an assigned staff member can update those projects.” A feature label alone cannot establish whether that rule is enforced throughout your workflow.
This guide compares documented capabilities and provides an original evaluation worksheet. The documentation was reviewed on 1 November 2026. It is not a hands-on platform benchmark, a security certification or a ranking of vendors. Confirm current plan availability and test the proposed configuration before selecting a platform.
If you are still defining the portal’s purpose, begin with client portal features, roles and security planning.
Separate sign-in, page visibility and access to individual records
Authentication establishes who is signed in. Page visibility determines which interface a user can open. Record-level permissions determine which records that person may retrieve or change. A hidden button or filtered list should not be treated as proof that an unauthorised request is rejected.
| User | Allowed work | Work to deny |
|---|---|---|
| Client A contact | Read Client A projects and submit an agreed request. | Retrieve Client B records or change the organisation assigned to a project. |
| Assigned staff member | Update projects allocated to that staff member. | Export unrelated customer records or grant themselves administrator access. |
| Portal administrator | Manage accounts and approved administrative tasks. | Perform undocumented actions outside the agreed operating responsibilities. |
| Former client contact | Only the explicitly retained access, if any. | Continue access merely because an old link or session exists. |
Use stable relationships between users, organisations, projects and files. A record with no organisation or an incorrectly linked account is an important exception to test. Define what should happen when the relationship is missing instead of allowing a convenient default to expose data.
Compare the documented controls before running your own tests
| Platform | Documented approach | What to confirm for your portal |
|---|---|---|
| Noloco | Record-level permission rules use roles and relationships; the documentation distinguishes API-level enforcement from interface filters. | Model client organisations and assigned staff, then test each required operation and the current plan entitlement. |
| Softr | Global data restrictions apply rules to tables and user groups. Its guide distinguishes view permissions from create, edit and delete restrictions. | Confirm action permissions on the selected plan and verify coverage of every component used in the portal. |
Noloco’s record-level permission guide explains the relationships needed to express access rules. Use it to prepare a candidate configuration, then validate the complete workflow rather than assuming a single rule covers every requirement.
Softr’s global data restrictions guide states that view restrictions are available across plans, while create, edit and delete restrictions require Business or above at the review date. It also identifies the Comments block as outside global data restrictions. Treat that exception as a specific design question if your portal uses comments.
This shortlist is not exhaustive. The documentation confirms that relevant mechanisms exist; it does not prove that either product is configured correctly for your data. Ask for the exact plan, data source, components and limitations in a proposal. Do not compare an entry-level quote for one platform with a different permission scope on another.
Run allowed and denied scenarios with isolated test data
Create two fictional client organisations, one staff account and an administrator in an environment you own or are authorised to test. Use non-sensitive sample projects and files. Agree expected results first so a convenient interface result cannot redefine the intended permission rule.
| Test | Expected outcome | Evidence to record |
|---|---|---|
| Client A opens its own project | Permitted fields and operations are available. | Role, test record, action and observed result. |
| Client A requests Client B’s project using a known test identifier | The unauthorised record is not returned. | Request route and denied response, with no real customer data. |
| Client A tries to reassign a project to another organisation | The operation is denied unless explicitly authorised. | Attempted change and unchanged stored relationship. |
| A user follows another client’s file link | File access follows the intended permission policy. | Authenticated and signed-out outcomes where relevant. |
| A staff assignment or account is removed | Access changes according to the documented policy. | Session state, time of change and subsequent result. |
| Search, exports, comments and related-record selectors are used | They do not expose information outside the agreed scope. | Results from every enabled access path. |
Keep a separate observed-result column and mark untested paths as untested. A permissions screenshot is useful configuration evidence, but it is not a substitute for an executed denied-access test. Retest after changes to roles, data relationships or portal components.
Download the editable worksheet (Markdown). Copy it into your preferred editor and record your own evidence.
Choose from demonstrated fit and operating responsibility
- Write the access matrix and identify the sensitive records and actions.
- Confirm the selected platform and plan can express the rules.
- Build a small authorised proof of fit using isolated data.
- Run the acceptance worksheet and resolve failures or unsupported paths.
- Assign account administration, support and change-review responsibilities.
- Record why the chosen option fits and which limitations remain.
OWASP’s authorization guidance recommends least privilege, denying access by default and validating permissions on every request. Use those principles when reviewing the implementation; a checklist cannot certify an application as secure.
If a platform cannot support an essential rule, examine whether the workflow can be simplified or whether a different implementation is justified. Custom development also needs a clear permission model, verification and ongoing ownership. It is not automatically a safer option.
Questions about choosing a client portal builder
Which builder has the best record-level permissions?
There is no universal winner established by this review. Compare the exact role, organisation and action rules your portal needs, then choose using documented capabilities and executed tests.
Can I rely on hiding a page or button?
No. Interface visibility helps usability, but the underlying record and action must also be protected. Test access paths that bypass the visible control.
Should I test with real client records?
Use isolated fictional data for the proof of fit. Keep permission and security testing within systems and accounts you are authorised to assess.
When should I consider custom development?
When essential rules or integrations cannot be supported by a maintainable configuration and the business can fund implementation, verification and ongoing support.