How a change set works: propose, approve, apply, undo
A change set is the reviewed way MarqIQ changes records in your CRM. The change is built as a list first, shown to a person row by row, and written only after a workspace admin approves and applies it. Read this before you approve your first one. To build one, go to Propose a change. MarqIQ has other writes that are not change sets, and Who can approve what lists them.
A change set writes nothing until a person approves it
A change is proposed, approved, applied and — if you want it back — undone. The four steps are separate on purpose, and each one is recorded.
| Step | Who does it | What happens |
|---|---|---|
| Propose | A role holding Manage on Tool Operations, or an AI assistant on a token an admin allowed to propose | MarqIQ works out the changes from its synced copy of your records and saves them as a list. Nothing reaches your tool. |
| Approve or reject | A Workspace Admin approves. Whoever can propose can reject. | You read every item as what is there now and what it would become, then click Approve or Reject. |
| Apply | A Workspace Admin | MarqIQ reads the live value of every field first, writes only the items that still match, reads each field again, and records what your tool answered for each record. |
| Undo | A Workspace Admin | MarqIQ puts back what was there before. The button reads Put everything back. |
Note
A list waiting for approval is not a queued job. It writes nothing and changes nothing until an admin clicks Apply. You can leave one sitting, reject it, or let it expire.
The write re-checks the live value first
The list is built from MarqIQ’s synced copy of your records, and that copy is minutes or hours old. Records move on. At the moment you click Apply, MarqIQ reads the current value of every field on every record in the list and decides again, one item at a time.
| What the live value is | What MarqIQ does | What the *Result* column says |
|---|---|---|
| Still what the list was built against | Writes the new value | Changed |
| Already the value MarqIQ was going to write | Writes nothing, and does not count it as changed | Left as it was: it already held this value |
| Something else, changed since | Leaves it alone | Left alone: its value had changed |
| The record is no longer in your tool | Leaves it alone | Left alone: record no longer in the tool |
| Your tool refuses the write | Records the reason your tool gave | Refused by the tool |
An item whose value moved is skipped, never forced. This is why a set of 480 changes can finish as 360 applied. That is the correct outcome rather than a failure.
The write is read back
A record counts as changed only when your tool’s own answer says that record was written. MarqIQ writes to HubSpot 100 people at a time and to Marketo 300 at a time. Where the tool refuses a batch because of a record in it, MarqIQ narrows it down: a HubSpot batch is halved and each half sent again until the refused part is 13 people or fewer, and those go one at a time; a Marketo request is sent again one person at a time. One bad record does not stop the others, and each refusal carries the tool’s own reason. A refusal about the connection itself, such as the sign-in, a permission or a rate limit, is the same for every person, so those are not sent again.
After each batch MarqIQ reads again every record it sent, whatever your tool answered, with one more request the same size as the first.
| What the second read shows | What the *Result* column says |
|---|---|
| The field holds the value | Changed |
| Your tool accepted the write, and the field holds something else or the record is not there | Not confirmed, with what MarqIQ saw printed under it |
| Your tool gave no answer to the write, and the field holds the value | Not confirmed, with a note saying that MarqIQ sent a write, got no answer, and then read the value there. It is not called Changed: somebody else may have put the same value there |
| MarqIQ could not connect to your tool, so the write never left | Not sent. Nothing was written, and the record is not read again |
| Your tool gave no answer to the write, and the field does not hold the value | Not answered by the tool, with what the second read found printed under it |
| Your tool gave no answer to the write, and the record cannot be read either | Not confirmed, with what MarqIQ saw printed under it |
| Your tool refused the write, and the field holds the value all the same | Not confirmed, with what MarqIQ saw printed under it |
An item that is not confirmed, or was not answered, is not counted as changed, but your tool may hold what MarqIQ sent. Open the record in your tool to see what it holds. No answer covers a time-out, a connection that dropped after it was made and an error of your tool’s own: none of them says whether the record was written.
What Put everything back may write to
There are three kinds of record, and Put everything back treats each differently.
| The record | How its row reads | What *Put everything back* does |
|---|---|---|
| Your tool answered that it wrote this record | Changed | Reads it again, and writes the old value where the field still holds exactly what MarqIQ wrote |
| MarqIQ sent a write, or was sending one when its run was cut off, and nothing confirms it was made | Not confirmed, or Not answered by the tool | Reads it again, and writes the old value where the field holds exactly the value MarqIQ sent. MarqIQ cannot tell its own write from someone else putting the same value there, so the line under the button counts these changes apart and says so before you click. If you put that value there yourself, change those records back by hand in your tool afterwards |
| Every other record: refused, not sent, left as it was, left alone, not applied yet, or not known | As the row says | Nothing. It is never read and never written, whatever its field holds |
There is no control for leaving one record out of Put everything back, which is why the line under the button says what to do afterwards.
A set in which no item changed is labelled Nothing was applied. Where a write in it could not be confirmed, or was never answered, the label reads Not confirmed: check HubSpot (or Marketo) instead, because your tool may hold what MarqIQ sent. Put everything back is offered on such a set, and reads those records again.
You have 30 days to put it back
A Workspace Admin can click Put everything back on anything that was applied. MarqIQ refuses it more than 30 days after the set was applied, because too much else will have happened to those records by then. After 30 days the button is no longer shown, and the panel says why.
Undo reads again every record that may still hold what MarqIQ sent: the items that read Changed, and the ones MarqIQ sent a write for and could not confirm. It writes the old value back only where the field still holds exactly what MarqIQ sent. An item that was left as it was, left alone or refused is not read and not written, so a value somebody typed in by hand is never cleared. While any record may still hold what MarqIQ sent, because your tool refused the put-back, did not answer, or the time ran out, the button stays and can be clicked again for the rest. The set is labelled Put back only when none is left.
Undo restores a field only where it still holds exactly what MarqIQ wrote. If the field holds anything else by then, it is left as it is and the item is marked Not put back: the field did not hold what MarqIQ sent. A colleague’s later edit stands, and so does whatever one of your workflows made of the value. An undo never writes over a value MarqIQ did not send.
Take care
Undo puts field values back. It does not reverse anything your CRM did in response to the write — a workflow that fired, an email that sent, a score that recalculated. Check what your own automation listens to on those fields before you apply a large set.
Who in your team can press which button
Applying a set and putting one back are refused by MarqIQ’s server for anyone who is not a Workspace Admin. No other role can reach either one.
Approving is refused by the server too, for anyone who is not a Workspace Admin: Approving a change set needs a workspace admin. The Approve button is shown to everyone and greyed out for anyone else, with the line Approving and applying need a workspace admin. beside it. An approval on its own writes nothing; the apply that follows it is an admin’s as well.
Rejecting needs the Workspace Admin role or Manage on Tool Operations, the same permission proposing needs. Whoever can build a list can withdraw one.
How safe each change is
MarqIQ works out what a change would do from the items in it, not from a label whoever proposed it chose. The review panel prints the answer under How safe it is.
| What the change does | Who approves |
|---|---|
| Fills empty fields only. It cannot replace a value, and it can be undone. | A Workspace Admin. Every change MarqIQ offers today is this kind. |
| Replaces existing values. It can be undone from MarqIQ’s record of what was there before. | A Workspace Admin. No operation in the product produces one of these yet. |
| Cannot be reversed once the tool has done it. | Not offered. MarqIQ builds no change of this kind. |
One item that would replace an existing value moves the whole set into the second row. Because both change sets MarqIQ offers today fill empty fields only, every set you see is the first row.
The limits that keep a mistake small
- One change set holds at most 500 changes. MarqIQ cuts the list at a record boundary, so a person is never half-filled, and the summary tells you how far it read to build the set.
- A proposal reads your records 2,000 at a time, in order, and stops when the set is full or at 100,000 records. The summary says which. The next proposal carries on from where one stopped at 100,000.
- A list expires 14 days after it was proposed. After that it cannot be approved, and you build it again from fresh data.
- A field of a record that an open set already lists is left out of a new proposal, whichever operation proposed it. Two sets can wait at once; the same record is never proposed twice.
- A workspace may hold 20 open change sets at once. The 21st is refused until some are approved, applied or rejected.
- Every item must be a real change. A list containing an item that would change nothing is refused when it is proposed.
- Each field on each record may change once per change set.
- A workspace may make 20 proposals a minute, and 30 approve, reject, apply or undo actions a minute. The proposal limits are the same for an AI assistant’s token.
- One apply or undo stops starting new work after 150 seconds. Everything written by then is recorded. The items it did not reach are counted on the What happened line as not attempted.
What is recorded
The History list under each tool holds that tool’s 50 most recent change sets. Open one and the panel shows the summary, How safe it is, the What happened line, and every item with its own result.
- Who proposed it and on what date, and whether that was a person or an AI assistant.
- Per item: the person, the field, the value before, the value written, the one-sentence reason that record was chosen, and the result.
- Per item, where your tool refused: the reason your tool gave, with the field named by its label.
- The same messages once each above the table, with the number of changes each one stopped.
Note
MarqIQ also stores who approved or rejected a set, the time it was applied and the time it was put back. No screen shows those today, so ask support if you need them for an audit. A rejection records the person but not the time.
What a change set cannot do
These are limits of the product today, not of your setup.
- Change sets work in HubSpot and Marketo only. For any other tool that has operations, the panel says there is none yet.
- Every change set today works on people. Deals and companies are not changed.
- There is no way to exclude one record from a set. You approve the whole set or you reject it.
- An AI assistant may propose a change set and read where it stands. It can never approve, apply or undo one, and there is no route that lets it.
- A change set cannot create a field. If the field does not exist in your tool, your tool refuses the write.
Next steps
Related articles
Was this article helpful?