For your AI agenthttps://lotics.ai/docs/apps.md

Apps

An app is the interface a desk actually works in — a docs cockpit, a sales desk, a quotation app, a driver's delivery screen. Apps live on the /apps route and read and write the same records as the rest of the workspace.

We build them. Apps are real code, not a configuration you assemble: written against a typed SDK, built, and deployed to your workspace. That is what lets an app match how a job actually runs instead of how a builder's component palette allows. Your team never touches a builder — they open the app and do the work.

Why an app rather than a table view

Not everyone should navigate a table with forty columns. A warehouse worker needs a form to log incoming goods. A finance director needs a summary with charts. A customer needs a portal showing their order status and nothing else. Each of those is a different shape of the same data, and each is a different app.

They are not separate systems. The apps share one dataset underneath: the operations desk, the documents desk, and the billing desk read and write the same records. One source of truth, many purpose-built views onto it.

What an app can do

An app declares three kinds of capability up front, and can use nothing it hasn't declared. That declaration is what makes an app safe to share — including publicly, with no Lotics account.

Queries read data. Each is a fixed template naming its tables, joins, filters, and columns; callers only fill typed parameters. An app can't widen its own reach at runtime, and a query that scopes to "the current member" resolves to whoever is using the app.

Workflows are the only way an app writes. Every create, update, and delete goes through a declared workflow with a typed input schema, so table rules, validation, and audit logging all apply. A workflow can create and update records, generate documents (PDF, Excel, Word) from your templates, send email, call external APIs, and chain multi-step logic with conditions and loops. A file uploaded into an app stays inert until a workflow attaches it.

Agents are for the open-ended work — reading a messy document, drafting an estimate, reconciling two spreadsheets against each other. An agent declares the tools and knowledge docs it may use, streams its progress into the app as it works, and can stop mid-run to ask the user a question before continuing. It reaches records only through the app's own declared queries and workflows.

Actions are deterministic and fully logged. A "Generate Invoice" button pulls the order's line items, fills your Excel template, converts it to PDF, and emails it — the same way every time, with an execution log and a report of exactly what the run created.

Restricting where an action can run

RestrictionDescription
GeofencingOnly allow (or deny) submission within a radius of GPS coordinates. For field work that must happen on-site.
IP addressOnly allow (or deny) submission from specific addresses. For securing actions to an office network.

Permissions

Apps run under the authority of the person who owns them, and expose only what they declared — so a caller, including an anonymous visitor to a public app, can invoke exactly the declared queries and workflows with typed parameters and nothing else. Per-input constraints bound the values they may pass.

Where an app scopes data to the current member, that resolves to the person using it. On a public app with no signed-in user, such a query is refused rather than widened — an app never serves the rows a scoping filter existed to protect.

Data freshness

Apps read through the same pull-based layer as the rest of the platform. Data refreshes when the app regains focus, when the connection is re-established, and after any action that changes it — so the numbers on screen reflect what a workflow just wrote. There is no server push: a change made by another person appears on the next revalidation, not the instant they make it.

Common use cases

KPI dashboards. Metrics from several tables on one screen — throughput, revenue, SLA compliance — with date filters for switching between weekly, monthly, and quarterly views.

Data entry. Warehouse staff scan goods in, drivers confirm drop-offs, inspectors submit checklists. The data lands in the same records the back office reads.

Document desks. The incoming set arrives, AI drafts the outgoing documents from it and flags the numbers that don't agree, and the team reviews before anything is sent.

Customer portals. External users see their own order status, shipment tracking, and document downloads without a Lotics account, scoped to their records only.

Field operations. Mobile-friendly screens with geofenced actions — a delivery confirmation that collects signature, photo, and notes, and submits only within 200 metres of the address.

Frequently asked questions

How do I get an app?

You tell us what the desk does and we build it. New apps and changes to existing ones are part of the plan for as long as you're a customer. Your industry's app set usually exists already, in which case we install it and fit it to your templates and rules.

Where do apps live?

On a dedicated Apps page in the main navigation. Each app also has a direct link you can share.

Do apps update in real time?

They refresh on focus, on reconnect, and after any action that changes data. There is no server push, so another person's edit appears on the next refresh rather than the instant they make it.

Can non-technical users build apps?

They don't need to — that's our job, and it's included in the plan. The workspace itself (tables, fields, views, document templates, automations) is configurable through the AI assistant if your team wants it, but the apps a desk works in are built and operated by us.

How do app permissions work?

An app can only do what it declared, and every write travels a declared workflow. Data scoped to the current member follows whoever is using the app. See Permissions for the full authorization model.

Can I create a customer-facing portal?

Yes. An app can be shared publicly, with access scoped to that customer's own records. The declare-up-front model is what makes this safe: an anonymous visitor reaches exactly the declared queries and nothing else.

What happens if an action fails?

The app shows the error and keeps the form's current state so nothing is lost. The run's log records what happened, including anything it had already created.