The Parsware Platform
One product that covers the whole of an internal application: the data model, the screens, the process, the reports, the security, and the way a change gets from a developer’s environment into production without anybody copying anything by hand.
The platform at a glance
Everything an internal application needs, in one product
Twelve parts built to work together, with one data model, one security model, one scripting language and one packaging format underneath all of them — not a set of products to integrate.
Model-Driven Apps
Tables, forms and views, built from one data model.
Studio apps
Screens drawn on a canvas, for the desktop and the phone.
Processes
Approvals drawn in swimlanes and run by an engine.
Reports
Documents designed at the size of the paper, printed exactly.
Graphic Designer
The canvas every report and Studio screen is drawn on.
BS Lang
One scripting language for rules, processes, APIs and functions.
Functions
Scheduled and long-running work, kept out of the way of a save.
Custom APIs
HTTP endpoints you define, for other systems to call.
Portals
Sites for customers and partners, on your own data.
Solutions and environments
Development, test and production, separated by the database; work moves by import.
Security and auditing
Roles, teams and row-level rules, and an audit trail the database writes.
Your own code
React apps and custom controls that run inside the platform.
Model-Driven Apps
Declare a table once, and the app follows
Columns, relationships and choice lists become real database tables. Forms, views and lookups all read that one definition, so a column that changes changes on every screen that uses it.
- Forms with tabs, sections, lookups and related records
- Views with filters, sorting, saved views and spreadsheet import
- Calendars, timelines and charts over the same tables
Studio apps
Draw the screen, then say what each part is
The Application Studio is for the screens a form cannot express. Draw them on a canvas, mark a shape as a list, a form or a button, bind it to your tables, preview it and publish it.
- Lists, forms, file pickers and charts bound to live records
- Navigation, modals and drawers, and screens that update themselves
- A phone app on the same data, or a screen inside a model-driven app
Processes
Draw the approval, then watch it run
A swimlane designer with an engine behind it. Tasks reach the right person in the app they already use, and every run has a live diagram of where it is.
- Lanes for roles, teams and people, with work routed by rules
- Timers, deadlines, parallel sign-off and branches on conditions
- A history of every step: who did what, and when
Reports
Reports that print exactly as designed
Lay a document out at the size of the paper and bind it to a table or a saved query. What the designer shows is what appears on screen, in a PDF and out of the printer.
- Bands, groups, totals and formatted expressions
- Charts, barcodes and QR codes
- Right-to-left layouts for Persian and Arabic
Graphic Designer
One canvas behind every drawing
Reports and Studio screens are drawn on the same vector designer, so what a maker learns once works in both. Every drawing is saved as a plain document with a published schema, so it can be reviewed, generated and imported like code.
- Frames, auto layout and resize constraints
- Shared styles, design tokens and a component library
- Components drawn once and placed on every screen that needs them
BS Lang
One language for every rule
Form logic, server-side validation, process conditions, custom APIs and functions are all written in BS Lang — a small typed language that runs in the browser and on the server with the same results.
- Query records, call an outside service, send an email
- Shared scripts, imported wherever the same logic is needed
- An editor with errors as you type, completion and signature help
Functions
Long work, kept away from a save
A function is a BS Lang script that runs in a service of its own: by hand, on a schedule, or started from another script. A forty-minute batch never slows down the person saving a record.
- Run now, or every so many minutes, hours or days, at a time of day you choose
- A maximum runtime, and a log of every run and what it wrote
- Files written to object storage, and a callback when a run ends
Custom APIs
Endpoints you define, not a database handed to an integration
A custom API is a versioned HTTP contract with a BS Lang script behind it. Another system calls exactly the operations you name, as an app you registered, and nothing else.
- A script that reads its input, queries records and sets the status and the output
- Versions side by side, so a change never breaks a caller still on the old one
- Called with the client id and secret of an app registration
Portals
A site for your customers, on the same tables
Publish a Studio app as a portal and the people outside your company get their own sign-in and their own address — and see only the records a policy says are theirs.
- Visitors who sign up, sign in and use two-step sign-in
- Row-level rules: a visitor sees their own company’s records and nothing else
- Your own domain, pointed at the portal with a CNAME
Solutions and environments
Environments that are actually separate, and one way between them
Each environment gets its own database schema, not a filter column. Work moves from development to test to production as a versioned solution — exported, imported and upgraded in place, never copied by hand.
- A query against the wrong environment fails rather than returning the wrong rows
- Layered components, so uninstalling a solution puts back what was there before
- Seed data and environment variables that travel with the solution
Security and auditing
Who may see a record is decided by the server
Security roles grant create, read, update and delete table by table, reaching every record, a team’s, or only a person’s own. No screen decides what somebody may see; the server answers with only what they may.
- Roles held directly or through a team
- Record ownership, sharing and row-level rules
- An audit log, written by the database, of who changed what and when
Your own code
Your own React, inside the platform
When a designer is not enough, build a React app or a custom control against the runtime SDK, pack it into one archive and upload it. It runs inside the platform’s own shell and travels in the solution like everything else.
- Custom controls that take the place of a field on a form
- Whole React apps, listed beside model-driven and Studio apps
- Hot reload against a development environment while you build
Tell us what you are building
Your tables, your process, your questions. Whoever replies has built the thing you are asking about.