Inbox sync failed in Zintara: isolate the mailbox and missing message

Locate the reply before changing the connection

Open the affected account directly in its provider mailbox. Search for the expected response using a message you are entitled to inspect. If the provider does not have it, Zintara cannot retrieve it from that mailbox. Check the address used by the sender and any delivery error before treating it as a sync problem.

If the provider does have it, note its folder and receipt time. The current Zintara sync path reads INBOX. A rule that immediately archives or moves a reply can therefore matter. Do not disable all mailbox rules as a first step; use a controlled test that stays in INBOX to distinguish folder behavior from connection failure.

Work through one mailbox at a time

The current synchronization process selects connected accounts with incoming-mail settings. It can retrieve messages from some accounts while reporting failure for another. A workspace-level failure is a reason to investigate the affected mailbox, not evidence that every conversation is unavailable.

A ‘sync already running’ condition is also different from a credential rejection. Let the existing attempt finish and retry once before escalating. Repeated clicks do not create better evidence. Where the UI reports only a broad failure, give support the affected account and test time so the underlying error can be correlated.

Worked example: a provider rule hides a test reply

A fictional operator sends a controlled message from their connected mailbox and replies from a second account they own. They can find the response in the provider's archive, but not in INBOX. Zintara's current view does not show the conversation. Rather than reconnecting repeatedly, the operator checks whether a rule moved the response.

They then send another controlled response that remains in INBOX, choose the correct workspace in Zintara and use the Inbox Sync action. If this one appears, the experiment has narrowed the difference to the message path. It does not prove that every archived message will be imported or that moving an old message will necessarily replay it.

Controlled comparison
Reply A: provider archive → not in INBOX
Reply B: provider INBOX → run Zintara Sync
Record: mailbox, receipt time, selected workspace, result
Conclusion: investigate the differing path; avoid a global reset

Repair the failing branch and verify the result

Credential changes can invalidate an existing connection; Google explicitly revokes app passwords after an account-password change. Follow the provider-specific connection method rather than replacing unrelated settings. Never send support the password or refresh token.

After repair, perform one controlled incoming test and inspect the result. Also check your workspace and inbox category filters. An empty selected view and a failed mailbox connection are different observations.

1. Identify the mailbox and confirm the message exists in its provider INBOX.
2. Confirm connected status and incoming-mail configuration.
3. Resolve the exact authorization, network or folder issue using the provider's settings.
4. Use Inbox → Sync and inspect a fresh controlled response.
5. Review pending outreach to anyone whose reply may have been missed before resuming follow-ups.

Source: Google: Sign in with app passwords

Do not use reconnection as an unexplained reset

Deleting and recreating an account is not a neutral troubleshooting step: it changes account configuration and can affect associated work. Preserve the existing connection and collect evidence first. Ask for targeted support when the failure is unclear.

A successful sync is not a guarantee of a complete historical archive, every folder or every conversation classification. This guide describes the current incoming-mail path and a way to isolate its failures. For the role of the inbox in the wider workflow, see the product overview.

Source: Zintara unified inbox overview