Company Brain
Editorial guide

A Read-Only Helpdesk Connector Should Not Mean “Ingest Everything”

A helpdesk connector can remove a painful setup step. Instead of exporting tickets, downloading macros, and rebuilding source references by hand, the team can select the relevant material directly.

Company Brain’s Zendesk connection is not available to customer workspaces yet. Today, you can upload a bounded Zendesk export and run the same review workflow without connecting the account.

That convenience creates a dangerous temptation: connect the account, ingest the whole workspace, and sort it out later.

Do not do that.

A full helpdesk contains unrelated queues, old cases, sensitive account context, one-time exceptions, stale macros, and years of behavior owned by different people. More records can make the result harder to review while exposing data the task never needed.

Read-only is an important safety property. It is not a scope.

Start with the decision the team needs to make

Before connecting a helpdesk, name the operating area and intended use.

Examples:

  • review billing-adjustment guidance and macros
  • document account-access recovery
  • improve bug-report evidence and escalation
  • resolve one onboarding-support handoff

Then name the owner who can approve the result.

This gives the connection a purpose. “Analyze our Zendesk” is not a reviewable purpose. “Turn the support operations view for billing and access cases into reviewed procedures, gaps, and macro drafts” is much closer.

Bound the selection inside the helpdesk

Use the narrowest selection that still contains the standard cases, meaningful exceptions, and current guidance.

A bounded selection may use:

  • one view or queue
  • specific tags
  • a date range
  • selected groups or brands
  • ticket status
  • a related macro set
  • another explicit support boundary

The exact controls depend on the helpdesk. The principle does not: the process owner should be able to explain what was selected and why.

Do not rely on a vague “recent tickets” scope if account type, region, product line, or support group changes the process.

Ask for the minimum read access

The connector should read only the records and fields needed to create reviewable source evidence.

That may include selected ticket conversations, macros, relevant user or organization context, and the metadata required to preserve provenance, meaning the trace back to each original record. It does not justify ticket mutation, writeback, broad administrative access, or workflow execution.

Credentials should stay server-side and scoped to one authorized organization. They should not appear in browser output, exports, logs, articles, or generated packs.

“Read-only” should remain true across the whole path, not only in the marketing label.

Preserve record identity

The review becomes far more trustworthy when a proposed rule can point back to the exact ticket, macro, or note that produced it.

Preserve:

  • the source system and organization
  • stable record identity
  • timestamps or versions
  • the selection boundary
  • relevant source snippets or references
  • import and refresh state

Do not copy raw records into an anonymous text blob and discard the link to their origin.

Make connection failures visible

Connected ingestion is not a single success state.

The workspace may be:

  • connecting
  • importing
  • ready
  • partial
  • stale
  • rate-limited
  • failed
  • revoked
  • disconnected

Those states affect what a reviewer can trust. If an import stops halfway, the source inventory must not imply the corpus was complete. If access is revoked, the system should preserve reviewed outputs safely while making the source state clear.

Retries and refreshes should be idempotent, meaning the same request can be repeated without duplicating records or corrupting the pack.

Keep organization boundaries hard

A connection belongs to one organization. Its tickets, cursors, imported source records, and packs must not be readable or reusable across organizations.

A person who can access one organization’s workspace should not gain access to another organization’s helpdesk connection through a guessed identifier, stale browser state, or shared import path.

The minimum requirement is simple: one Company Brain workspace must never expose another organization’s helpdesk data.

Connected records are still candidate evidence

A current ticket can be wrong. A macro can be stale. A manager can grant a one-time exception. A recent workaround can be unsafe to repeat.

The connector should feed the same review workflow as an upload or export:

  1. inventory the selected sources
  2. draft procedures, rules, gaps, conflicts, and open questions
  3. show source context
  4. let one accountable owner approve, reject, edit, or mark each item as Needs Edit
  5. finalize and export only after every Draft or Needs Edit item is resolved

Connection does not bypass review. It improves the path to review.

Design refresh and disconnect before launch

A safe connector needs a way to recover from change.

On refresh, preserve prior approved versions and show relevant changes for review. On disconnect, stop new reads, revoke access where possible, and make the retained-source and deletion behavior explicit. Do not corrupt reviewed packs merely because the live source is no longer connected.

If the system cannot honor revocation, organization isolation, provenance, or deletion behavior, external access should remain disabled.

How Company Brain fits

Company Brain has implemented a bounded, read-only Zendesk ingestion path behind strict activation gates. It keeps one authorized organization, one selected support source set, preserved provenance, and the same human-review workflow used for uploads and exports. Customer access remains disabled until the external-customer readiness gate passes and the production gate is enabled.

Future connectors will have to meet the same standard: bounded selection, read-only access, clear provenance, organization isolation, and human approval. A long list of connected apps would not make the result trustworthy by itself.

For why live records still need review before reuse, read live context is still candidate knowledge. For the current upload and export workflow, read your support queue already contains the SOP.

The next step

Define the helpdesk slice you would connect, the fields genuinely needed, the reviewer, and the intended use. If the source set is available as a supported export today, you can run the same bounded review without waiting for a connector.

If the source set, reviewer, and use are ready, open the upload workspace. If the boundary or data handling needs a closer look, get scoping help.