ToolJet Permissions Separate Building From Configuration

A builder can use a data source in an application without being allowed to change that data source's credentials. That distinction is central to the platform's access model, and it is the first place to look when a public workspace is identified. On 2026-11-15, count-only ZoomEye probes used sub_type=all, page 1, and page size 1. app="ToolJet" returned 689 records, title="ToolJet" returned 694, and http.body="ToolJet" returned 19,422.

The application and title counts are close, while the body count is broad enough to include documentation and product mentions. All three are index observations, not a claim that every matching page exposes a production workspace. ToolJet's data-source documentation describes two distinct permissions: Build with and Configure.

A user with Build with can use an authorized data source in an app or workflow but cannot update its credentials. Configure allows the user to edit the configuration. The separation is useful, but it only works when custom groups, workspace membership, environment access, and released apps follow the same policy.

Inventory workspace authority List every workspace, its admins, builders, end users, custom groups, and super administrators. A workspace admin can manage users, groups, data, and apps within that workspace. A super admin can manage all workspaces and users across a self-hosted instance.

That broader authority needs a separate owner and a stronger recovery process. Review authentication at the instance and workspace levels. A workspace can inherit instance SSO or configure its own login.

If a workspace overrides the instance setting, make sure the redirect URI, client secret, and allowed user population are intentional. A disabled account should not retain access through a second workspace login path. Review data-source credentials For each data source, record who can configure it, which groups can build with it, and which apps or workflows use it.

Test a builder account that should not see credentials. Attempt to read the configuration through the UI and the API, then attempt to change the host, database, or token. The expected result is a denial before the credential is returned.

Environment permissions deserve their own test. A builder who can edit in development may receive production access through an inherited application permission. Check the exact environment scope and the release process.

A released app should not silently gain a new data source or a broader query merely because the workspace changed after release. Use the count as a review lead app="ToolJet" Open the exact ZoomEye search The 689 application observations are candidates for version, login, and workspace review. The title and body counts remain separate signals.

After confirmation, check whether self-service signup is enabled, which SSO path is active, and whether the public page exposes a workspace identifier. Do not enumerate workspaces or data sources without authorization. Test the boundary Create a group with Build with permission for one data source and no Configure permission.

Verify that it can run an authorized query and cannot edit the credential. Add a second source and confirm the group cannot see it. Remove the user from the group and test the active session.

Review workspace constants and variables with the same rigor, since they can contain secrets even when they are not data-source records. ToolJet's low-code model concentrates authority in a small number of configuration screens. The review should mirror that concentration.

The important question is who can reach the workspace, who can wire data into an app, and who can replace the credential behind that data.