A dashboard workflow write through MCP uses an outer UUID idempotency_key. That identifier lets the service recognize a retry and replay a confirmed outcome rather than dispatching the same work again.
If a network interruption occurs after a write request, keep the original request identity. Do not retry the uncertain operation with a new ID merely because the assistant did not receive a clear response.
Ask the assistant to inspect the saved outcome or original workspace record and retry the same attempt through the supported workflow. A new request ID should represent a genuinely new operation, not an attempt to force a response from an ambiguous earlier one.
When asking support to investigate, provide the safe request ID, operation, company, and error wording. Keep private record payloads and credentials out of logs and messages. The goal is to establish whether the original operation completed before another mutation occurs. A timeout is uncertainty about the response, not proof that the server made no change.
Was this article helpful?
Tell us whether this answered the question you came with.