Custom Apps
Build the app your operation is missing.
Describe it to an agent, watch it take shape in a live preview, and publish it to your team. Its own data, roles, rules, and screens, inside the workspace people already use. No separate stack to host, no restart.
Built by conversation
Describe it. Preview it. Publish it.
Open the Builder and tell a coding agent what your team needs: vendor onboarding, an approval queue, equipment tracking, or a process unique to your company. The agent writes the app, its tables and fields, its own roles, the rules behind the buttons, and the screens, while you watch the result in a preview beside the chat. Switch the preview to a phone or a tablet, or drag it to any width.
Everything lands in a draft with data of its own that only the app's Builders see. When you are ready, the Publish tab compares the draft with the published app and lists every change in plain words: new screens, who gains or loses access, a field whose type changes, anything that opens to people outside the workspace. Publish, and your team gets the new version the next time they open a screen.
Every turn shows exactly which files it changed and how the screens built. Publishing never deletes data: a removed field keeps what it held and gets it back if it returns.
Think Airtable inside your workspace, with the same people, permissions, and audit trail as everything else, and an agent that keeps building alongside you.
Start from a working app
Templates you can use on day one
Each template is a complete app: data, roles, rules, screens, and a dashboard. Add sample data to try it at once, then change anything in the Builder.
Asset Inventory
Categories, locations, check-outs and maintenance for the things your team hands out.
Employee Onboarding
Onboarding plans and a checklist per hire, from the offer to the first weeks.
Event Registration
Events, tickets and agendas, registrations, and a waitlist when an event fills up.
Expense Claims
Claims and their expenses from draft to paid, with approvals and policy flags.
Purchase Requests
Requests, approvals and orders against cost centers and their budgets.
Recruiting
Jobs, candidates and applications by stage, with interviews and scorecards.
Room & Desk Booking
Offices, rooms, desks and phone booths; bookings, check-ins and released no-shows.
Sales Pipeline
Companies, contacts and deals by stage, with calls, meetings and follow-ups.
Training & Certifications
Courses and sessions, enrollments, certifications, and what each department requires.
Vendor Register
Vendors, contracts and notice dates, software subscriptions and quarterly reviews.
And more
New templates arrive with the product. Start from one, start blank and describe your own, or import an app another Volobox workspace exported.
Part of the workspace
Built into the workspace, not bolted on
An app in Volobox does not live beside your team's work. It uses the same people and groups, reads the same projects and tasks, reacts to the same events, and reaches people where they already are.
Links to Volobox items
A record can point at a project, a milestone, a task, a request, a repository, a pull request, a support ticket, a Docs page, or a meeting. People pick it in a search box and open it from the app.
Reacts to what happens
A rule runs when a task closes, a pull request merges, or a ticket comes in. An Admin decides which projects, repositories, or desks the app listens to.
Starts workflows
An event the app announces, such as a submitted request, can start a Volobox workflow, so an agent picks up the work from there.
Inbox cards and alerts
Approvals arrive as Inbox cards with the app’s own buttons, decided right there. Notifications ring the bell, and conditions that stay wrong show up as alerts until fixed.
Agents use your apps
Ask your assistant how many requests wait for you, or to book a desk. It acts with your access, shows an approval card before any change, and external agents reach the same actions over MCP.
Charts in Insights
Share an app’s records with Insights, and dashboards count and chart them next to the rest of your workspace data.
Apps that work together
One app can build on another
A CRM app can let a sales app link each deal to one of its customers, react when a customer is created, or ask it to create a follow-up. The app that has the records decides what it offers in a share: which tables and fields, which records, which events, which actions. Its Admins decide which apps get it.
The app that uses it reads those records as if they were its own, runs its rules when the other app announces an event, and calls the actions the share names. Nothing is shared until both apps are published and an Admin gives the share, and the publish review tells you before a change would take away something another app relies on.
The logic behind the screens
Rules that run on the server
Screens are what people see. Rules are what happens when they act: on a create, an edit, a button, an event, or a schedule. The agent writes them in JavaScript, and they run on Volobox, never in the browser.
Access first, then rules
Who may list, read, create, or change each table is declared, per role, and checked before any rule runs. Rules handle what access cannot express, such as a status change.
Schedules
A daily reminder, a weekly digest, a monthly close: rules on a timetable that start running the moment the app is published.
Other systems
Rules call REST APIs, receive webhooks, and handle a payment provider’s callback. Credentials are bound by an Admin, never written into the app.
Reach people
Send email and Inbox cards to the people in the app, by name, by group, or by role, and keep a log of what each rule did and who it reached.
Who sees what
Governed like everything else in Volobox
The same workspace identity, the same groups, and a review before anything reaches people.
Members, Builders, Admins
Members use the published app. Builders change the draft and publish. Admins decide who is in the app and how it is set up. Add people or whole groups.
The app’s own roles
Requester, approver, finance: the agent writes the roles your process needs, and each decides which screens open and which records a person reads or changes.
Open to the whole company, or to guests
Make an app public so everyone in the workspace can use it. Open one screen to people without an account, such as a sign-up or a consent form; the publish review marks it every time.
A review before every publish
What changed, grouped by who can do what, data, rules, and screens, with the items that need your attention counted at the top.
A version on file
Export the published app before you publish over it, and import that zip later to make it the draft again.
Agents on your terms
Agents acting for a person act with that person’s access and ask first. An Admin can keep agents out of an app with one switch.
For the people who read the code
Files you can read, an app you can take with you
An app is a small set of files the agent writes, and Volobox checks them after every turn. Nothing about it is hidden.
app.json, rules, screens
One file describes the data, roles, access, events, and menu. Rules are JavaScript, one file each. Screens are React components, built into one bundle per version.
The Structure tab
A diagram of the tables and how they connect, every rule and event, each schedule, who may do what, and the recent runs with their logs.
Export and import
Download a version as a zip, keep it on file, or import it into another Volobox workspace: from a test workspace to production, or to a colleague’s company.
Your own coding agent
Build with OpenCode on your organization’s models, or with Cursor or Codex on your own subscription, the same choice as a coding session.
Several languages
Ask for the screens in more than one language. Each person sees the app in their own Volobox language when the app has it.
Phone, tablet, desktop
The preview shows the app at a phone’s or a tablet’s width while you build, so the screens people open on the go are the screens you saw.
Built by the team behind the ABP Framework, on the same workspace foundation as the rest of Volobox.