Make a connector issue reproducible

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.

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.

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.

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: 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.

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.

• What if the error keeps repeating? Report the first and latest timestamps together; a pattern is easier to trace than a single occurrence.