# Website enquiries

An enquiry submitted on JBRH's own website is a message to JBRH, not to any customer's workspace. It is held in a control-plane table that sits outside every workspace, and the operator works it. A customer looking for one of these in their own Connect and not finding it is watching tenant isolation behave correctly, not hitting a fault.

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

## What these enquiries are

Somebody who has never used Connect fills in a form on the public site asking about the product. That message is addressed to JBRH Digital Solutions, the operator. It is not addressed to any workspace, it does not belong to any workspace, and there is no workspace it could sensibly be filed in — the person writing it has not chosen one.

So the intake path stores it where it belongs: `connect_inquiries` is a control-plane table, deliberately outside every workspace, and `connect_intake` is the module that owns it. That is a positive design decision rather than an omission, and it is the reason the enquiry can be answered at all without first inventing a tenant to attach it to.

## Why not simply put it in a workspace

Because every scoped record in Connect belongs to exactly one workspace, and that rule is enforced independently three times: 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 underneath both. A record with no workspace is invisible to workspace-scoped reads by construction.

| Record | Where it lives | Who can read it |
|---|---|---|
| A website enquiry | The control plane, outside every workspace | The operator |
| A lead in your workspace | Your workspace, stamped and scoped | You |
| A support case | The workspace that owns the person | That workspace only |
| A prospect from discovery | The workspace that ran the research | That workspace only |

> **Note** Putting an unassigned enquiry into some workspace to make it visible would mean choosing whose customer a stranger is. Every version of that choice is wrong, and the wrong ones leak one business's enquiry to another.

## What the operator does with one

The operator reads the enquiry, answers it, and — if it turns into a relationship — creates the person and the company in JBRH's own workspace, where every normal capability applies: identities, timeline, follow-ups with reasons, a deal if it becomes one. The enquiry is the front door; the relationship record is the building.

Verifying customer payments and JBRH's own pricing sit in the same category: correctly operator-only, because they are the work of running the platform rather than the work of using Connect. A capability marked for the operator is not a feature a customer is waiting for.

## What a customer sees instead

- Enquiries that arrive at **your** business — through your mailboxes, your phone line, your WhatsApp number, your own forms — land in your workspace as conversations and people, exactly as they always have.
- Nothing from JBRH's public site appears in your workspace, and nothing in your workspace is visible from the control plane's enquiry list.
- If you expected to find one and cannot, [A website enquiry is not in my workspace](/docs/troubleshooting/enquiry-not-visible/) walks through what you are actually seeing.
- A row with no workspace stamp is invisible rather than missing — a distinction worth understanding before reporting data as lost.

## The general principle

Two planes, and knowing which one a record is on answers most 'where did it go' questions immediately. The control plane holds what belongs to the operator of the platform: enquiries about the product, payment verification, JBRH's own commercial terms. A workspace holds what belongs to one business: its people, its conversations, its deals, its cases. Nothing crosses, and the crossing is not a permission somebody can be granted.

## Questions

### Why can I not see website enquiries in my workspace?

Because they were never yours. An enquiry on the JBRH site is addressed to the operator and stored outside every workspace. Your own website forms, mailboxes and numbers deliver into your workspace as normal.

### Could an enquiry be moved into a workspace later?

The relationship can be created in a workspace once it is clear whose it is — that is what the operator does when an enquiry becomes a real conversation. The enquiry row itself stays on the control plane, where it was addressed.

### Does this mean the operator can read my workspace?

No. Isolation runs the other way too: a workspace's records are scoped by the middleware allowlist, the workspace kernel and row-level security. Living on the control plane grants no read into a tenant's data.

## Related

- [Support in Connect](https://connectbyjbrh.com/docs/support/)
- [A website enquiry is not in my workspace](https://connectbyjbrh.com/docs/troubleshooting/enquiry-not-visible/)
- [A website enquiry, end to end](https://connectbyjbrh.com/docs/workflows/website-enquiry/)
- [Security and isolation](https://connectbyjbrh.com/docs/security/)
- [Three independent layers of tenant isolation](https://connectbyjbrh.com/research/three-layers-of-isolation/)
- [Data that is invisible rather than missing](https://connectbyjbrh.com/research/workspace-stamp/)

## 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/CHANNELS.md` §6 — capabilities that are correctly operator-only
- `docs-source/sources/GENERAL.md` §10 — the three isolation layers
- Connect capability registry (docs-source/facts.py) — `website_enquiries`, `rls_isolation`