A form or widget has a Scope that controls who may use it. The app's server permissions control what its code may do. Configure both: a narrowly scoped interface can still expose too much data if its server action returns unrestricted records.
Choose Scope when adding a Form or Widget group, or open the group's settings from its menu in Project files. Saving the group's settings changes the draft configuration; publish the intended version before testing the shared interface.
What you’ll have at the end
A published form or widget tested against the audience you intend to admit.
- Choose scope
- Configure policy
- Publish version
- Test visitor access
Before you start
- A working Form or Widget group
- An intended audience
- Separate test sessions for allowed and denied visitors
On this page
| Scope | Intended caller | Additional configuration |
|---|---|---|
| Public | A visitor without contact or admin access | Optional PIN |
| Contact | A signed-in user linked to an eligible contact in this organization | Contact types, segments, and tags |
| Admin | A signed-in organization user with the required permissions | Required organization permissions |
| Custom admin action | A supported action inside the admin workflow | Currently the application-submission acceptance action |
Scope is not a way to change an external API key's permissions. External integrations use their own server-side credentials, while the form/widget runtime checks the visitor and the group's access policy.
Public access does not require a contact or admin account. If you set a PIN, the published app requires that PIN before loading or running the group. A shared PIN is not a per-person identity: everyone who knows it has the same shared secret.
Keep the form or widget's output appropriate for that audience. Do not use a public widget to return private member records solely because the server has Members Read access. A PIN does not supply record-level ownership rules for your custom action.
Test the published link with the correct PIN and with an incorrect or missing PIN. The runtime can return a not-found response for denied access; this does not necessarily mean the group was deleted.
Contact access requires a signed-in user with a matching contact in the app's organization. The current matching rules are:
- If contact-type/segment entries are configured, at least one entry must match the contact's type.
- Within a matching type entry, an empty segment selection imposes no segment restriction; otherwise at least one selected segment must match.
- Every configured tag must be present on that same contact.
An empty type/segment list or tag list adds no restriction for that part of the check. It does not remove the requirement for an eligible signed-in contact. A user with several contact records is admitted when at least one record satisfies the combined rules.
Test a matching contact, a contact missing a required tag, and a signed-out visitor. Do not use your organization-owner session as the only access test.
Admin access requires a signed-in organization user whose permissions satisfy the group's configured requirement. Choose the actions needed to use this interface, not every action the app's server might perform internally.
Client permission requirements and server permissions are independent. A user may be permitted to open a widget while the server lacks the access needed for an API call. Conversely, the app's server may have broad access that the widget must never expose to every admitted user.
When a server action accepts a record ID, verify that the operation is appropriate for the caller and workflow before returning or changing the record. Do not treat a hidden client control as enforcement.
The current configuration supports acceptSubmission. It is not a generic mechanism for inventing new admin actions by entering an arbitrary string. The runtime checks application-submission Edit permission for this scope.
Use the matching application review workflow and test its input and outcome there. Do not advertise its share URL as a public form. A successful standalone simulation does not prove that the action is wired into the intended admin flow.
After publishing, test both allowed and denied callers for the actual shared link or embedding context. Check loading and server-action execution: the public runtime enforces access again when an action runs.
When access fails, review the published version, group Scope, PIN, organization, linked contact, type/segment/tag requirements, and required admin permissions. A 404 can deliberately conceal an inaccessible group. For a group that loads but fails during its server action, inspect server access and logs separately.
Check your result
- Allowed visitor
- The published interface opens as intended.
- Unapproved visitor
- The scope rejects access.
- Owner simulation succeeds
- Still test the published visitor policy separately.