Workspaces and projects
A workspace holds your projects; each project is a self-contained model with its own types, records and team. Nothing leaks between projects.
Who can see what, who is watching it, and how the rest of your stack finds out.
A workspace holds your projects; each project is a self-contained model with its own types, records and team. Nothing leaks between projects.
Owner, admin, data admin and data viewer, assigned per project. Someone can own the model in one project and only read another.
A discussion thread on the record itself, so the argument about the change sits next to the thing being changed.
Watch a record to hear about it, bookmark the ones you keep returning to, and pin the types you work in to your project home page.
One page across every project you belong to, for the times the question is bigger than a single project.
Events delivered to your endpoint from a transactional outbox, signed so you can verify them. Your ERP hears about the change without polling for it.
In the APIA server-to-server HTTP API over everything: schema discovery, records, query, search, structures, rollups and change requests, with ETag concurrency and idempotent upsert.
In the APIApprovers get their outstanding change requests by email, so nothing waits three days because nobody opened the app.
Take the configuration, the records, or the entire project as a bundle you can clone into a new one. Your data is not held hostage by the platform.
In the APISpin up a workspace and start building. It only takes a few minutes.