Platform
The part of your process nobody sells software for.
Every business has three or four processes that are genuinely theirs — the ones that live in a spreadsheet because no vendor ships them. Custom apps let you build those inside the platform, over your own objects, under the same permissions and the same audit trail as everything else.
The financial problem
The spreadsheet is where the control environment ends.
- The process that governs real money runs in a file with no owner, no history and no access control.
- Numbers are keyed twice — once in the sheet, once in the system — and the two disagree by month-end.
- Nobody can answer who changed the figure, or when, because the file has no audit trail.
- It is load-bearing enough that losing the person who maintains it is an operational risk.
The technical problem
A custom build outside the platform inherits none of it.
- A side application needs its own auth, its own roles and its own data-scope rules — all of which drift from yours.
- It needs its own integrations, so the same partner feed is mapped twice, differently.
- It is not in the audit trail, so an auditor sees a gap exactly where the judgement was applied.
- And it becomes a second upgrade path, maintained by whoever built it.
What you can build
An object, a page, a place in the menu
A custom app is not a form bolted to the side. It is a first-class part of the application, in the navigation, with data behind it.
Your own objects
Define the record and its fields — the things your process actually tracks, not an approximation of them in someone else's schema.
Master–detail
A parent record with its lines, linked on the field you choose, so headers and detail behave the way the rest of the platform does.
Pages in the navigation
Each app gets a route, an icon and a menu group, so it sits alongside the shipped modules instead of being a bookmark somebody shares around.
Choose what shows
Pick which fields appear on the page. The object can carry more than the screen exposes, which is how you keep a form usable.
Actions on submit
Save the record, and optionally push it straight out through an existing interface — so a custom process can still feed the ERP.
Records, not documents
Everything created is a real record with real CRUD: queryable, reportable, and visible to the same searches as anything else.
How it gets built
Describe it, review it, publish it
Two routes to the same result — configure it yourself, or tell an agent what you need. Both end at a draft a person approves.
-
01
Describe
Build it by hand in the page builder, or tell the Custom App Builder agent what the process is. It asks for the title, the data behind it, the layout and where it belongs in the menu.
-
02
Review as a draft
The agent proposes a specification — it does not create anything. What comes back is a draft an administrator reads, edits and decides on.
-
03
Publish
On approval the page becomes real: routed, in the menu, with its object behind it. Nothing reaches users because a model suggested it.
It inherits the controls. That is the whole point.
A custom app is not a lighter-governed corner of the platform. The same role permissions decide who opens it, the same data-scope rules decide which rows they see, the same audit trail records what changed, and the same integration layer moves data in and out.
Which is the argument for building it here rather than beside it: the spreadsheet is quicker to start and the side application is quicker to demo, but neither one can tell an auditor who changed the number.
How access and audit work →Bring the spreadsheet.
Show us the process that runs your business from a file nobody owns, and we will show you what it looks like as a governed app.