Appearance
Table Access
Table Access controls which Project Users and User Groups are permitted to view, add, modify, or delete records in a Project Database table.
Configure Table Access when a table contains information that should not be available to every visitor or when different users need different capabilities. A table may support public submissions, signed-in user workflows, administrative management, or a combination of these uses.
Table Access is part of the Project's security model. It works alongside Page Settings, Users, User Groups, and trusted server-side processing through Cloud Flow.
A Page being accessible does not automatically make its Database records accessible. Equally, hiding an action or restricting a Page is not a substitute for protecting the underlying data operation.
Why Table Access Matters
The same table can be used through several different interfaces.
For example, a Registrations table may be used by:
- A public event-registration Form that creates a new registration.
- A signed-in visitor checking their own registration.
- An administrative Data Table Widget for reviewing registrations.
- Page Flow or custom JavaScript using the ioLoop Client API.
- Cloud Flow that verifies capacity before accepting a registration.
- An AI Agent with a configured Table Knowledge Source.
These uses should not necessarily have the same permissions. Public visitors might be permitted to submit information without being allowed to list existing registrations. Administrators may need broader record-management access. A registration-specific workflow may need additional checks before revealing or changing a record.
Plan table permissions around the operations that users actually need to perform, rather than granting broad access to make an interface easier to build.
Access Operations
The access editor uses the labels View, Add, Modify, and Delete. API and workflow documentation may describe the same operations as Read, Create, Update, and Delete.
| Editor Label | API Term | What It Allows | Example |
|---|---|---|---|
| View | Read | Retrieve table records for viewing or processing. | Display permitted orders in a customer portal. |
| Add | Create | Add a new record. | Submit a registration or support request. |
| Modify | Update | Modify an existing record. | Change a registration status. |
| Delete | Delete | Remove a record. | Delete an obsolete administrative record. |
Treat these as separate permissions. A user who can create a support request does not necessarily need to read every request. Someone permitted to read a record may not be permitted to update or delete it.
If the workflow does not need an operation, do not grant it merely because another operation is required.
Read Access and Data Exposure
Read access is particularly important for tables containing personal, financial, or operational information.
When a Page retrieves a record, the data may be available to browser-side JavaScript even if some fields are not displayed visually. Hiding a Data Table column, removing a text element, or filtering records after retrieval does not secure data already returned to the browser.
Limit the data that can be retrieved, and use a trusted server-side workflow when a user should receive only an authorized subset of records or fields.
Project Users and User Groups
Project Users are the people using the published application. They are distinct from Creators who collaborate on building the Project in the Project Editor.
User Groups help organize Project Users for access and application behavior. For example, a Project may have groups for customers, support staff, reviewers, or managers.
Common access patterns include:
| Application Pattern | Intended Access |
|---|---|
| Public submission | Public visitors may create a record without being allowed to list or modify other records. |
| Member portal | Signed-in users interact with records permitted by the application's authorization rules. |
| Review team | A designated User Group may read and update relevant records. |
| Administrative table | Administrative users can manage records required for their responsibilities. |
| Read-only reference data | Visitors may read records but cannot change them. |
These are example policies, not permissions automatically created by ioLoop. Configure the applicable Table Access options and any additional authorization required by your workflow.
For setup and membership management, see Users and User Groups.
Configuring Table Access
Table permissions should be configured as part of table setup and reviewed whenever the table's use changes.
A typical workflow is:
- Open the Project in the Project Editor.
- Go to Backend → Database.
- Select the table whose access needs to be configured.
- Open the table's access or security configuration.
- Review the available View, Add, Modify, and Delete permissions.
- Configure the appropriate permitted user contexts or User Groups using the options supported for that table.
- Save the configuration.
- Test allowed and denied operations using the intended user contexts.
The available choices depend on the table's access configuration and the Project's user and group setup. Configure the options shown in the editor; do not assume that every business rule can be expressed as a table-level permission.
Example: Event Registrations
Consider an application that allows visitors to register for events and permits administrators to manage registrations.
A permission plan might be:
| User Context | View | Add | Modify | Delete |
|---|---|---|---|---|
| Public visitor | No general listing | Submit registration | Not generally | No |
| Signed-in attendee | Authorized registration only | As needed | Authorized changes only | Not generally |
| Event administrator | Manage registrations | Add registrations | Manage registrations | If required |
This table describes the intended application policy, not a specific ioLoop configuration screen.
If a signed-in attendee may view or edit only their own registration, the workflow must verify record ownership or another valid authorization condition. A table-level permission to read or update records should not be assumed to enforce that per-record restriction automatically.
If registration capacity must be checked before accepting a new record, use trusted processing that checks and enforces the capacity rule. Simply allowing Create access does not establish such a business rule.
Table-Level Permissions vs. Record-Specific Rules
Table permissions address whether an operation is permitted at the configured access scope. Some applications also need rules that depend on which record is involved.
Examples include:
- A customer may read their own order but not another customer's order.
- An employee may update a ticket assigned to their team.
- A reviewer may approve a request only while it is in a reviewable state.
- A registration may be changed only before the event's cutoff date.
- An administrator may update a record but may not change certain protected values through a particular workflow.
These requirements can go beyond a general Read, Create, Update, or Delete permission.
When designing record-specific or field-specific restrictions:
- Identify the rule that determines which records or values are permitted.
- Determine which supported access controls can enforce it.
- If trusted record-specific validation is needed, implement it in Cloud Flow or another appropriate trusted Backend operation.
- Verify the current caller and the target record using trustworthy context.
- Return only information the caller is authorized to receive.
Do not treat a client-supplied record ID, user ID, group name, or hidden Form value as proof of authorization.
For server-side authorization, see Cloud Flow Access Security.
Page Access vs. Table Access
Page access and table access are separate concerns.
| Control | What It Governs |
|---|---|
| Page Access | Whether a visitor can open a Page under its configured restrictions. |
| Table Access | Whether a Database operation is permitted for the relevant user context. |
| Visible controls | Which actions the interface presents; this alone does not enforce data security. |
| Cloud Flow authorization | Whether a specific trusted server-side operation is allowed under the application's rules. |
For example, an administrative Page may be restricted to an Admin context. Its Data Table still needs an appropriate data-access model. Conversely, a public Page that contains a registration Form may legitimately need Create access without granting visitors general Read access to the Registrations table.
Use Page Settings to configure Page restrictions. Use Table Access and trusted Backend checks to protect data and operations.
Frontend Database Access
Pages, Forms, Data Table Widgets, Data Design, and Page Flow can interact with Project data through supported ioLoop Client APIs.
Fully custom frontend implementations using HTML, CSS, and JavaScript can use those same Client APIs. Built-in Forms, Widgets, and Page Flow blocks are development abstractions, not a separate privileged data-access path.
Regardless of the frontend approach:
- Database operations must follow the configured access model.
- Browser-side logic must not contain private credentials or trusted authorization decisions.
- Hidden or disabled controls are presentation choices, not permission checks.
- Data that a user must not receive should not be fetched into the browser and then merely hidden.
For frontend integration patterns, see Using Database from Pages.
Named Queries and Access
Named queries are useful for reusable retrieval patterns such as filtering, sorting, or selecting relevant records.
However, a query and an authorization rule are not the same thing.
For example, a query that loads a record using a customer ID supplied by the browser must not automatically be treated as secure merely because it returns only one record. The application must also ensure that the caller is authorized to access that record.
When using named queries:
- Apply the applicable Database permissions.
- Validate query inputs that affect sensitive data selection.
- Use trusted Backend checks for ownership, privileged filtering, or other protected rules where necessary.
- Avoid returning broader data than the current workflow requires.
For query creation and usage, see Queries.
Cloud Flow and Table Access
Cloud Flow runs on the server and is appropriate when an operation needs trusted validation, centrally enforced business rules, or protected integrations.
A Cloud Flow workflow may need to:
- Confirm the caller's authenticated identity or authorized context.
- Check membership in the required User Group.
- Verify record ownership or another record-specific rule.
- Validate status transitions or capacity limits.
- Perform permitted Database changes as part of a larger operation.
- Return only the authorized response to the caller.
Server-side execution does not automatically make every requested action appropriate. Cloud Flow must enforce the intended application rules and should not trust arbitrary identity or record values supplied by frontend code.
Cloud Flow access settings govern who may invoke a workflow, while its processing logic may still need to decide whether the requested operation itself is authorized.
For implementation details, see Using Database from Cloud Flow and Cloud Flow Access Security.
AI Agents and Table Access
An AI Agent may access Project data through a configured Table Knowledge Source or function-based workflow.
When enabling such functionality, decide which records the Agent is supposed to retrieve or modify and which users should be able to request those actions.
Review both the Agent configuration and the access or authorization applied to its underlying data operations. Do not assume that an Agent's instructions or the way it presents responses are sufficient to restrict sensitive data.
For more information, see AI Agents and Table Knowledge Sources.
File Fields and Access
A Database table may contain file fields associated with records, such as receipts, attachments, or uploaded documents.
A file's association with a record does not, by itself, establish that it is private. Review the supported rules and workflows used to list, upload, retrieve, download, or delete files.
Do not use public Frontend Media for files that require restricted access. Media assets are designed to be browser-loadable public resources.
For Database-associated files, see File Fields.
Testing Access in Preview
Test permissions from the Page or operation that will actually be used, not just from the Database editor.
During Preview, ioLoop automatically directs all built-in Database operations to the Project's development database. Reads, creates, updates, and deletes through those built-in operations do not target the published application's production database.
The Preview user-context selector can help test Public, Any User, configured User Groups, and Admin behavior where supported. Database permission testing still requires checking that the operation itself is permitted or denied as intended.
Access Test Matrix
| Test | Expected Result |
|---|---|
| Public visitor submits an allowed request | Create succeeds without exposing unrelated records. |
| Public visitor attempts an unauthorized read | Read is denied or returns no protected data, according to the enforced policy. |
| Signed-in user accesses an authorized record | The permitted operation succeeds. |
| Signed-in user attempts another user's record | Record-specific authorization prevents disclosure or modification where that restriction is required. |
| Read-only user attempts Update or Delete | The forbidden operation is denied. |
| Authorized administrator performs a permitted operation | The operation succeeds. |
| Unauthorized caller invokes a protected Cloud Flow | The workflow rejects the call or operation appropriately. |
| Form, Widget, Page Flow, or custom JavaScript uses a restricted table | The same underlying data-security expectations are enforced. |
Where possible, test both expected success and deliberately denied operations. Include direct Client API paths, not only the buttons and Pages intended for normal users.
External services require separate checks. Although built-in Database operations use development data during Preview, a Cloud Flow workflow, custom request, or Integration may contact an external system using its configured environment. Do not assume that Preview automatically switches every connected service to test mode.
For details, see Previewing and Development and Production Data.
Reviewing Access Before Publishing
Before publishing a workflow that uses a Database table:
- Confirm which Pages, Forms, Widgets, AI Agents, and APIs access the table.
- Review the intended View, Add, Modify, and Delete permissions.
- Verify User Group assignments and Page restrictions where applicable.
- Identify any record-specific or field-specific authorization rules that need trusted enforcement.
- Test allowed and denied operations with development data.
- Verify the applicable Cloud Flow access settings and protected operations.
- Publish the Project when the configuration is ready, then verify important access paths in the published application.
Changes to permissions can affect multiple Project components that reference the same table. Review those dependencies whenever access rules change.
Good Practices
- Start with least privilege. Grant each user context only the operations it needs.
- Treat operations separately. View, Add, Modify, and Delete serve different purposes.
- Design access with the workflow. Understand who uses each table before making it available to frontend components.
- Distinguish table permissions from record-level rules. Add trusted authorization where an operation depends on ownership or other record properties.
- Use Backend processing deliberately. Choose Cloud Flow for server-enforced business rules and sensitive operations.
- Return limited data. Avoid sending records or fields the caller does not need.
- Test denied behavior. Verify that unauthorized operations fail appropriately, including direct API attempts.
- Review after changes. A new Page, Widget, Agent, or Integration can change how table data is exposed.
Common Mistakes
Avoid these patterns:
- Granting broad access simply to make Preview tests succeed.
- Assuming a restricted Page automatically secures every Database operation behind it.
- Treating hidden Buttons, Data Table columns, or conditional UI as authorization.
- Assuming a general table permission enforces record ownership or field-specific restrictions.
- Filtering sensitive records only after they have been returned to the browser.
- Trusting browser-supplied user IDs, group names, or record IDs without appropriate verification.
- Assuming a named query is automatically an authorization boundary.
- Assuming Cloud Flow access settings alone enforce all record-specific business rules.
- Treating AI Agent instructions as sufficient protection for table data.
- Testing only as Admin and never checking denied operations.
Table Access is most effective when the permissions on a table, the operations exposed to users, and any additional trusted authorization are designed together. That keeps data accessible to the workflows that need it without relying on the frontend interface as a security boundary.