Custom quote property gets silently overwritten by an unrelated save in the quote editor

We built a workflow that writes a custom checkbox property on the Quote object, called requires_approval, used together with Standard Approvals to block publish when a line item price is below a floor price. The workflow itself works correctly every time it runs. The problem is downstream, in the quote editor.

Here is the exact sequence we reproduced, with timestamps from the Quotes API propertiesWithHistory endpoint, portal is Professional tier, no Enterprise.

  1. line item price is 40, below a 50 floor, workflow correctly sets requires_approval to true.
  2. we raise the price to 60, above the floor, in the quote editor.
  3. workflow correctly re runs and sets requires_approval to false, sourceType shows INTEGRATION, our workflow’s own ID.
  4. we then save a completely unrelated field in the same quote editor session, in our case the Seller Company panel, no price field touched, no checkbox touched.
  5. immediately after that save, requires_approval flips back to true, sourceType shows QUOTES, not our integration, meaning the editor itself wrote this value, not our workflow and not a manual click on the checkbox.
  6. Request approval is then clicked, reads requires_approval as true, and the quote is blocked in PENDING_APPROVAL, even though the price is correct.

We suspect the quote editor loadss own frontend state on page open,and any later save in that same sed copy of the whole quote,
overwriting whatever a workflow wmeantime.

Has anyone else seen a custom quoike this by an unrelated save inthe quote editor. Is this expectee a documented way around it, suchas forcing the editor to reload troperty setting that opts a fieldout of this caching. Any pointers this would help too, we could notfind it addressed anywhere in the current Quotes API guide

I think your diagnosis may be correct. There have been similar reports in the Community of the quote builder overwriting values that were changed outside the editor while the quote was being edited.

HubSpot’s documentation also notes that changes in the quote editor are autosaved. So your sequence makes sense: the editor loads the quote with requires_approval = true, the workflow subsequently changes it to false, then another save from the already open editor appears to persist its older state and writes true back.

The sourceType = QUOTES in the property history would seem consistent with that as well, especially since you’ve confirmed the workflow’s write to false immediately beforehand.

I found a similar Community discussion where the quote builder was reported to overwrite data set by a workflow:

I don’t see a documented setting that forces the open quote editor to refresh a property after an external update. As a workaround, I’d avoid relying on a workflow changing a quote property while that same quote is actively open for editing. If possible, moving the approval flag to an associated record, or triggering the calculation after the editing step, may avoid the collision.

Given that you’ve reproduced it consistently and have the property history showing the two different sources, this also seems worth raising with HubSpot as a potential quote editor issue.

Hi @huzaifasr and welcome, we are so glad you are here!

Thanks for reaching out to the HubSpot Community and thanks @FYossef for your help!

A save to an unrelated panel (e.g., Seller Company) should not overwrite properties that were updated externally (via workflow/integration) after the editor session opened. So what you are describing seems to not follow the expected behavior.

Here is the documentation for reference: Quotes API guide - HubSpot docs

Let me investigate this internally and I’ll get back to you as soon as possible.

Thanks for your patience @huzaifasr!
Bérangère

Hi @Berangere, thanks for looking into this. I did some more testing on my end since posting, and found something worth sharing. I edited the price above the floor, then instead of submitting right away I hit a hard refresh on the quote editor page, and after that refresh the flagged status was gone, matching the corrected value. So it does seem tied to the editor session caching the property value in the frontend when the page first loads, then resubmitting that cached value on a later save, rather than reading the current server value. A page refresh before submitting avoids it every time in my testing.