The gap
AI fixed the demo. It didn’t fix the system.
Let’s concede the part that’s true: a business user can now describe a tool and get something that works. That’s real, and it happened fast. The problem is what a working demo still isn’t.
- A form that captures the request
- A workflow that routes it for approval
- A dashboard that counts what’s open
- A page that looks like software
- Identity, groups, and inherited membership
- Column-level permission and deny-over-allow precedence
- An audit trail an auditor will actually accept
- Data residency, retention, and deletion
- Separate test, UAT and production — and a way to promote between them
- Delegation, out-of-office, and acting on behalf of
- Backup, restore, and proving you can
Every one of those is unglamorous, and every one of them is where “we’ll handle that in Phase 2” became a running joke. Flowsey’s position is simple: those belong to the platform, not to your project plan.
The model
A baseplate, and bricks that snap onto it.
Governance isn’t a feature you remember to switch on per app. In Flowsey it’s a property of the substrate everything is built on — so an app assembled by a business analyst on a Tuesday inherits the same enforcement as one built by engineering.
What the platform guarantees
Users, groups and recursive membership. Permission policies down to the column, with deny beating allow. Audit captured at the database write. Five environment stages with promotion between them. Delegated authority with a fingerprint on every action. Storage access controlled by path.
What you design
Typed datatables. Forms with validation, formulas and sub-tables. Workflows with lanes, approvals, checkpoints and sub-flows. Reports and pivots. Portal pages for people outside your organization. Then package the whole thing and ship it to the next environment.
The catalog
What’s actually in the box.
Not a roadmap. These are shipped, documented capabilities you can assemble today.
in 7 families
for portals
audit trails
stages
articles
Forms, approvals and checkpoints that wait for a quorum. Sub-workflows that block until they finish. Email, API calls, scheduled sweeps, custom code and Python steps. Assignment by lane, by group, or delegated.
Typed tables with validation and formulas. Cross-table queries with joins and aggregation. Column statistics and distribution profiling. Every record change attributable to a person, a run, or a job.
Portal pages with tables, calendars, kanban boards, dashboards and forms. Export any app as a package and import it into the next environment — or into another tenant entirely.
The starting point
You already know how to do this.
Laying out columns, setting a validation rule, writing a formula, sharing the file with your team — that’s the whole skill. Flowsey takes those same decisions and gives them a spine. Here’s what changes.
The argument
Why this is hard to bolt on later.
Every capability here is one a competitor could ship. What’s hard is that each one had to be decided before the first feature was written — which is exactly what makes it expensive to retrofit.
Enforcement sits under the components, not inside them
A new page or endpoint inherits the permission model by default. Nothing has to remember to check.
Audit is captured at the database write
Not instrumented feature by feature — which is why coverage doesn’t drift as the product grows.
Apps are portable because identity was modelled up front
Exporting an app to another environment or tenant works because references were never hard-wired to one database’s row IDs.
The AI reads through the permission model
The assistant answers from what the asking user is allowed to see. It isn’t a side channel around your access rules.
One stack, so there’s no integration tax to protect
Suites that grew by acquisition have revenue riding on the seams between their own products. We don’t have seams to defend.
Straight answers
What starts a run — and what doesn’t.
You’ll ask this in the evaluation, so here it is now. Six things can start a workflow:
- A person, from a form
- The scheduler, on a recurrence
- A due-date sweep
- A sub-workflow step
- An authenticated API call
- A project being initiated
There is no inbound-email trigger, and no generic “when any record changes” event bus. If your process depends on either, tell us in the first call and we’ll tell you honestly whether Flowsey fits — rather than letting you discover it in week three.