# A website enquiry, end to end

Someone with no account submits a form on the JBRH site. There is no session and no workspace to resolve, so the submission is stored on the control plane rather than inside a tenant. The operator answers it from JBRH's own workspace, and only if it becomes a real relationship does a Person get created — in that workspace, not in anybody else's.

- **Status:** Available (operator)
- **Audience:** owner, customer
- **In the app:** #/relationships, #/conversations
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/website-enquiry/

## The stage chain

1. Trigger — a visitor to the public site fills in the enquiry form. They have no account, no session and no workspace.
2. External event — the submission reaches the intake endpoint, which is a public route by necessity: the person submitting it cannot authenticate.
3. Authentication and workspace resolution — the decisive stage, and the one that resolves to nothing. There is no workspace to attribute this to, and inventing one would mean deciding whose customer a stranger is.
4. Ingest — the submission is validated and written to `connect_inquiries`, a control-plane table that deliberately sits outside every workspace. `connect_intake` owns that path.
5. Canonical record — none yet. The enquiry is not a Person, not a Lead and not a Prospect in any workspace; it is a message addressed to the operator of the platform.
6. Classification and reasoning — the operator reads it and decides what it is: a product question, a sales conversation, or noise.
7. Knowledge, memory and rules — anything answered is grounded in JBRH's own Knowledge, under the same rule every workspace has: a price or a term that Knowledge does not support is refused rather than invented.
8. Autonomy and approval — the operator's own autonomy rules apply to the reply, exactly as a customer's rules apply to theirs. There is no special path because the sender came from a form.
9. Action and provider — the answer goes out from a JBRH mailbox through the same send boundary as any other message.
10. Result — the provider's acknowledgement decides whether it counts as sent; until then the state is uncertain rather than delivered.
11. Relationship, timeline and memory — if the enquiry becomes a conversation worth keeping, a Person and Company are created in JBRH's workspace and everything ordinary applies from there: identities, timeline, follow-ups with reasons, a deal if it becomes one. The enquiry row stays where it was written.
12. Audit and usage — the decision and the send are attributed and metered in the workspace that made them.

## The stage that decides the rest

Stage three is the whole design. Every scoped record in Connect belongs to exactly one workspace, and three independent layers enforce it: the allowlist in the middleware that decides which routes a customer session may reach, the workspace kernel that scopes every query, and PostgreSQL row-level security under both. A submission from a stranger has no workspace to be stamped with, so the only correct home for it is outside the scoped world entirely.

> **Careful** The tempting shortcut — attach it to some default workspace so it is easy to find — is how one business's enquiry ends up readable by another. There is no version of that choice that is both convenient and safe, so the record simply lives elsewhere.

## What each audience sees

| Stage | The operator sees | A customer sees |
|---|---|---|
| Submission | A new enquiry on the control plane | Nothing — it was never addressed to them |
| Answer | An ordinary reply from a JBRH mailbox | Nothing |
| Becomes a relationship | A Person and Company in JBRH's workspace | Nothing |
| Their own website forms | Nothing | Conversations and people in their own workspace, as normal |

That last row is the one customers actually care about. Enquiries arriving at *your* business — through your mailboxes, your phone line, your WhatsApp number, your own forms — reach your workspace and behave like every other inbound message. Nothing about this flow removes anything from you; it describes records that were never yours to begin with.

## What can fail

**The form is submitted twice** — Two enquiries exist. They are deduplicated by a person reading them, not by a rule that might merge two different people with the same question.
**A customer goes looking for one** — They find nothing, and the absence is correct. [A website enquiry is not in my workspace](/docs/troubleshooting/enquiry-not-visible/) explains the shape of what they are seeing.
**An enquiry is never read** — Nothing chases it on its own: it is not a follow-up and it has no due time until somebody makes one.
**The reply cannot be grounded** — It is refused and escalated like any other ungrounded commercial question, because the operator's workspace runs by the same rules it ships.

## Questions

### Why is a public form allowed to write anything at all?

Because the sender cannot authenticate — that is what a public enquiry is. The protection is not authentication but placement: the write lands on a control-plane table outside every workspace, so it cannot reach tenant data.

### Does the enquiry become a lead in a workspace?

Only in JBRH's own workspace, and only when the operator creates the relationship. The enquiry row itself stays on the control plane, where it was addressed.

### Do enquiries from my own website work this way?

No. Your forms, mailboxes and numbers deliver into your workspace, where the message resolves to a person and behaves like any other inbound conversation. This flow is specific to the public JBRH site.

## Related

- [Website enquiries](https://connectbyjbrh.com/docs/support/website-enquiries/)
- [A website enquiry is not in my workspace](https://connectbyjbrh.com/docs/troubleshooting/enquiry-not-visible/)
- [Security and isolation](https://connectbyjbrh.com/docs/security/)
- [Three independent layers of tenant isolation](https://connectbyjbrh.com/research/three-layers-of-isolation/)
- [A row with no workspace stamp is invisible, not missing](https://connectbyjbrh.com/research/invisible-not-missing/)
- [Support in Connect](https://connectbyjbrh.com/docs/support/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §7 — `connect_intake.py` and `connect_inquiries` as a control-plane table
- `docs-source/sources/GENERAL.md` §10 — the three isolation layers and the send boundary
- `docs-source/sources/CHANNELS.md` §6 — refusing ungrounded commercial terms
- Connect capability registry (docs-source/facts.py) — `website_enquiries`, `rls_isolation`