This page is intentionally text-only. demo2's Sync Monitor currently has zero profiles and zero diagnostic rows, so its screenshot would show navigation but no symptom, failing cycle, conflict or step evidence. Use the live monitor named below when an actual incident exists; do not substitute an empty console image for troubleshooting proof.
Work from the symptom. Each section below opens with the most likely cause, then the rest in order of likelihood — and almost every diagnosis starts in the same two places: the app's run history and the Sync Monitor.
A scheduled flow or profile never runs
Most often the cron expression. Schedules are six fields with a leading seconds field (0 */15 * * * *), in UTC. On integration triggers, an invalid expression — classically a five-field cron — is accepted on save but silently skipped on every tick, so the trigger sits active and never fires. Re-save the trigger with six fields.
Then check the active flags, because three stack: the trigger, the flow's version (exactly one active version must exist — a schedule dispatching a flow with no active version fails the run), and the app itself. Also note: schedule triggers do not fire in sandbox tenants, and downtime is not backfilled — after an outage only the latest matured occurrence fires once.
"You don't have access to this integration app"
You have the capability (you can see the list) but no membership on this app. Access inside an app is granted per security profile on its Members tab — Viewer, Operator, ConnectionManager or Admin — and new apps start with only the creator and system administrators. Ask an app Admin to grant your profile a role; to decide approvals you need Operator or higher, and to manage secrets, Admin.
The connection test passes, but runs fail with authentication errors
For the generic HTTP/REST connector this is expected behavior, not a contradiction: its test proves reachability — any non-server-error response passes, including a 401. Open the test details and read the returned status; a 401/403 there means the credential is wrong even though the test shows green. Credentialed connectors (Salesforce, Zoho) genuinely fail their test on bad credentials, so for them a passing test plus failing runs points elsewhere — usually at permissions on the specific records or objects, or at a credential rotated on one side only.
A run failed and I need to know why
Read it in three layers on the app's Errors tab. Start with category and message. Transient faults can retry with backoff, deterministic failures wait for correction, retries-exhausted work dead-letters, and the orphan sweeper handles runs that never reached a terminal state. Then inspect steps. Step status and errors are always useful, but input/output snapshots exist only when captureStepData was enabled for that flow version and the retention sweeper has not removed them; redaction does not create a snapshot that was never captured. Fix the cause before replay.
Replay accepts only Failed, Succeeded, DeadLettered or Rejected runs. It needs the original flow definition to still have an active version, plus an explicit body or retained archived InputJson. The new run uses the current active flow version and is linked to the original; it does not execute a deleted historical version merely because that version id remains on the old row.
Inbound records are duplicating
The write is not keyed. An inbound sink without an external key (or with write mode Create) inserts on every run; with Upsert plus a stable external key — the source system's record id — re-runs update the same records instead. If duplicates already exist, clean them up first, or the keyed writes will keep updating one of each pair while the others sit stale. Sync profiles do this pairing automatically through their ledger, which is one reason to prefer a profile for standing synchronization.
A sync profile runs green but records are not syncing
In likelihood order:
- The sync identity cannot see them. The engine reads and writes as the profile's sync identity, bounded by record security — a narrowed identity silently stops syncing what it cannot read. Widen that user's access deliberately.
- An entity needs a reseed. The health board's "Reseed required" column means the cursor has no trustworthy baseline behind it; reseed the entity from the profile.
- The records are parked. Check the profile's Records tab: Excluded records were stopped by an "Ignore always" conflict resolution and stay stopped until resumed; Error records show their last failure inline.
- Nothing actually changed. Echo suppression drops re-reads whose content hash matches the last sync — a cycle full of echoes writes nothing and is healthy.
- For push-based systems (Tally): the site went silent. No run, no error — only the Sites column shows it. The fix is at the client end.
The same conflicts keep reopening
Someone is resolving them without changing the facts. Merged by hand records your claim that you reconciled the values yourself — the engine writes nothing, so if the two sides still disagree, the same conflict is redetected next cycle. Either pick a side (Keep xMatix / Keep external, which actually writes), genuinely align the records, or — if this record should simply stop syncing — use Ignore always and accept the parking. A rising detection count is the tell that a conflict is being closed cosmetically rather than decided; a rising backlog suggests the conflict policy is stricter than the data needs — field-level merge resolves edits to different fields without human traffic.
Inbound runs park as "pending approval" and nothing lands
The entity binding requires approval — by design. An Operator decides on the app's Approvals tab; approving with auto-replay left on re-dispatches the parked run's archived input so the records are written without re-fetching. Approving without auto-replay closes the approval but writes nothing, which is the usual cause of "we approved it and still no data". Parked runs are eventually reaped as failed by the orphan sweeper; the approval remains decidable, and approving with auto-replay still recovers the work.
Everything from one app failed at once
A shared dependency moved. In order: a secret was rotated or deleted while still referenced (resolution failures on every run that uses it); the external system revoked the credential (auth errors that do not self-heal — deliberately not auto-retried); or the app was deactivated, which stops schedules and refuses dispatches as its kill switch. The app's Errors tab timestamps make the "at once" moment easy to correlate.
Common questions
Does a failed integration ever affect users saving records?
An integration failure cannot roll back the business write because entity-event handling occurs after commit and dispatch runs separately. The post-save handler still scans active trigger configuration and queues matching work, so it can add some post-save latency even though connector execution is not coupled to the response. Failures may be visible only in run history or logs, which makes monitoring essential.
Is it safe to just replay a failed run?
Only after checking eligibility and idempotency. Do not replay a non-terminal run or one still inside its automatic retry window. Confirm archived input is retained (or supply the intended body), a current active version exists, and downstream writes are keyed. For batch runs without per-item completion evidence, replay can reapply the full batch.
When should I pause versus deactivate?
Pause the single trigger (its active flag) to stop one flow; deactivate the app to stop everything it owns — schedules stop, dispatches are refused. Both preserve all configuration, watermarks and history, and neither cancels runs already in flight; those are cancelled individually. Deletion is the only destructive option and takes the app's whole contents with it, so treat it as last resort.