Skip to content

Deal Category and Template Release

Release status — 28 October 2026

The six-category backend and Qwilr update correction passed the normal deployment preflight and production release from commit 9d750fb3f469b3497f5f3db602553ec0714a518e. App and documentation containers passed health checks. The operator installed the categories ZIP as widget version 6.0. A fresh CRM session verified the Home category label, category-review control, successful draft saving and the quote action returning the existing Qwilr page. The release package is available in the local checkout at .local/widgets/peppermint-quote-builder-categories.zip.

The live field retains API name Business_Category and ID 42659000013442096. Its label is Deal Category; all six choices are active. The Standard layout remains shared to Administrator and Standard profiles, with the field required and no default. Legacy MSP and Tech Projects are unused options, preserving historical records. No existing customer Deals were migrated.

The active Reserved workflow 42659000014367298 matches MSP - New Client, Tech Project, MSP and Tech Projects. Its Stage trigger and function action are unchanged. The operator explicitly approved Zoho's warning that changing criteria resets this workflow's usage-report history. The active Deal-created workflow still calls the middleware for all new Deals; the middleware decides which categories receive Scoping projects.

Five new saved blocks were created in Qwilr and their IDs/types verified through GET /v1/blocks/saved. All 25 distinct blocks referenced by the five compositions exist; each composition has one QuoteV2 block and one Accept block. Preparation used no proposal credits. Rollout created one internal draft, then reused it for content replacement checks. Nothing was published, sent or accepted.

Live testing found that Qwilr rejects page-level metadata on PUT. Update requests therefore send only saved blocks, substitutions and published: false. Initial page metadata is not a current revision record; use replaced line metadata and the backend's quoted snapshot. The corrected request returned HTTP 200 on the same draft. A regression assertion covers the supported update request fields. After deploying the correction, the live backend successfully changed the test offer to MSP additions and back to Home, requiring explicit category review and returning the same page ID on each update and unchanged retry. The controlled draft's stale pending marker from the rejected request was reconciled against the confirmed Qwilr result, with a backup and exact saved-version checks.

Verification evidence and remaining review

  • Full suite: 1,269 passed, 1 skipped. Both strict documentation builds are required for each published documentation change.
  • Six controlled Deals passed live category, design, billing-default and draft-save checks. Only new-client MSP returned preset sections. Test record creation used trigger: []; it did not invoke project, email or billing workflows.
  • Changing the controlled Deal's category blocked generation and unreviewed saving; explicit review preserved its existing line and selected the new composition.
  • Browser rendering checks covered MSP, Tech Project, Retainer, Hardware and the shared standard composition. All reused the same draft and its zero-price test line. These checks do not replace staff review of scope, wording or mobile layout.
  • Anonymous and invalid-widget-key requests returned HTTP 401. The operator's widget-load confirmation is distinct from a separate Standard-profile test.
  • The existing Test Oc26 draft checksum stayed unchanged: b4be29546b1fcd8b56901364db92820eb90fd9ba94e978be503be67e7ab7bf3f. Its backup is under .deploy/backups/deal-categories-20261028/offers on the server; the previous widget package and private CRM metadata snapshots are kept locally.
  • Open legacy Deals still need individual business review. Lead conversion, imports, Standard-profile interaction, full mobile design review and preview acceptance remain explicit follow-up checks. Do not infer those checks passed from metadata inspection or the controlled API tests.

Reusable acceptance test journeys

Keep five independent test Deals and Qwilr drafts, one for each Qwilr journey. Home is excluded: its end-to-end test path does not require Qwilr. The operator approved three additional page creations, reusing the two existing drafts for Tech Project and new-client MSP. All five remain internal drafts; use preview acceptance and never send or accept them as real customer orders.

Journey CRM Deal ID Qwilr draft
MSP - New Client 42659000019315011 6ae1e1533ecaa8f33ce9286e
MSP - Additional Product / Service 42659000019346004 6ae1fdaed8224979c6418909
Tech Project 42659000019343004 6adf77ddedeaac49435ffa8d
Tech Retainer 42659000019346007 6ae1fdb14598238e3754ce29
Hardware 42659000019342008 6ae1fdbaf12322e49ae7f418

Enable Reset proposal only for these IDs through OFFER_TEST_DEAL_IDS. Their names must also start with TEST. Reset restores the current category's new-offer configuration while keeping its Qwilr page, and archives the old draft. Configure products after reset, then update the existing Qwilr quote. Repeat preview acceptance on the rebuilt revision; reset does not undo downstream project, service or billing changes. It cannot reset real accepted pages. See reset behaviour.

The original Test Oc26 Deal and four unused category test Deals were deleted with workflows disabled after backups. Their saved offers remain archived under recovery/two-test-deals-20261028/ in the server offer directory. Test Oc26's linked project was left intact. Its Qwilr page was reassigned to Tech Project; the former Home Deal and page were repurposed for new-client MSP. Page-level creation metadata may identify the original Deal or category; acceptance tests must use the current saved association, quoted snapshot and replacement line metadata rather than creation metadata alone.

These Deals have no Company. They support proposal and preview-acceptance tests; company/service linkage must be configured deliberately before testing downstream activation or billing. Their existence does not mean that the Service Line and billing handoff is implemented or verified.

The installed 27 October widget baseline and its evidence are recorded in Deal Offer Editor. The Deal offer rules and staff procedure define the six-category behaviour.

Category and design mapping

Keep the existing field API name Business_Category and field ID. Rename only its display label to Deal Category, make it required on new Deal creation, and leave its default blank. These changes apply to Deals, not similarly named fields on Accounts, Products or the exploratory Commercial Services module.

Active picklist value Design source Composition identity
MSP - New Client MSP master; existing Automation MSP saved snapshot 6adf7a2373060bd251f95f61
MSP - Additional Product / Service Plain shared layout; no master supplied standard-2026-10-28
Tech Project Tech Project master; existing Automation Tech Projects saved snapshot 6adf7a81a5a8a42d0afd9c3f
Tech Retainer Retainer master plus shared introduction, quote, acceptance and current footer retainer-2026-10-28
Hardware Plain shared layout initially hardware-standard-2026-10-28
Home Plain shared layout; no master supplied standard-2026-10-28

Composition identities are internal registry keys, not necessarily Qwilr page IDs. app/offer_templates.py defines their ordered saved-block IDs. Staff select the category, not arbitrary Qwilr templates. Several categories can share a layout without sharing their business rules or default billing frequency.

The old Hardware master contains another integration's repeating Product variables and a Computer Setup charge. It is not used in this release. A future Hardware design must replace all quote sections and resolve/remove its owner/creator variables before activation. The Retainer's older footer is not copied; the existing shared footer is reused. Retainer scope and terms are design content, not implemented rollover or billing logic. Review their suitability for the offer before sending.

Saved blocks prepared

Saved block name ID Type
Release 2026-10-28 Retainer Cover 0yqxqXXXFsyZFmoU4_11lzI21visgQ Text
Release 2026-10-28 Retainer Scope OLdrGGK6-t_tkE1EIgc0nncPzfDiNg Source
Release 2026-10-28 Retainer Terms aR0TVhmW-aK81K-2vPbDtvsFlmjM3w Text
Release 2026-10-28 Standard Products q7TCnvN2FOw4sotK8QawLclt0nevPg QuoteV2
Release 2026-10-28 Standard Acceptance GWGMeDuzl-N2ldPCPWpiO0kfrcQiKQ Accept

The standard composition is Products → Acceptance → existing company footer. It contains no assumed project terms or MSP onboarding. Its placeholder quote row is zero-priced and is completely replaced by the configured offer sections. The acceptance text asks the customer to review products, services and billing frequencies. Appropriate scope and agreed terms remain a staff review before sharing.

Coordinated CRM rollout

  1. Record the current field ID, active values, layouts, required/default settings, workflow filters and any reports, Blueprint rules, buttons or integrations comparing category text. Back up local offer files and current widget package.
  2. Deploy the compatible backend and upload the rebuilt widget together. Use the existing widget installation procedure and normal deployment pipeline. The updated widget needs the new category response and review control. Avoid a mixed-version rollout window.
  3. Add the six values above to the same local picklist. Preserve historical values/records; do not use bulk replacement to turn all MSP into new-client MSP, or all Tech Projects into one-off projects. Remove legacy choices from new-entry options only through CRM controls that preserve existing records; verify the effects in the actual layout before saving.
  4. Rename the display label, require deliberate selection on new Deals and retain a blank default. Check Lead conversion, imports, API-created Deals and both Administrator and Standard profiles, not just the administrator's form.
  5. Review the deal-created workflow: new-client MSP, Tech Project and Tech Retainer need Scoping projects; MSP additions, Hardware and Home must not create them. Middleware also skips blank/unsupported categories. Correcting a category later does not itself invoke project creation; rerun setup deliberately if needed.
  6. Update the existing Reserved workflow criteria to include MSP - New Client and Tech Project, retaining the old MSP / Tech Projects paths while legacy records remain. The previously inspected Deal Won Deal Automations workflow ID is 42659000014367298; inspect current criteria before editing. Do not add Retainer or MSP additions to the one-time delivery-model setup.
  7. Review open legacy Deals individually. Choose new-client versus additional MSP, and one-off project versus Retainer, from their actual scope. Historical closed Deals can retain their old values. Reporting can group canonical categories without rewriting historical deals; existing reports using exact old labels need their filters reviewed.
  8. Verify six controlled records, reusing existing drafts where appropriate. Confirm design, empty/preset products, billing defaults, manual category-change review, missing category rejection and project-routing behaviour. Review a Home offer without a Company: the plain layout has no Account placeholder.

Retainer gets a Scoping project but no automatic Reserved delivery model. MSP additions must be associated with the existing service during manual review; service-lookup enforcement and the accepted-Service-Line handoff are not yet built. These limits are explicit so the category change cannot silently create a new MSP onboarding project or a one-time retainer model.

Future design releases through a browser harness

The team can keep editing the Qwilr masters. An AI workflow with browser access can perform the following procedure at an agreed release; model choice does not change the validation or activation steps. This page is the runbook, not an installed scheduled harness or an automatic synchronisation service.

  1. Open each named master and record its block order, variables, quote positions, foldable content, acceptance settings and attached Agreements. Compare it with the current released composition. Use release copies so a partial run cannot change the active design.
  2. Save the non-quote design blocks through Qwilr's UI with a release-specific name. Do not bring source Product rows, prices or optional charges into the offer. Use one known dynamic QuoteV2 shell at the chosen pricing position. Multiple source quote blocks need an explicit design decision; never leave a second unpopulated quote block in the page.
  3. Capture each saved block ID and verify its type through the saved-block API. Check that every referenced block exists, exactly one is the replaced QuoteV2 block, and exactly one is Accept. Review embedded/custom HTML, variable values, company details, discounts, taxes and legal attachments separately. API block inventory alone does not verify content or attached Agreements.
  4. Add a new composition identity and point the category mapping to it. Keep old identities and saved blocks while any drafts or rollback may need them. Avoid editing/deleting active release blocks in place. A changed release applies on the next explicit draft save/update; it does not rewrite signed pages.
  5. Run offline tests, inspect an assembled draft through the normal supported Qwilr API, and review desktop/mobile layout and acceptance content. Reuse one designated draft per scenario; update that draft instead of generating another.
  6. Activate the reviewed registry through the normal release pipeline and record the source master, release date, ordered IDs, validation and exceptions here.

Qwilr documents saved blocks and the public API. The public API lists saved blocks; it does not provide their full authoring workflow. Browser actions supply that step. Generated pages and library copies do not continuously track future edits to their source master.

Verification and recovery

Run the offer, widget and project-automation tests, then the full test suite and both strict documentation builds. Controlled page rendering remains necessary because mocked generation cannot prove Qwilr will render the full composition. Use preview acceptance for repeatable development checks, retaining sanitised fixtures for offline replay. Preview evidence must not activate Services, bill customers or advance Deal stages.

If rollout fails, restore the matched backend/widget release and previous category mapping. Pause new-category entry before reverting to a backend that cannot resolve those values; do not delete or bulk-rewrite Deals. Preserve generated page IDs, quoted snapshots and old blocks. Resolve any pending Qwilr request by inspecting its page before retrying. Never use page creation as a recovery for an uncertain update. Before reverting a draft's design, check its current Qwilr status: accepted or published content must not be silently rebuilt.