A change was skipped, refused, or only partly applied

Why: The proposal was built from MarqIQ’s synced copy of your records. At the moment you clicked Apply, MarqIQ read the live value again and found something different. A colleague, a workflow or an import had filled that field in the meantime, and MarqIQ skips the item rather than writing over the newer value.

Fix: Nothing is broken. Propose the same operation again. The new set is built from a fresh read, so records that have since been filled are no longer in it, and anything still empty is offered again.

Why: The record was deleted or merged in your CRM after the last sync, so MarqIQ could not find it to read or write.

Fix: Run a sync from Connected Tools so MarqIQ’s copy matches your tool, then propose again. If a lot of rows say this, check whether a deduplication run or a bulk delete happened between the proposal and the apply.

Why: Those first-touch fields were never mapped, so MarqIQ proposed against its own default field names. Those fields do not exist in your tool, and your tool rejects the write. The message names the field by the label in the Field column and ends by pointing you at Field Mapping.

Fix: Open Tool Operations › Field Mapping and map each first-touch field to the property that actually holds it. Create the missing ones in your tool first if you need to. Then propose the set again.

Why: MarqIQ writes as the account you connected. That account may lack write access to the field, or the field may be calculated or read-only, or a validation rule or required field on the object may block the update. The refusal is your tool’s, and MarqIQ prints your tool’s sentence with the field named by its label. Where the connection lacks a permission, MarqIQ says which one and where it is granted.

Fix: Send that message to whoever administers the tool. Grant the connected account write access to the field, or relax the rule for these fields, then propose and apply again.

Why: The same thing is wrong for every one of those records, usually a field HubSpot does not have or a permission the connection lacks. MarqIQ writes to HubSpot 100 people at a time. HubSpot refuses the whole batch for one record in it and does not say which, so MarqIQ halves the batch and sends each half again, until the refused part is 13 people or fewer, and sends those one at a time, five at once. One bad record does not stop the other ninety-nine, and each refused row carries HubSpot’s reason for that record. A refusal about the connection itself (the sign-in, a permission, a rate limit) is the same for everyone in the batch, so MarqIQ does not ask again one by one. Where HubSpot says it does not have the field, MarqIQ asks five people and, when all five get that answer, gives it to the rest of the batch without sending them. The reason is also listed once above the table, under Why HubSpot refused, with the number of changes it stopped.

Fix: Read the message. It normally names the property or the value HubSpot objected to. Fix that, then propose and apply again. The records that did go through are no longer empty, so they are not offered a second time.

Why: MarqIQ updates Marketo leads by id and only ever updates, so it never creates a lead Marketo cannot find. Marketo answers record by record, so each row carries its own reason.

Fix: Read the reason on each row. A field Marketo will not accept needs the field name checked under Tool Operations › Field Mapping. A lead Marketo cannot find is not refused: it reads Left alone: record no longer in the tool, so run a sync and propose again.

Why: One change set holds at most 500 changes, so a mistake stays small. MarqIQ cuts the list at a record boundary, so nobody has half their fields filled.

Fix: Read the summary line, which names how many more are waiting. Apply this set, then propose the same operation again for the next 500. Repeat until the summary stops mentioning a remainder.

Why: MarqIQ matches a person to what it captured by email address, and it reads your oldest 50,000 recorded form fills. A person with no email address in your tool is never matched, and neither is anyone whose first form fill came after those 50,000.

Fix: Run Fill empty first-touch fields from the most recent touch for the people left over. Where a person has no email address in your tool, fix that first, because nothing else can match them.

Why: Between the proposal and the apply, somebody or one of your own workflows put the same value in the field. MarqIQ wrote nothing, so the item is not counted as changed, and Put everything back never clears it.

Fix: Nothing to do. The end state is the one you approved. If you need to know who wrote the value, check the field history in your own tool.

Why: MarqIQ reads each field again after it writes. Your tool accepted this write and the field then held a different value, most often because a workflow of your own rewrote it or your tool stored the value in another form. The note under the row says which it saw: the field was still as it had been, or it held a different value. Less often your tool refused and the field held the new value all the same, or your tool gave no answer and the record could not be read either. MarqIQ does not count the item as changed.

Fix: Open the record in your tool and read the field and its history. To remove what MarqIQ sent, a Workspace Admin can click Put everything back: MarqIQ reads the record again, writes the old value back where the field holds what MarqIQ sent, and leaves it as it is where the field holds anything else.

Why: The set was applied by MarqIQ as it worked before October 2026, and that run was cut off before it finished. Back then MarqIQ sent every write of a set before it recorded any of them, and sent nothing to a record that already held the value. So for a record that run left with no note, MarqIQ cannot tell whether it wrote to it: the value in the field may be the one MarqIQ sent, or it may have been there all along. MarqIQ does not count the item as changed and does not call the set Nothing was applied or Put back. Put everything back does not read that record and does not write to it, because it puts back only what MarqIQ knows it sent: clearing a value somebody else put there would be worse than leaving one of MarqIQ’s.

Fix: Open the record in your tool and read the field and its history. In HubSpot the property history on the contact names the private app that wrote each value. If the value came from MarqIQ and you want it gone, put the old value back there by hand. The line under Put everything back says how many such changes it leaves alone. Where they are the only ones in doubt the set is labelled Not known, there is no button, and the panel says why in its place.

Why: Before October 2026, when Put everything back was refused by your tool or got no answer, MarqIQ saved that answer over its note of what the apply had done to the record. It did that for records the apply had changed and for records that had already held the value alike. So nothing is left to say whether MarqIQ ever wrote to this record, and MarqIQ does not put it back: clearing a value that was there all along would be worse than leaving one of MarqIQ’s.

Fix: Open the record in your tool and read the field and its history. The line under the row quotes the answer that was saved. If the value came from MarqIQ and you want it gone, put the old value back there by hand.

Why: MarqIQ could not connect to your tool for these records: the connection was refused, the tool’s address could not be found, or no connection was made in time. The write never left MarqIQ, so nothing was written to them.

Fix: Propose the same operation again once your tool can be reached. The new set holds what is still empty.

Why: The connection to your tool dropped or timed out during the write, or your tool answered with an error of its own. MarqIQ read the record again and the field did not hold the new value. Most often that means nothing was written. A write that was cut off can still be finished by your tool a little later, which is why MarqIQ does not say the record was not written. The same result is recorded where a batch went unanswered and the record, sent again on its own, was then refused: the batch can still land, so the row is not called refused, and its note gives your tool’s reason for the later refusal.

Fix: To keep the values, propose the same operation again: a record that is still empty is offered again, and one that has since taken the value reads Left as it was in the new set. To remove them, a Workspace Admin can click Put everything back on this set: MarqIQ reads those records again and clears the field only where it holds what MarqIQ sent.

Why: One run stops starting new work after 150 seconds, so that it finishes inside the time MarqIQ has for one request. It also stops when your tool no longer returns current values part-way through. Everything written by then is recorded. The rows it did not reach still read Not applied yet, each with the reason underneath. A record that had already been sent when the time ran out is not one of them: it is read again like any other.

Fix: Propose the same operation again. The new set holds only what is still empty.

Why: Every item was left alone, refused or not sent, and not one changed. The set still holds a result for each item. The label is red when your tool refused a record or could not be reached. It is grey when every record was left alone.

Fix: Read the Result column and match each reason to its entry above. The commonest cause is a refusal your tool repeated for every record.

Why: No item is counted as changed, but at least one write could not be confirmed. Your tool accepted it and the field held something else when MarqIQ read it again, or your tool gave no answer. Your tool may hold values MarqIQ sent, so MarqIQ does not call this Nothing was applied.

Fix: Open the records the Result column marks and read the field and its history in your tool. To remove what MarqIQ sent, a Workspace Admin can click Put everything back: MarqIQ reads those records again, and writes the old value only where the field still holds what it sent. The line under the button says how many changes it will read, counts the ones that are not confirmed apart, and says what to do if you put that value there yourself: MarqIQ cannot tell its own write from someone else’s. It also says how many that read Not known it leaves alone.

Why: No item is counted as changed, and every record in doubt reads Not known: a run before October 2026 was cut off before it kept a note for them, or a Put everything back before October 2026 failed on them, so MarqIQ cannot tell whether it wrote to them. Your tool may hold values MarqIQ sent, so MarqIQ does not call this Nothing was applied, or Put back where other records were put back.

Fix: There is no Put everything back button, because MarqIQ puts back only what it knows it sent, and the panel says so in its place. Follow Rows read Not known above: check each record in your tool, and put the old value back there by hand if it was changed.

Why: People this set had sent a write to were later erased from MarqIQ at a privacy request. Their changes are gone from the set, so MarqIQ does not list them and cannot read them again or put them back. It keeps one mark for each such change. The mark holds nothing about the person; it keeps only what the change read when it was removed. The What happened line says how many changes that is (one person can have several) and counts three kinds apart. A change that read Changed is said to be changed: what MarqIQ wrote stays in your tool. A change whose write was never confirmed is said to be not confirmed: your tool may hold what MarqIQ sent, and MarqIQ cannot say more than that. A change that read Not known is said to be not known: MarqIQ cannot tell whether it was sent. The label appears once no listed record may still hold what MarqIQ sent, and it stays after Put everything back has put the others back: the set is never called Put back or Nothing was applied while an erased record may still hold what MarqIQ sent.

Fix: Correct those records in your tool if they need it. Where the line says a change was not confirmed or is not known, open the record in your tool to see what the field holds.

Why: MarqIQ recorded this set as applied, and no change it still lists was written: each already held the value, was left alone or was refused. A set comes to read this way through how MarqIQ worked before October 2026. Back then a record that already held the value was recorded as changed, and erasing a person removed their changes from a set with no mark left behind. So MarqIQ can speak for the changes it lists and for nothing else, and the What happened line says so. No changes listed means none is left on the set.

Fix: Nothing, for the changes listed: MarqIQ wrote none of them. If you need to know what the set wrote to one particular person, open that record in your tool. In HubSpot the property history on the contact names the private app that wrote each value.

Why: Your tool would not return the current values, so MarqIQ stopped before writing anything at all. The red message names what the tool said and ends with Nothing was changed.

Fix: Check the connection under Connected Tools, reconnect it if it asks, and click Apply to [your tool] again.

Why: A proposal is good for 14 days. After that the records will have moved on, so MarqIQ refuses it rather than applying a stale list.

Fix: Propose the operation again. The new set is built from current data, and anything already fixed is left out of it.

Why: Undo restores a field only where it still holds exactly what MarqIQ sent. This field held something else, and the line under the result says which case it is. Either the field was changed after MarqIQ wrote it, by a colleague or by one of your workflows. Or MarqIQ’s own write was never confirmed, and the value there may be what your tool made of it: a workflow that reformats the value as it arrives, for one. An undo never writes over a value MarqIQ did not send.

Fix: Nothing is broken. Decide per record whether the value there is right. If it is not, correct those records in your tool.

Why: MarqIQ could not confirm that the old value went back. Your tool accepted it and the record could not be read again, or the field then held some third value; or your tool gave no answer and the record could not be read.

Fix: Click Put everything back again. MarqIQ reads the record first: where it holds its old value the row becomes Put back with nothing written, and where it still holds what MarqIQ wrote the old value is sent again. You can also open the record in your tool and correct it there.

Why: MarqIQ tried to put the value back and your tool refused the write or did not answer, so the record still holds what MarqIQ wrote. The set keeps its Put everything back button, and the reason is listed once above the table, under Not put back yet, and why. The label reads Applied where nothing was put back and Partly applied where some records were.

Fix: Read the tool’s message and fix its cause: wait for a limit to reset, reconnect the tool, or have the rule that blocks the clear relaxed. Then click Put everything back again. MarqIQ reads again only the records that may still hold what it sent.