Some records did not come through
A record MarqIQ could not turn into a row is set aside with its full payload and the reason, and the rest of the batch carries on — so "missing" records are usually kept rather than lost. This article tells you how to read the count, how to tell one awkward record from a systematic fault, and how to get them in. If the total is short rather than a handful of records being odd, read My record count does not match my CRM instead.
Before you start
You need one finished sync for the tool, because the counts below are recorded per run.
Tip
Read the grey notes line on the tool’s card under Data sources first, which needs Pro or above. A run that set records aside says so there in words, with the reasons attached — and that line tells you which section of this article you need.
What happens to a record that cannot be written
Every record in a page is written on its own rather than as one batch, so one bad record can no longer take the page with it. A record that fails is kept, with everything needed to understand and retry it.
- Your tool’s own id for the record, which is what a later successful walk matches on.
- The whole payload your tool sent, exactly as it arrived.
- The reason it failed — the part of the error that names the problem, up to 300 characters.
- How many times it has failed. A record that fails again is the same row with the count raised, not a second row.
- When it was last seen.
The walk carries on past it. The run is then recorded as partial rather than successful, because records were fetched and not written, and calling that a success is how a shortfall stays invisible.
Note
Two copies of the payload exist, and they expire differently. The set-aside record keeps its own copy for as long as the row lives. Separately, MarqIQ lands the payload of every record it fetches before it tries to map it, and keeps that copy for 30 days — so a mapping fix applied inside that window costs a re-merge rather than a fresh pull against your tool’s daily quota. That second copy is best-effort: it is never allowed to fail a sync.
Reading the count
The notes line names it in plain words, for example: "3 contact records could not be mapped and were set aside:" followed by the reasons. Each run also records four numbers separately.
| Number | What it means |
|---|---|
| Written | Records that landed in MarqIQ’s copy. |
| Fetched | Records received from your tool. Greater than written means records arrived and did not land. |
| Removed upstream | Records your tool’s own deletion log named, marked gone in MarqIQ’s copy. |
| Set aside | Records that could not be mapped. These are the ones this article is about. |
No screen shows fetched against written today, so ask support to read that pair from the run when a count looks short.
Take care
At most three distinct reasons per page of records reach the notes line. That is deliberate — a systematic mapping fault produces one message per record, and a log that repeated it a thousand times would say less, not more. The count is whole; the list of reasons is not.
One awkward record, or a systematic fault?
The count and the reasons together tell you which, and the two need different responses.
| What you see | What it is | What to do |
|---|---|---|
| A handful set aside, with different reasons | Individual records carrying something the mapper cannot use — an unparseable date is enough on its own. | Fix those records in your tool. The next walk that reaches them writes them. |
| Hundreds or thousands set aside, all with one reason | A systematic fault: one field on one object is arriving in a shape MarqIQ cannot map. | Raise a case with the reason quoted exactly. The payloads are kept, so a mapping fix can be re-applied to them without pulling from your tool again. |
| Nothing set aside, and the total is still short | Records never arrived at all. Set-aside is not the cause. | Read the next section. |
A record that later maps is marked resolved rather than deleted, because "this used to fail and no longer does" is the only evidence a mapping fix worked.
When the records never arrived at all
Set-aside records were fetched. These were not, and each cause looks different on the card.
The credential cannot see them
Why: MarqIQ reads exactly what your connected user can read. Salesforce applies that user’s sharing rules and field-level security; a Pipedrive personal API token carries its owner’s record visibility; a Dynamics security role whose read depth is User returns an empty list, because the application user owns nothing.
Fix: Connect as a user who can see the whole database — a dedicated integration user is the usual choice — and sync again. On Dynamics, "Fully synced — 0 records" is almost always this.
The object was stepped over
Why: Where your tool names the object it is refusing, MarqIQ skips that object and carries on with a note rather than failing the whole run. On Salesforce that applies to Accounts, Opportunities and their companions; Leads and Contacts are the two it will never step over, so a failure there stops the run.
Fix: Read the notes line — it carries wording such as "Opportunity: not readable by this connection — skipped." Grant that object to the connected user and sync again.
The run hit a per-run cap
Why: Some walks are bounded per run, and a few of those caps mark themselves caught up either way, so what is past the cap is not picked up next time. Pipedrive reads at most 20,000 leads per run, and its sweep for deleted people and companies reads at most 10,000 changed records per run. Zoho reads at most 4,000 deleted ids per module per run.
Fix: Nothing on the day. Where an account churns faster than those caps, tell support — the caps are stated so the shortfall is explainable rather than mysterious.
Marketo holds nothing at all after a first sync
Why: Marketo has no "list all people" call, so the first sync walks the person-id space blind. Where MarqIQ holds no Marketo records and the first 350,000 ids come back empty, it gives up and falls back to the change feed — so an instance whose person ids start above that is never fully loaded.
Fix: Raise a case with your Munchkin ID and the lowest person id in your instance. The change feed still brings in everyone who changes from then on.
The count is short and no run says anything is wrong
Why: A delta walk can only ask what changed since a moment in time. A merge changes a record’s id, and an association change moves no timestamp at all, so neither is visible to it. Once a week MarqIQ asks your tool how many records it holds and compares.
Fix: Read the notes line for the drift figure. "Are in the source but not here" is fixed by a full reload; "are here but not in the source" means records were deleted in your tool without appearing in its deletes feed. The comparison never repairs anything on its own, on purpose.
Getting the set-aside records in
Read the reasons on the notes line, and note the object they name.
Open one of those records in your own tool and look at the field the reason names.
A date that is not a date is the commonest — a text field holding something like "n/a" where a date is expected fails outright.
Correct the value in your tool.
MarqIQ cannot correct it for you. The record failed before it existed in MarqIQ’s copy, so there is nothing here to propose a change against.
Click Sync on the tool’s card.
The next walk that reaches the record writes it and marks the old failure resolved. The set-aside count on the new run drops by what you fixed.
Ask support for the full list where the reasons do not identify the records.
MarqIQ keeps every set-aside record with its id, its payload and its reason, and there is no screen that lists them today. Quote the tool, the object and one reason exactly as written.
Note
Where the fault is in the mapping rather than in your data, payloads fetched inside the last 30 days can be re-mapped without a single call to your tool. That is the point of keeping them, and it is why the reasons are worth reporting even when the records look unimportant.
If it did not work
The set-aside count stays the same run after run
Why: An incremental run only re-reads records your tool says have changed. A record you have not touched is not fetched again, so its failure is not retried.
Fix: Change something on the record in your tool, which moves its modified timestamp and brings it into the next incremental run.
A record you fixed still does not appear
Why: The failure was resolved but the walk had already passed that page, or the fix moved no timestamp your tool reports.
Fix: Press Sync once more and check the tool’s record count on the card afterwards. A repeat is harmless — every write is an upsert.
The notes line lists three reasons and the count is far higher than three
Why: Only three distinct reasons per page are carried into the log. The count is the real number of records.
Fix: Treat the three as a sample. Where they are all the same sentence, it is one systematic fault rather than many separate ones.
The run reads partial and you can find no set-aside records
Why: Partial means records were fetched and not written, which includes failures that never reached the point of being kept — the store itself refused them.
Fix: Quote the run to support with the tool and the time. The fetched-against-written pair is recorded on the run even though no screen shows it.
Next steps
Related articles
Was this article helpful?