The view our operators get of your Relay workspace shows its shape, not your posts

Every service run on somebody’s behalf eventually needs a member of staff to look inside one customer’s account. A connection keeps failing; a key needs revoking; a customer asks why something stopped. The question worth asking of any provider is not whether staff can look — they have to — but what they see when they do.

For a social publishing service the answer matters more than most. A workspace holds the tokens that let us post as a brand, and the drafts of what that brand is about to say in public. Neither is something a support engineer needs in order to fix a failing connection.

Shapes, not contents

The Relay workspace view in the operator console shows a workspace as its shape:

• Who is in it, from the organisation’s membership.
• What is connected, and which connections need re-authorising or were revoked.
• Which API keys exist.
• How recent posts went — for each network, whether it was delivered, failed or rejected, the error code, and how many attempts it took.
• The workspace’s own audit trail.

And it does not show three things: no credential — no access token, no key value, nothing that would let somebody act as the customer — no post body, and no media. What "my posts stopped" needs is statuses and error codes, and that is what is there.

The question to ask a provider is not whether staff can look inside your account. It is what they see when they do.

Two levers, and neither needs the contents

The view carries two actions, both chosen because they fix the common problems without needing anything the view withholds:

• Disable a connection — stop one misbehaving account from publishing, without touching the rest of the workspace.
• Revoke a key — cut off an API key that has leaked or belongs to somebody who left, immediately.

Each one asks for a reason, and lands on the customer’s own audit trail with it. An owner who reads that the portal disabled their LinkedIn page deserves to learn why in the same sentence, rather than by opening a ticket. The broader incident switches go further and record the named member of staff — that post is here.

By construction, not by promise

"Our staff never read your posts" is a sentence any provider can write. What makes it true here is where the view gets its data: it reads the workspace through the Relay’s own admin interface, and what that returns about a post is a status, where it came from, its times, and a delivery result per network. There is no field in it for the words of a post, so there is nothing for the view to show — whatever permission a support engineer holds.

It is the same instinct behind the one product we deliberately do not host: where the data is sensitive enough, the strongest guarantee is a system that cannot show it, rather than a rule that says nobody will look.