# Make a connector issue reproducible

Connector name, operation, timestamp and a sanitized error or object reference.

## When you need this

A workspace administrator or a knowledge owner who sees a connector behave unexpectedly: an import that brings the wrong version, a document imported twice, or an error that repeats hourly. It usually starts when a lesson draft cites a document nobody updated. A report that only says the connector is broken helps nobody, because nobody can reproduce it.

## Steps

An issue brief records expected and actual behavior and whether a retry could import the same document twice.

- In the Web workspace, open Company Knowledge, select the connector and note its name, the operation and the failure timestamp.
- Copy the error text or object reference, and strip any access token, private content or credential before pasting it.
- Write expected versus actual behavior in two lines, and state whether retrying could duplicate an external action such as a written record.
- Send the brief to your workspace owner or the support contact in your agreement, and do not retry a write until someone confirms it is safe.

## What you should see

A fictional insurance brokerage asks for its policy manual system to be connected to Company Knowledge, and our team connects it. The knowledge owner, Nadia, finds a lesson draft citing manual version 7 while the source published version 8 yesterday. The connector log shows a 6:00 a.m. sync that ended with an object reference and a short error.

- The brief reads: connector Policy Manuals, operation sync, 6:00 a.m. today, expected version 8, actual version 7, retry safe because sync is read-only.
- The error text is pasted with the object reference kept and internal path removed.
- The workspace owner logs the brief, and the lesson draft is held until the version question is resolved.

## What to check before relying on it

Exclude access tokens, private source content and credentials. No support ticket is submitted by reading or using this website.

- Connector name, operation and timestamp are stated as shown in the workspace.
- The brief says whether a retry could duplicate an external action.
- No token, credential or private source content appears in the brief.

## If it does not work

If it does not work: confirm the timestamp against the source system's own log, because a source published after the sync ran is not a connector fault. If the operation was a write or a message, wait for your workspace owner to confirm the external system's state before retrying. This website submits no ticket; the confirmed contact in your agreement is the path.

## Questions people ask

**Q:** Can I retry a failed sync myself?

A read-only sync is generally safe to retry once. Anything that writes or sends should wait; a duplicate action elsewhere is hard to undo.

**Q:** What if the error keeps repeating?

Report the first and latest timestamps together; a pattern is easier to trace than a single occurrence.