Skip to main content

​
Public feedback and trust surfaces: idea board, community, help center, sub-processor notices

Some of what your end users reach for is deliberately unauthenticated: a signed-out visitor can self-serve help content, ask the community a question, submit a product idea, or subscribe to sub-processor change notices without an account. Four Orbit surfaces share that posture, and they share one design contract that bounds it. This page maps the four surfaces and the invariants that keep them safe — separate from the incident model, which is org-scoped status. Read the model once and configure each surface with the same mental picture of how anonymous access is constrained.

​
Feedback surfaces, not the status model

The org-scoped status model owns the incident feed: declared incidents, per-channel impact projections, and the white-label status URL you hand to customers. None of that lives here. The surfaces on this page are feedback and trust surfaces: they take input from your users (ideas, questions, help feedback), or they publish trust information (help articles, sub-processor notices) — inbound and outbound respectively, both unauthenticated. A widget-style “was this affected?” question and a “how do I do X?” question resolve to different surfaces; this page is the map that keeps you from conflating them.

​
Idea board: hosted, opt-in, tenant-scoped

The idea board is a hosted feature-request surface you enable per organization. Your end users submit product ideas, upvote the ones they want, comment for context, and read a public roadmap that exposes each idea’s lifecycle (under review, planned, in progress, shipped).
  • Opt-in per tenant. The board answers only when your organization has flipped the idea-board setting on. Until you do, the endpoint behaves like a non-existent route, which is also what keeps your surface list private.
  • Tenant scope by org slug. Requests carry your organization slug in the query string, so the board renders only your organization’s ideas; an unknown slug and a disabled board return the identical 404, which means a probe cannot enumerate tenants and cannot discover which tenants enabled the board.
  • Write bounds. Reads up to 120 per minute per IP; votes up to 30 per minute per IP (votes are idempotent per voter); idea submissions and comments up to 5 per minute per IP. Author email and visitor IP are HMAC-hashed before they are stored, never persisted raw, and content length is capped at the validation layer.
  • Roadmap is operator-side. A visitor can create ideas, comments, and votes only. The status of an idea moves only when an operator moves it; the public roadmap is a read projection of that lifecycle, and its shipped column doubles as your public changelog.
The roadmap’s shipped column surfaces in the JSON API, and the idea’s detail page reads the same lifecycle projection — one source, two views, so what you see answers what your users saw.

​
Community surface and public help-center read

Two more surfaces serve the same signed-out visitor in adjacent ways: The public help-center read is the self-serve knowledge base: anyone can browse and search the articles you marked public, which deflects tickets before they exist. The community sits alongside it: your users answer each other, which flips the ticket-you-didn’t-get into a question someone answered (publicly) once. Both resolve tenant scope by org slug, both collapse a disabled or unknown org to the same 404, and both bound anonymous writes with the same per-IP rate budgets and the same hashing of identifiers. Feedback and ticket submissions on the help center are one-way: no GET ever echoes your feedback rows back. Where the idea board and community overlap, choose deliberately: capture product feedback on ideas, deflect support on community, and run the help center as the content both link into.

​
Sub-processor subscription surface

The sub-processor subscription surface is a different audience processing different trust data: instead of your end users handing you feedback, you (the customer) register for advance notice before the platform adds or replaces a sub-processor, as most Data Processing Agreements require.
  • Register an email address or an HTTPS webhook endpoint; the surface records a pending row and returns a signed confirmation token keyed to the row.
  • Confirm or unsubscribe with a signed, single-purpose, expiring action token — the same human-readable links carried in the confirmation email. Tokens are verified in constant time, bound to one action and one subscription, and survive long enough for an inbox sweep (30 days).
  • Fail closed. The registration endpoint authenticates against a platform-side signing secret; when that secret is unset, the endpoint refuses to accept subscriptions rather than record them unconfirmed. A re-subscribe is an idempotent upsert on your canonical endpoint, so a repeated signup resets the double-opt-in cleanly.
It is invoice-grade process data anyone in the DPA flow may need: this surface does not require an account because its audience is your legal and procurement reviewers, not your operators.

​
The public-trust design invariants

Five invariants define the whole family. Together they let you explain to your users exactly how unauthenticated submission is bounded:
  1. Unauthenticated by design. The visitor is intentionally anonymous; no surface on this page asks for an account, API key, or session. Access control is not layered on a logged-in assumption, it is structural.
  2. Tenant-existence hidden on failure. Unknown org slug and disabled feature return the identical 404. Enumeration and feature-discovery both fail in the same way, which keeps your surface list private.
  3. IP-keyed rate limits. Each surface budgets anonymous reads, votes, and writes per IP at the validation layer, so a browser sees a bound, not a throttle guess.
  4. Hashed identifiers, never raw. Author email and visitor IP are HMAC-hashed before persistence; nothing stores them in reversible form.
  5. Zero outbound comms on idea submission. Submitting an idea, vote, or comment triggers no email, SMS, or other outbound channel; the sub-processor surface is the one outbound here, and it sends only the confirmation email owed to your registrants (outbound messages stay within the platform’s existing email path).
Something that LOOKS like an unauthenticated write but needs an internal credential — such as the sub-processor registration endpoint, which authenticates at the platform edge — is deliberately not counted under this family; the invariant is “unauthenticated by design,” not “unauthenticated everywhere.”

​
See also