A company's work is done in several systems: a CRM, a helpdesk or a tracker, a tracking platform, an accounting package, spreadsheets, a messenger. The people who work in them have access. But data from these systems is regularly needed by others too: customers, staff in the field, managers, partners, the owner. A customer wants to know where the order is. A driver fills in a vehicle check. A manager approves an expense from the phone. A partner registers a deal. The owner wants to see this month's numbers without asking anyone. And the people who do work in those systems often need, for a given task, not the whole interface but one form or one page: submit a request, approve it, look at the summary.
A screen for them used to be a development project of its own: write it, host it, connect it to the systems, maintain it. In most companies it never reaches the top of the list, and staff do the work instead: they answer the calls, forward the extracts, gather the numbers by hand.
Apps in FlowTrux are that screen. An app is a form, a page or a small application that a workflow puts in front of people on your own address, whether or not they have an account in your systems. You describe it; it is built, connected, published and versioned in one place; the data stays where it already is.
Seven screens every company ends up needing
Below are the seven situations in which a company most often needs a separate, simple screen on top of its systems: for customers, partners, and staff outside the office and inside it. For each: what it usually looks like, and how it is built in FlowTrux.
A request that someone has to approve
Leave, an expense with a receipt, a purchase, access to a system, a new laptop, a design proof, a partner's deal registration. The requester fills in a form, the approver gets a message with two links, the requester hears back, and the record lands where such records live.
In FlowTrux this is one form app and one workflow. The form collects the fields and the attachment. The workflow writes the row (a CRM or ERP, a spreadsheet, a task tracker, a database, any system with an API), sends the approver a message in a messenger or by e-mail, and waits until one of the two links is clicked, with no time limit. Then it records the decision and tells the requester by e-mail, SMS or messenger. Every submission stays in the app's Submissions tab.
A live view for people without an account
Monthly numbers for the owner, a client's project status, a KPI page for the management, a sales dashboard on the office TV. Read-only, always current, no login, no PDF that is stale by the time it is opened.
A result page shows the latest run of a scheduled workflow and refreshes itself. The workflow pulls the figures from the systems that hold them (a CRM or ERP, spreadsheets, a task tracker, your telematics or IoT platform, a database, any API), an agent step adds a short note on what changed, and the page is served on your address, open by link or behind a password. The same run can post the picture to a messenger and render a PDF for the mailbox.
A status lookup by reference number
“Where is my ticket?”, “Where is my shipment?”, “What happened to my return?” The visitor enters a number and sees the answer for their own record.
A small app with one field. The lookup runs in a workflow, which decides what comes back, so the visitor sees their own record and nothing of anyone else's. Tickets in the helpdesk or tracker, shipments in a sheet or a database, orders in the shop's system: the workflow reads them live.
A check filled in on a phone
The daily vehicle inspection, proof of delivery with a photo, a site audit, an equipment checklist. The person in the field opens a link or a QR code, no app to install, and the supervisor sees a log.
A form app with a photo field (on a phone it offers the camera), a few fields, a button. The workflow appends the row to a sheet, posts the photo and the defect to the team's messenger, and the driver sees a confirmation with the number. The files stay with the submission.
The morning board
Today's trips for the stand-up, the sales leaderboard, the help-desk load. Large type, no buttons, on the office TV and in the team chat at the start of the day.
The same result page as above, and the same workflow posting the summary to the chat on its schedule. The page is never older than the schedule.
A portal where an outside party sees only its own records
Each client sees their fleet, their project, their invoices. Each vendor their documents and their payment status. Each partner their deals.
Two shapes, both built the same way. When the outside party already has an account in the system the data comes from, the app signs them in with it and asks the service on their behalf: a telematics customer opens “my vehicles” and sees exactly the units their own login in the tracking platform can see. Otherwise the app is published behind a password, one per client, each reading only that client's slice through its workflow. For companies that serve other companies this pairs with FlowTrux workspaces: one per client, with its own connections and recipients, and with access rights for the client's staff when they need to enter the workspace itself.
An intake form that creates a record in an existing system
A lead into the CRM and the sales chat, an IT request into the tracker, a creative brief onto the content board, a job application into the recruiting sheet with a short summary of the CV next to it.
A form app bound to a workflow that creates the issue in the task tracker, the deal in the CRM, the row in the spreadsheet, the record in any system with an API. Where reading is part of the job, a forwarded purchase order in a mailbox, a résumé against the vacancy text, an agent step does the reading inside the workflow and the structured result goes into the record.
The same seven screens in every department
The way of building does not depend on the industry. What changes is the system behind the screen and the people in front of it.
- Telematics / IoT. A vehicle check from the driver's phone; a client's report page and a “my vehicles” view for each customer fleet; event subscriptions by SMS.
- Logistics and delivery. “Where is my shipment” by number; a quote request; proof of delivery with a photo; the morning board of today's trips.
- Customer support. Ticket status without an account; a return or warranty form; the help-desk load on the wall.
- Sales and marketing. A lead form that lands in the CRM and the sales chat already sorted; partner deal registration with approval; the leaderboard on the TV.
- E-commerce. A wholesale buyer application with approval; emailed purchase orders turned into orders; a stock view for staff.
- Finance and accounting. An expense request with the receipt and an approver; purchase approval; a vendor's documents and payment status.
- HR and recruiting. A job application with a summary of the CV next to it; onboarding of a new hire; a leave request with approval.
- IT and DevOps. Service, access and hardware requests that arrive as tickets; a change request; a status page for the services people depend on.
- Content and media. A creative brief into the board; a proof or design approval by the client; a content calendar with sign-off.
- Analytics and reporting. A live dashboard for people without seats; a page per client with only their numbers; the morning summary in the chat.
Ten departments, one way of building. A company does not adopt a portal product for support, a form product for HR and a dashboard product for management; it describes each screen in the same place and connects it to the same systems.
Why this is solved here, and not in a chat with an AI or in another service
Any current AI model will write the HTML of an expense form in a few seconds, and there is no shortage of form and portal builders. The difficulty is not the screen but what surrounds it: where it runs, where it takes its data from, what happens after it is submitted, and who keeps it working. That is what FlowTrux is.
The screen has somewhere to live. A published app is served on your-organization.flowtrux.ai/app-name, with a readable name, open by link or behind a password. Each publish is a version; you can compare and roll back in one click. The draft you keep editing and the version visitors see are separate. You need no server, hosting or certificates of your own.
The screen is connected to your systems.Your organization's connections (CRM and ERP systems, e-mail, spreadsheets and calendar, messengers, SMS, task trackers, telematics and IoT platforms, databases, any HTTP API) are configured once, in Settings, encrypted, and assigned to workspaces. A workflow uses them, and the assistant relies on them while building: it can ask the connected systems what exists and check each step against the real data before it adds it.
The screen can wait, and it can run on a schedule.The workflow waits for the approver's decision as long as it takes, refreshes the page at the set time, runs the lookup when the visitor presses the button, and retries a request when a service is temporarily unavailable. Every app is backed by a workflow, and the workflow is what handles time and waiting.
The record stays where it is. Nothing is copied into a new database that then has to be kept in sync. The app is a window into the systems you already use; the workflow reads from them and writes back to them. When the CRM changes, the app changes with it.
You can see what happened.Every run of every workflow behind an app is in the execution history, step by step, with inputs and outputs. When a visitor says “it didn't work”, you open the run and see at which step and why.
It is built the way the rest of your automation is built. The same assistant, the same workspace, the same workflow editor. Describe the screen: who opens it, what they see or fill in, where the data lives. The assistant writes the app and, when the data belongs to your organization, creates the workflow next to it with an App trigger and the right integration steps. The workflow appears switched off; you look at it and turn it on. Then you refine the app the way you would brief a colleague: change a column, add a filter, hide what is not needed. Before it goes live, the app is checked for secrets left in the code and for calls to services it did not declare.
For your own company, and as a service to your clients
Apps are used in two ways, and one company often uses both.
For your own work.The company closes its own joints: requests and approvals for staff, status for its customers, summaries for management. This may be a company moving from “everything is in someone's head and a chat” to processes that run whether or not that someone is in the office. Or a mature company whose systems have long been in place and which wants to improve its internal processes and its work with customers, partners and contractors.
As a service to your clients.A telematics provider, an integrator, an agency, an outsourced accounting firm or an IT contractor does the same for the companies it serves. Each client gets its own workspace with its own connections and recipients; the workflows and apps worked out on one client are rolled out to the next. The client gets a status page, a request form or a portal under the provider's brand and address without buying or implementing anything itself. For the provider it is a new service on top of what it already sells.
In both cases the work happens at the joints between systems and between people. The workflow automates the joint; the app makes it available to everyone who needs it, inside the system and outside.
FlowTrux is a universal tool, and that is the point. The same way of describing a screen and connecting it to the systems works for any of the seven cases above and for those that did not make the list, for your own company and for the companies you serve. Industry and size do not matter: only the systems behind the screen and the people in front of it change, and the way of building stays the same.
Open Apps in a workspace, press Create, and describe the first screen your team or your customers are missing.