A website enquiry, end to end

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.

What each audience sees#

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 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#

Related#

• Website enquiries
• A website enquiry is not in my workspace
• Security and isolation
• Three independent layers of tenant isolation
• A row with no workspace stamp is invisible, not missing
• Support in Connect