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 — an API key and the AI assistant are bound by the same authorization model as everyone else.

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.

Admins have full access to everything else — no resource-level grants needed. Members only see what is explicitly shared with them (or shared with the organization or their groups).

Knowledge documents and document templates stay private, even from admins. An admin sees that each one exists, what it is called, who owns it and who it is shared with — in the Library, open the View menu and choose All in your organization. To open one, use it in chat, or generate from it, the admin needs it shared with them: the owner shares it, or the admin grants themselves access from the Library. Granting yourself access is recorded in the access log, like any share. The AI assistant follows the same rule, so an admin’s assistant never answers from a colleague’s private document. An API key that is not a person keeps the access chosen when it was created.

Resource roles

Each resource type has specific roles that control what a member can do with it.

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.

Standing in while you are away

In an app where each step of the work has an owner — a request waiting on the director, a payment on the accountant — the step should not stall while its owner is on leave. Set it yourself in Settings → Away: the first and last day you are away and the colleague who stands in for you.

• On those days, every step that is yours — by name, or through a group you are in — also waits on the one standing in. The step says so: “Lê Văn Sơn · thay Trần Thị Mai đến 08/10” (standing in for Trần Thị Mai until 08/10).
• It stays yours too: you can still act on it.
• The one standing in reaches it only through apps they can already use, and never approves a request they made themselves or a second level of the same request.
• Only a colleague who works in your organization now can stand in.
• An absence runs at most 60 days, the first and last both counted; to stay away longer, set it again. Press End absence to end it early.
• An admin can end anyone’s absence: in Settings → Members, where each member away is marked on their row, open the member and press End absence.
• Each absence set or ended is written to Settings → Access log, naming who did it.

Ownership

Every resource has an owner — the member who created it. Ownership determines:

1. Who manages the resource — the owner can edit structure, configure sharing, and delete the resource.
2. Runtime authority — when automations, workflows, and apps execute, they run with the owner’s current permissions (see below).
3. 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

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, except to knowledge documents and templates, which must be shared with the owner. If the owner is a regular member, it can only access resources the owner can access. If the owner loses access, the workflow fails.

Who can build apps

Building an app is the owner’s because an app runs with its owner’s permissions: what you build reaches exactly what you reach, and no more. That is also why a Manager share does not let you build somebody else’s app — you would be writing something that runs with their access, not yours. Share the app with them as Manager if they should run it; transfer it to them if they should build it.

Sharing an app with anyone who has the link is an admin’s decision, because the people it reaches are not people the organization can ask.

Transferring an app to a new owner clears who it is shared with, including a public link. The app’s reach follows its owner, so the new owner decides who sees it rather than inheriting an audience.

API keys, terminals and AI agents

A key an admin creates in Settings has its own access, chosen on the key: All apps and tables, or Only selected ones — and for the second, which apps and tables, picked from every workspace in the organization and each at its own level. That list is changed on the key’s own screen at any time; a resource’s Share dialog shows a key that reaches it and lets that access be taken away, but adds none. Its Can setting narrows the key further, never widens it. What a key creates belongs to the key, and an admin can transfer any of it to a person. A key created for a person carries that person’s access instead — the key list shows Acts as and their name for one — and it stops working when that person is removed.

A command-line sign-in (lotics auth login) acts as you. You can see and end it yourself at Settings -> Security, and lotics auth logout ends it too — either way it stops working for good and leaves the list. A key belongs to the organization, so logging out only removes it from your machine.

An AI assistant you connect over MCP — ChatGPT, Claude — also acts as you, in the one workspace you approved it for. You can see and disconnect it at Settings -> Security, and an admin can see and disconnect members’ at Settings -> API keys. Disconnecting ends its access at once; removing it inside the assistant does not.

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, except use a knowledge document or template not shared with them.
• A member chatting with the AI assistant can only interact with resources shared with them.
• A key set to All apps and tables reaches the whole organization. A key set to Only selected ones reaches the apps and tables named on it, and nothing else.

Data visibility rules

Tables support row-level visibility rules that further restrict which records members can see. For example: “sales reps see only their own deals.”

Who bypasses visibility rules:

• Admins
• The table owner
• Workflows/automations/apps owned by admins
• API keys set to All apps and tables

Who follows visibility rules:

• All other members, regardless of their table role
• API keys set to Only selected ones, and command-line sign-ins (which follow the rules of the person they act as)
• Workflows owned by non-admin members

A key set to Only selected ones follows the rule as itself, and a rule written against whoever is asking — “sales reps see only their own deals”, which reads a field holding people — matches no key, so a table given to one that way answers it with no rows at all. Give the key a table whose rule does not depend on who is asking, or set it to All apps and tables.

Visibility rules are enforced on all data access paths: direct table access, views, search, filters, exports, apps, and the API.

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.

Sharing a table grants that table and nothing else — a linked table needs its own share.

Lifecycle events

Member removal (offboarding)

When a member is removed from the organization:

1. Automations they own are disabled.
2. Ownership of their resources is transferred to an admin. That includes the table checks they saved, which from then on read records with that admin’s access, so the admin gets a notification in each workspace naming the checks that came to them.
3. All role bindings, group memberships, and connected accounts are removed, and so are their absence and every absence naming them to stand in. The access log records each of those other absences as ended by the admin who removed them.
4. Every credential acting as them is revoked — their command-line sign-ins, any key that acts as them, and the AI assistants they connected over MCP.

No resources are deleted — everything is preserved under new ownership. An app that changes hands this way also loses who it was shared with, so the new owner decides that afresh. If you restore the member later, their credentials stay revoked: they sign in and connect their assistants again.

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 — refused while an app or a workflow elsewhere still references the table. Once nothing does, the table’s views and its record lifecycle workflows are deleted with it.
• 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, except to knowledge documents and templates, which must be shared with the owner. 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, all their access is revoked, and every credential acting as them is revoked with them. An API key with its own access is not one of them — it is not that person — so the integrations running on it keep running. No data is deleted.

How do API keys work with permissions?

A key has its own access, set on the key: All apps and tables reaches the whole organization, Only selected ones reaches the apps and tables named on it and nothing else. A key’s Can setting narrows it further — a key that may only read data cannot write, whatever its Access reaches. Keys are created in Settings -> API keys and use the format ltk_ followed by 48 characters.

Can I scope an AI agent’s access?

Yes, on two axes. Create the key with Only selected ones and give it just the apps and tables the agent needs — it reaches those and nothing else — and set the key’s Can to the operations it actually performs.

Can a member build an app?

Yes. Any member can create one, and whoever creates it builds it. What the app can reach is what that member can reach, so a member’s app cannot show data they could not open themselves. Sharing it with anyone who has the link stays an admin’s decision.