Retry. Re-executes the exact operation the entry refers to. A successful retry links back to the original and automatically acknowledges it, so the error count self-heals.
Acknowledge. For errors that need no (further) action - a test order the 3PL rejected on purpose, a data issue you have already resolved. Acknowledging keeps the entry for history but removes it from the active-error count (dashboard Errors card). Acknowledged-by and when are recorded; Re-open Error (Admin) undoes it. Acknowledge instead of deleting - the log is your evidence.
Timeouts acknowledge themselves. When a run of an operation succeeds, any older unacknowledged errors for that same operation whose message describes a transient connection problem (timed out, connection reset, bad gateway, and the like) are auto-acknowledged with a note naming the successful entry - the retry proved the outage passed. A persistent outage keeps its errors unacknowledged, keeps counting on the dashboard and keeps escalating to support, exactly as it should.
Process Anyway (Admin). On a failed despatch entry, an administrator can force the despatch through with the batch safety rules overridden for that one run. Use it when you are certain the 3PL's despatch is real but Odoo's batch picture disagrees - for example "only holds 0.0 un-batched unit(s)". The override covers an un-batched shortfall from batched stock (oldest expiry first - the goods physically shipped from some batch), creates any quantity Odoo does not hold at all, and creates unknown batches instead of failing. If the 3PL shipped more than was ordered ("shipped but only N was ordered"), the ordered quantity is delivered - completing the sales order normally - and the surplus is removed from stock by a negative adjustment, because those units physically left the warehouse. Every forced step is itemised in the resulting entry's Summary, the product's activity trail records the adjustment, and the instance chatter records who forced it. The next inventory sync reconciles the batch picture properly. This is deliberately a two-step action - open the entry, read the confirmation - and is never available to non-administrators.
Email Support. On any error or warning entry, opens a pre-filled
email to the provider's support contacts (configure them on the
provider card: one primary To, comma-separated secondary CCs) in your
desktop mail client. Everything that leaves Odoo is PII-redacted:
customer names, addresses, emails and phone numbers are masked in both
payloads and free text - over-redaction by design. Clicking the button
also downloads two files - sync-<entry>-request-redacted.json and
sync-<entry>-response-redacted.json - ready to attach to the email,
and stores a full redacted text report on the log entry itself.
Raise Support Ticket. The one-click alternative: sends the same PII-redacted report, with both redacted payload files attached, straight to your help desk's ticket intake address - the desk turns it into a ticket automatically, no mail client involved. Configure the intake address under Settings > 3PL Connector > Raise Support Tickets by Email (requires an outgoing mail server on the database). Every raised ticket is noted in the instance's chatter with who raised it.
In-app help widget. With a Zoho Desk ASAP add-on configured (Settings > 3PL Connector > In-App Help Widget), connector users get a floating help launcher inside Odoo: Knowledge Base search over this documentation, the Zia Answer Bot, and ticket submission - without leaving the screen they are stuck on.