Permissions and Access Control
Lotics has a complete identity and access management (IAM) system that controls who can see and do what across the entire workspace. Every table, view, app, document template, automation, and workflow is protected by the same authorization model. This works for both human team members and AI agents — API keys and the AI assistant follow the same permission rules as the person who created them.
Why this matters
In operational environments — where gate clerks, operations managers, accountants, sales reps, and external customers all touch the same data — access control is the difference between a toy and a system of record. A gate clerk should see container status but not billing rates. A customer portal should show only that customer's shipments. An automation should be able to update records on behalf of the team without giving the triggering user direct write access.
Lotics handles all of this through a single, additive authorization model with no configuration code required.
Organization roles
Every member has an organization-level role that sets their baseline permissions.
| Role | What they can do |
|---|---|
| Owner | All admin permissions. Assigned to the organization creator. Cannot be removed. |
| Admin | Full access to all resources. Create and manage any resource. Manage members, groups, settings, integrations. Transfer resource ownership. |
| Member | Create resources. Manage resources they own. Access resources shared with them. |
Admins have full access to everything — no resource-level grants needed. Members only see what is explicitly shared with them (or shared with the organization or their groups).
Resource roles
Each resource type has specific roles that control what a member can do with it.
| Resource | Available roles | What each role allows |
|---|---|---|
| Table | Viewer, Editor | Viewer: see data, press buttons. Editor: see and edit data. |
| App | User, Manager | User: use the app (view data, submit forms, trigger actions). Manager: edit app structure. |
| View | User, Manager | User: use the view. Manager: edit view configuration. |
| Skill | User, Manager | User: invoke the skill in chat. Manager: edit skill instructions. |
| Document template | User, Manager | User: generate documents from the template. Manager: edit template. |
Table management (schema changes, sharing configuration, visibility rules) is controlled by ownership: the person who created the table manages it. Admins can manage any table.
Sharing
Resources can be shared with three types of targets:
- Individual member — grants access to one person.
- Group — grants access to all members of the group. Adding a member to the group immediately grants them access. Removing them immediately revokes it.
- Organization — grants access to every member. New members automatically get access. Removed members automatically lose it.
Admins and resource owners can share resources. If a member receives access from multiple sources (direct share + group + organization), they get the highest role. The model is purely additive — there is no "deny" rule.
Groups
Groups are named sets of members used as sharing targets. They simplify access management when you have teams or departments that should see the same resources.
- Admins create and manage groups.
- A member can belong to multiple groups.
- Groups have no management powers — they exist purely for sharing.
- Deleting a group removes all access granted through it.
Example: create a "Finance" group, add the accountant and finance manager. Share the Invoices table with "Finance" as Editor. Both members can edit invoices. When a new finance hire joins, add them to the group — they immediately get access.
Ownership
Every resource has an owner — the member who created it. Ownership determines:
- Who manages the resource — the owner can edit structure, configure sharing, and delete the resource.
- Runtime authority — when automations, workflows, and apps execute, they run with the owner's current permissions (see below).
- Lifecycle — when a member is removed from the organization, their resources are transferred to an admin, and their automations are disabled.
Ownership is transferable by admins, which is important for offboarding.
Runtime authority for automations and apps
This is one of the most powerful aspects of Lotics permissions: automations, workflows, and apps run with the owner's permissions, not the triggering user's permissions.
What this means in practice:
- A gate clerk with Viewer access presses a button on a container record. The button triggers a workflow that updates the container status, generates a gate-in receipt PDF, and sends an email. The workflow succeeds because it runs with the owner's (admin's) permissions, even though the clerk only has Viewer access.
- An app built by an admin shows billing data from multiple tables. A sales rep with User access on the app sees the data through the app, even without direct access to the billing tables.
- An automation triggers when a record is created. It queries a related table, cross-checks values, and updates a third table. All of this works because the automation runs with the owner's permissions, not the triggering event's context.
The rule: if the owner is an admin, the workflow/automation/app has full access. If the owner is a regular member, it can only access resources the owner can access. If the owner loses access, the workflow fails.
API keys and AI agents
API keys act as the member who created them — same access, same visibility rules. When the member's permissions change, the API key's effective permissions change immediately.
The AI assistant in the chat acts as the chatting member. It can only access what that member can access. This means:
- An admin chatting with the AI assistant can ask it to do anything across the workspace.
- A member chatting with the AI assistant can only interact with resources shared with them.
- API keys created by an admin have full access. API keys created by a member have the member's access.
Data visibility rules
Tables support row-level and field-level visibility rules that further restrict what members can see. For example: "sales reps see only their own deals" or "the commission field is hidden from non-managers."
Who bypasses visibility rules:
- Admins
- The table owner
- Workflows/automations/apps owned by admins
Who follows visibility rules:
- All other members, regardless of their table role
- API keys (follow the creating member's rules)
- Workflows owned by non-admin members
Visibility rules are enforced on all data access paths: direct table access, views, search, filters, exports, and real-time updates.
Linked records and cross-table access
Tables can link to records in other tables. When a record links to a record in another table, the linked record's display text is visible to anyone who can see the link field.
- No access to linked table — you see the display text only, cannot expand or navigate to the linked record.
- Access to linked table — you can see the linked record based on your own permissions.
- Linked record hidden by visibility rules — display text is not shown.
The share dialog offers automatic linked-table grants: when sharing a table, you can opt to automatically share its linked tables with the same principals. This ensures that users who need to see related data don't hit permission walls.
Lifecycle events
Member removal (offboarding)
When a member is removed from the organization:
- Automations they own are disabled.
- Ownership of their resources is transferred to an admin.
- All role bindings, group memberships, connected accounts, and API keys are removed.
No resources are deleted — everything is preserved under new ownership.
Admin demotion
When an admin is demoted to member, their resources that depended on admin-level access (automations accessing all tables, apps showing all data) will fail at execution time. They lose full data access and can only access explicitly shared resources.
Resource deletion
- Table deleted — views on the table deleted, automations referencing it disabled, attached workflows deleted.
- App deleted — app action workflows deleted.
- Group deleted — all access granted through it removed.
Frequently asked questions
Can I give a customer access to only their own data?
Yes. Create an app that filters data by customer, share it with the customer as User. The app runs with the owner's permissions, so the customer sees only what the app exposes — they don't get direct table access. Combined with visibility rules, you can ensure customers see only their own records.
Can an automation access tables that the triggering user cannot?
Yes. Automations run with the owner's permissions, not the triggering user's. If the owner is an admin, the automation has full access. This is the core mechanism that makes shared workflows useful — a Viewer can press a button that triggers writes to tables they cannot access directly.
What happens when someone leaves the team?
Their automations are disabled, their resources are transferred to an admin, and all their access is revoked. No data is deleted. The admin can re-enable automations after reviewing them.
Can I restrict which fields a team member can see?
Yes. Field-level visibility rules let you hide specific fields from specific members. For example, hide the "Commission" field from everyone except the finance team.
How do API keys work with permissions?
An API key inherits the permissions of the member who created it. If that member is an admin, the API key has full access. If the member's role changes, the API key's effective permissions change immediately. API keys are created in Settings and use the format ltk_ followed by 48 characters.
Can I scope an AI agent's access?
Yes. Create an API key under a member account with the appropriate level of access. The agent using that API key will have exactly the same permissions as that member — no more, no less. For full access, use an admin's API key. For restricted access, create a dedicated member account for the agent and share only the resources it needs.