Project structure
Apps
Apps are user-facing surfaces. Each app declares an audience at creation — this drives routing, permissions, and PHI handling. Default CRUD against entities is implicit in an app; workflows are what apps add when behavior beyond CRUD is needed. See Apps authoring.Workflows
Workflows are automation contracts executed by the HASP runtime. Each workflow has one or more triggers and a step graph. Workflows reference entities (read/write), integrations (outbound calls), and emit data-change events that other workflows can listen to. See Workflow authoring.Entities
Entities are shared data schemas. Multiple workflows and apps in the same project can reference the same entity. Schema changes (adding, renaming, or removing fields) are surfaced as explicit confirmation gates in chat because they have migration consequences. See Entities.Integrations
Integrations are outbound connections to external systems — Stripe, HubSpot, EHR APIs, Postmark, Twilio, Google Workspace, and others. Credentials and configuration live at the project level so multiple workflows can share one connection without duplicating config.Webhooks
Webhooks are inbound HTTP endpoints. The project provisions a URL under your org’s runtime subdomain (or custom domain on Enterprise); workflows listen to specific webhook endpoints as triggers. Webhooks are sibling to integrations, not nested inside them.Settings
Settings are named configuration values referenced by name from workflow contracts — e.g.,compliance_officer_email, urgent_routing_recipients, practice_timezone. Changing a setting propagates to every workflow that references it without re-authoring.
Chat scope
By default, chat operates at the project scope. The system resolves resource references across the project, so a single conversational turn like “flag urgent intakes so clinicians see them at the top of the triage board” can compile changes to a workflow step, an entity field, and an app sort rule — all at once. You can scope chat down to a specific resource: “let’s work on just the intake form”. Scoped chat narrows reference resolution to that resource and its immediate dependencies. Return to project scope with: “go back to the project.” When the system infers something non-trivial — the audience for a new app, the shape of a trigger, whether a project is headless — it states the inference and asks for confirmation. The system never silently picks.Runtime URLs
Apps live at your org’s runtime subdomain (or custom domain on Enterprise):/intake. If a collision would occur, the system resolves it conversationally at app-creation time.
The project name does not appear in runtime URLs. Studio admin URLs (app.usehasp.com/projects/<project-slug>/...) carry project namespace because that is a builder concern, not an end-user concern.
Project navigation at scale
Projects with 50+ resources are the design target, not an edge case.Search (⌘K)
Project-wide search returns typed results across all six sections. Results show type, name, and key metadata — audience for apps, trigger type for workflows, and so on. Click to open that resource’s contract view.Activity log
Every contract change emits a project-activity event. The project overview shows recent activity by default with author attribution. A deeper history view is accessible for forensic review.Health rollup
The project overview shows: how many workflows are running normally, how many have recent failures, how many apps are live, whether webhooks are receiving traffic, and recent error counts. Failing workflows surface immediately with a click-through to the failing run’s trace.Reverse-dependency views
Every resource has a “what depends on me” view:| Resource | Shows |
|---|---|
| Entity | Which workflows write to it, which read from it, which apps render it, which data-change events it emits and who listens |
| Integration | Which workflows use this connection, which steps make outbound calls |
| Webhook | Which workflow handles incoming requests |
| Setting | Which workflows reference this value |
| App | Which workflows are triggered by events from this app, which entities it reads/writes |