Connect by JBRH Open Connect

A website enquiry is not in my workspace

You are seeing tenant isolation behave correctly. An enquiry submitted on JBRH's public site is addressed to the operator and stored on the control plane, outside every workspace, so no workspace-scoped query can return it — including yours. The record is not lost, not deleted and not delayed. It is in a place your session is not entitled to read.

Status
Available What this means
Audience
both
In the app
#/conversations, #/relationships
Last verified
Product version
6.3.2

The symptom#

Somebody tells you an enquiry was submitted, or you submitted a test one yourself, and nothing appears: no conversation, no lead, no person, nothing in search. Refreshing does not help and neither does waiting, which is usually the point at which it starts to look like a fault.

It is not one. There is a difference between a record that is missing and a record that is invisible, and this is firmly the second: the row exists, it is durable, and it carries no workspace stamp because the person who created it had no workspace.

What it means#

Every scoped record in Connect belongs to exactly one workspace, and three independent layers enforce that: the allowlist in the middleware deciding which routes a customer session may reach, the workspace kernel scoping every query, and PostgreSQL row-level security beneath both. A visitor filling in a form on the public site has no session and no workspace, so there is no stamp to apply — and a row with no stamp cannot be returned to a scoped read.

Storing it outside every workspace is therefore not a limitation being worked around. It is the only placement that does not require choosing whose customer a stranger is, and every version of that choice leaks one business's enquiry to another.

The likely causes, in order#

  1. It was submitted on the JBRH site. Those enquiries are addressed to the operator and never enter a workspace. This is nearly always the answer.
  2. You are expecting operator records in a tenant session. Payment verification and the operator's own pricing sit in the same category: correctly operator-only, not features you are waiting for.
  3. It did arrive, somewhere else in your workspace. An enquiry through *your* form, mailbox or number becomes a conversation and a person. Search the address rather than the enquiry.
  4. Your own intake is not delivering. A mailbox that is connected but unhealthy is quiet rather than broken, and quiet looks identical to nothing having been sent.

What Connect did complete#

  • The submission was validated and written durably to the control-plane table that owns enquiries.
  • The operator can read and answer it from JBRH's own workspace under the same rules any workspace runs by.
  • The workspace's own intake paths are untouched: its mailboxes, numbers and forms continue to deliver as normal.
  • Isolation held in both directions — being on the control plane grants no read into a tenant's data either.

What Connect did not complete#

  • It did not stamp the row with a workspace, because there was none to stamp it with.
  • It did not create a Person, a Lead or a conversation in your workspace, and it will not backfill one later.
  • It did not notify you. The enquiry was not addressed to you, so there is nothing for it to notify you about.
  • It did not fail. Nothing here is an error state, which is why no error is reported anywhere.

What you can do#

  1. Search your workspace for the person's address rather than for the enquiry.

    Result If they also wrote to your mailbox or rang your number, you will find the conversation that did reach you.

  2. If the enquiry genuinely concerns your business, ask the operator.

    Result They can answer it, or create the relationship in the right place. That is a human handover, and it is the correct one.

  3. Point the business's own intake at the workspace: site forms to a connected mailbox, the published number to the line.

    Result Future enquiries about that business arrive as conversations with people attached, under the autonomy rules already set.

Administrators, and when to escalate#

An administrator's useful move is to check the workspace's own intake rather than to hunt for the enquiry: mailbox health, the phone line's state, and whether the forms on your site actually deliver to a connected address. A workspace that believes it is receiving enquiries and is not will produce this same complaint repeatedly, for a completely different reason.

Escalate when a record that was created in the workspace is not visible to the session that created it, when a message reached a connected mailbox and never became a conversation, or when something from another workspace does appear here. The first two are real faults; the third would be serious, and none of them is what this page describes.

Questions#

Was the enquiry deleted?

No. It is stored durably on the control plane, outside every workspace. Invisible to a scoped query is not the same as absent from the database, and the operator can read it.

Can support move it into my workspace?

The relationship can be created in the right workspace once it is clear whose it is, which is a human decision. The enquiry row stays where it was addressed, because rewriting who a message was sent to is not a fix.

Does this mean my own website enquiries also disappear?

No. Forms, mailboxes and numbers you connect deliver into the workspace, resolve to a person and behave like any other inbound conversation. Only the public JBRH site's form behaves this way.