Skip to main content
An app is a user-facing UI surface within a project. Every app declares an audience at creation. Audience is not a configuration detail — it drives routing, permissions, authentication, and PHI policy for that surface. Apps are distinct from projects (the container) and from workflows (the automation primitive). A project can have many apps. An app can participate in many workflows by emitting events that workflows listen to.

​
Creating an app

Describe the surface you want in chat:
“Add a patient intake form that patients can access without logging in.”
The system infers:
  • Audience: Public (because “without logging in”)
  • Path: /intake (or proposes one if there’s a collision)
  • Entities: Prompts for or creates a patient entity
If the audience is non-obvious, the system states its inference: “I’ll make this a public app — accessible without login. Does that sound right?”

​
Audience taxonomy

Audience is probed conversationally at app creation. The system never assumes audience for a non-trivial app without stating the inference and asking for confirmation.

​
App URLs

Apps are served at the org’s runtime subdomain:
For Enterprise orgs with custom domains, apps resolve under the custom domain instead. Path uniqueness is org-scoped, not project-scoped. If a requested path is already in use by another project in the same org, the system resolves the collision conversationally at creation time.

​
What apps do

By default, an app has implicit CRUD access to the entities it’s associated with. You don’t need a workflow for an app that simply reads and writes entity records. Workflows are what apps add when behavior beyond CRUD is needed:
  • Trigger on form submission — User submits an intake form → workflow fires
  • Trigger on button click — User clicks “Approve” → workflow fires
  • Trigger on page load — App opens → workflow fetches and enriches data
  • Emit data-change events — User modifies a record → other workflows react

​
The live app center pane

When you’re working on a UI-backed app or its associated workflow, the center pane renders the live app. During authoring, the app runs against sandbox data. Once released, it runs against production. This is not a preview mock — it is the actual deployed app running against real (sandbox) data. You interact with it the same way your users will.
The live app center pane renders real sandbox data. If your sandbox environment contains synthesized PHI for testing, PHI handling policy applies to those interactions. Do not paste real patient data into sandbox unless your organization’s sandbox PHI policy permits it.

​
Audience changes

You can change an app’s audience through chat at any time before release. Changing audience is a draft change — it becomes part of the project’s pending changeset and is included in the next release. Audience changes may have routing and permission consequences; the system surfaces these when they’re significant.

​
Custom composition

The system generates the initial app contract from your conversational description. You can refine it:
  • Add fields — “Add a phone number field, optional.”
  • Change layout — “Put the risk banner at the top of the form.”
  • Add conditional sections — “Show the emergency contact section only if the patient is under 18.”
  • Add role-gated actions — “Show the approve button only to staff with the clinician role.”
All changes go through chat. The app contract is compiled by the system; there is no visual editor for app layout or fields.