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. An app is either stated in your workspace’s model — which fields each job reads, what each press writes — and drawn by the Lotics app runtime, or, where a job needs a screen of its own, written as code against a typed SDK. 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
An action can ask for the device’s location and refuse to submit outside a radius of GPS coordinates — for field work that must happen on-site. The reading comes from the device, so it records where an action happened rather than standing in for a permission check.
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.
Who the app is shared with is its owner’s to decide, or an admin’s. Sharing it with anyone who has the link is an admin’s decision alone, because it puts everything the app declares in front of people your organization cannot ask.
Steps and whose they are
Where work moves through steps — a request drafted, approved by the director, paid by the accountant — each step can name its owner: a person named on the record, or a group of your organization. Only the step’s owner can move the work on from it, and Lotics checks that on every press, not only on screen. At a step a group owns, the person who made the request never approves it, and someone who signed one level does not sign the next. A step can also say how many days it should take; past that, the record reads as overdue.
What waits on you comes first. The Apps page lists Waiting on you above your apps: every record, in the apps you can use, that stands at a step that is yours, the soonest due first, each opening in its app. Should an app’s records fail to load, the list names that app and lets you try again. Inside an app, the records waiting on you head its list. Someone on leave can name a colleague to stand in for them — see Permissions.
Building your own screens on an app
Sometimes the screen belongs somewhere else — a form on your own website, a customer area inside a site you already run, a script on your own server. The app’s declared queries and workflows are addressable endpoints, so that screen can read and write through them while the workspace stays the system of record. The declarations are what make it safe: a caller reaches exactly the queries and workflows the app declares, with typed parameters, and nothing else.
Publish the app’s API and those declarations become a promise. Publishing takes a numbered snapshot of exactly what each one accepts and returns, and hands you an OpenAPI document to generate a client from. From then on a change here that would break your code is refused rather than shipped — the way through is a new name beside the old one, so your callers move when they are ready. Ask us to publish it; the mechanics are in REST API.
A surface open to callers outside your team gets its own app. Sharing an app publicly, or giving a customer’s server a key to it, exposes everything it declares — there is no way to expose some of an app’s queries and not others. So the public part is built as a second app over the same tables: only the queries outsiders may read, each projecting only the columns they may see, and only the workflows they may run — a form anyone can reach has workflows to write and nothing to read at all. An app with no screens answers servers alone and is never shared publicly; once it declares a query or workflow, your apps list marks it API. The desk your team works in stays a separate, private app.
Data freshness
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. A change someone else makes reaches an open app on its own, without a reload. A publicly shared app has no signed-in connection, so it refreshes on focus, on reconnect, and after its own actions.
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 model usually exists already, as a preset we start your workspace from and then fit 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, and another person’s edit reaches an open app on its own. A publicly shared app has no signed-in connection, so it refreshes on focus, on reconnect, and after its own actions.
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.