Release 2603

🚀 release 2603 is now live in sandbox 🗓️ production deployment is scheduled for april 20, 2026 this release introduces powerful new capabilities across pricing, billing, and developer experience — including pricing engine plugins for custom javascript based pricing logic, in memory invoice previews via a new commerce api endpoint, and a customer scoped product catalog endpoint additional enhancements include filtered quote template selection for pdfs and e signatures, automated salesforce credential wiring, tax calculation on credit memos for refunds and write offs, and a subscription version guard to prevent stale data in change orders the release also addresses a wide range of bug fixes spanning the quote line editor, billing accuracy, docusign integration, netsuite sync, and pdf generation feature enhancements nue ai automate complex pricing with pricing engine plugins using price builder chatbot pricing engine plugins let you tailor nue’s pricing engine to match how your business actually prices deals — without custom development or system workarounds what you can do automatically apply volume or deal level discounts based on total quantity or contract value enforce pricing guardrails like caps, floors, or rounding rules customize subscription ramps to match billing or contract structures apply context aware discounts based on bundles, add ons, or customer attributes standardize pricing logic across quotes, orders, and renewals why it matters pricing engine plugins give revenue teams control over complex pricing scenarios, reduce manual work for sales reps, and ensure every deal follows your pricing strategy — all while keeping the core system simple and scalable ✨ pricing engine plugin interfaces for change quotes and orders are coming soon! learn more how it works define custom pricing logic using lightweight javascript plugins store and manage them directly in salesforce (pricingplugin c) turn them on instantly — no deployments or engineering support required run consistently everywhere pricing happens in the line editor during deal creation through apis and backend processes during renewals and change orders built in extension points beforecalculation — apply business rules before pricing runs afterrampgeneration — reshape subscription ramps aftercalculation — enforce final pricing rules and overrides create plugins with ai use the price builder chatbot to generate pricing logic using natural language quickly turn business requirements into working plugins without writing code available in both sandbox and production for more details, check out docid\ sfevbc77ak6u2zaj4ghpx lifecycle manager select filtered quote templates for pdf generation and e signature sales reps can now see and choose only the quote templates that are valid for a specific quote when generating a quote pdf or sending that quote for e signature this is powered by a new plugin, templateselectionplugin , which lets admins or developers register custom logic that receives the quote id and the published template list, then returns only the templates that should be available for that quote why it matters prevent reps from selecting the wrong document, such as a non reseller template for a reseller quote, reducing customer facing errors and rework speed up quoting and signature workflows by removing irrelevant template choices and preselecting the right default template for the quote context support customer specific template governance without requiring nue to hardcode every business rule, making it easier to scale template control across reseller, region, product family, quote type, and similar scenarios learn more customer use case use case 1 a sales rep is creating a reseller quote and needs to send an order form for signature before this enhancement, they could see both reseller and non reseller templates, which created confusion and increased the risk of sending the wrong legal document with template filtering in place, the system evaluates the quote and shows only the reseller approved templates, so the rep can confidently generate the pdf and start the docusign flow with the correct document options use case 2 a revops or admin team wants different template options to appear based on quote context, such as customer segment, region, product family, or quote type instead of asking nue to add one off product logic for each variation, they register a templateselectionplugin that returns the approved template list for each quote sales reps still get some flexibility, but only within the curated set that matches the business rules for that deal use case 3 a company enables the setting to use only the default quote pdf or template for sending documents for e signature in this case, the plugin does more than filter options it can also determine which template should default for the quote that means the rep does not have to manually interpret which version to use, and the e sign process consistently starts from the approved default returned by the plugin how it works admins or developers register a templateselectionplugin in salesforce under nue system settings when a rep generates a quote pdf or selects a template during the e sign flow, nue passes the quoteid and all published templates into the plugin the plugin returns only the templates that should be available for that quote, and the ui shows only those returned templates automate salesforce credential wiring in “connect to salesforce” flow when an admin clicks “connect to salesforce” (or “reconnect to salesforce”) in nue, the platform now automatically configures all required salesforce side credentials for salesforce→nue callouts specifically, nue detects the correct named credential and external credential pair for the target nue environment (production and sandbox) injects the tenant’s nue api key into salesforce’s external credential principal using salesforce’s connect rest named credential endpoint, with the exact apikey parameter name expected by the managed package header formula grants the proper external credential principal access entry on the nuerequiredpermissions nuerequiredpermissions permission set updates salesforce system settings so apex callouts route through the correct api key–based named credential rather than the legacy password based one, and ensures reconnects overwrite stale keys instead of failing silently this removes the need for admins to manually copy api keys into salesforce setup, hand edit external credentials, or wire permission sets after clicking “connect to salesforce ” why it matters admins no longer spend 10 30 minutes per environment manually creating or updating external credentials, pasting api keys, and fixing permission sets after each connect or sandbox refresh; the entire wiring now runs automatically as part of the connect to salesforce flow salesforce callouts to nue become reliably “click and work” instead of failing due to subtle misconfiguration (wrong apikey casing, stale keys on reconnect, or named credentials still pointing at legacy password based endpoints), which in turn reduces integration outages and support escalations the connection experience for sandboxes and production is consistent and future proof it lines up with our automated sandbox management flows and external client app (eca) migration, so customers can safely refresh sandboxes, rotate keys, or move to spring ’26+ orgs without additional manual credential work mark specific fields as read only on individual line items using ui plugin control which fields users can edit directly in the line editor by marking specific fields as read only through plugins this enables more guided workflows for example, locking contract dates while still allowing pricing adjustments by using a ui plugin, you can lock specific fields (e g , subscription dates or terms) on individual line items keep other fields (like price) editable for flexibility enforce consistency for system controlled values while allowing sales input where needed how it works use $$updatedlineitems\[] readonlyfields in your plugin to define which fields should be non editable for each line item example ramp lines have dates locked but totalprice editable // plugin sets read only fields $$updatedlineitems push({ id ramplineitem id, readonlyfields \[ "subscriptionstartdate", "subscriptionenddate", "subscriptionterm" ] }); // result dates are greyed out, totalprice remains editable why it matters this gives teams precise control over the editing experience reducing errors, enforcing business rules, and ensuring critical fields stay consistent while still enabling flexible deal adjustments everything billing enable tax calculation on credit memos for refunds and write‑offs when a finance user generates a credit memo against a taxed invoice—either as a refund (credit back type) or a write‑off—nue now automatically calculates the tax on the credit memo based on the tax from the original invoice this extends the existing “credit memo over invoice” tax calculation so that all downstream credit memo types stay aligned with the invoice’s tax configuration and effective tax rate why it matters ensures end‑to‑end tax accuracy and reconciliation across invoice → credit memos (standard, refund, write‑off) reduces manual tax work for finance teams by automatically deriving credit memo tax from the original invoice’s base/tax/total, even for multiple partial refunds or write‑offs, so users no longer need to do off‑system tax splits or overrides learn more customer use case use case 1 a finance manager at a saas company issues several partial refunds over time against a single taxed invoice that was originally billed with avalara each time a customer asks for a partial refund, the system generates a creditback credit memo tied to the payment and the invoice with this feature, the manager can trust that every refund credit memo automatically inherits the same tax ratio as the original invoice line and splits base and tax correctly for each refund amount after three separate refunds, the sum of all credit memos’ base, tax, and total matches the original invoiced base and tax exactly use case 2 a collections specialist is cleaning up aged receivables and decides to write off the remaining balance of a partially paid, taxed invoice they trigger a write‑off flow that generates a write‑off type credit memo against that invoice instead of guessing the tax or manually calculating the taxable and non‑taxable portions, nue automatically computes the write‑off credit memo’s base and tax from the invoice’s original tax amounts and the remaining outstanding balance when the specialist posts the write‑off, the gl and the tax engine both see an accurate, explainable write‑off of revenue and tax, keeping audit trails clean dependencies and limitations the invoice must have non‑zero tax for automatic tax calculation on the related credit memos; if the invoice tax is zero, these credit memos will not calculate tax and will behave as non‑taxed credits by design developer experience enable auto republish on save for price tags and product relationships this release extends the existing self service setting “automatically republish products when saved” so that it now also applies to price tags and product relationships when the setting is enabled, any time an admin saves changes to a published product, price tag, or product relationship, nue automatically republishes that object to the mirror cache used by self service and ai—no manual publish step required why it matters keeps self service storefronts and ai experiences in sync with the latest catalog, pricing, and upgrade/downgrade/swap rules, reducing the risk of showing stale offers or incorrect discounts to end customers eliminates manual “remember to republish” tasks for admins whenever they tweak price tags or product relationships, lowering operational overhead and configuration mistakes in complex catalogs enable in memory invoice preview for initial and change orders via commerce api's nue now provides a single rest endpoint, post /orders/invoice preview, that generates invoice previews entirely in memory for both initial orders and change orders without creating any draft orders, change orders, or other database records when the request body includes orderproducts, the endpoint runs the full initial order pipeline (product resolution, pricing, billing settings, invoice generation) in memory and returns previewinvoices for a new order when the request body includes assetchanges (optionally with products for cross sell), the endpoint runs the change order preview pipeline and returns previews showing the invoice impact of subscription changes such as updatequantity, cancel, updateterm, and renew the endpoint enforces that the request contains either orderproducts or assetchanges, but not both, and performs full validation and billing parity checks against the existing post /orders and post /orders/change orders invoice preview flows why it matters reduce data noise and cleanup work in downstream systems by eliminating the need to create draft orders or change orders just to preview invoices; the new endpoint performs zero database writes while producing the same invoice results as draft creation accelerate self service quoting and checkout experiences by giving developers a single, consistent api to preview both new business and change order invoices, simplifying integrations and reducing conditional logic in client code learn more customer use case use case 1 a saas provider wants to build a “review charges” step in their self service checkout flow when a buyer configures 3 different recurring products and a set of add ons, the front end sends those orderproducts to post /orders/invoice preview the api returns previewinvoices that show the exact monthly charge, billing dates, and line item breakdown without creating any draft order in nue the provider can safely let the buyer iterate on configuration and pricing as many times as they want, and only create the real order once the buyer clicks “place order” use case 2 a customer success team uses an internal “what if” tool to model mid term subscription changes when they simulate an updatequantity or updateterm on an existing subscription, the tool calls post /orders/invoice preview with assetchanges the api returns previews that show incremental charges, credits, and effective dates for the change order path, matching what would happen if a real change order were created, while leaving the production subscriptions untouched how it works developers call post /orders/invoice preview with either orderproducts (for initial orders) or assetchanges (for change orders) for initial orders, the endpoint converts the request into an internal create order request, resolves products, billing settings, and pricing in memory, generates invoices via the existing billing engine, and returns them in previewinvoices while skipping all persistence and event publishing steps for change orders, the endpoint converts the request into a change order request, initializes the existing orderchangepreviewengine, computes subscription changes and associated invoice previews in memory (including combinations like updatequantity, cancel, renew, and cross sell with products), and returns the result in the previews field the implementation is guarded by a read only transaction and is explicitly verified to perform zero database writes by comparing order counts before and after preview calls; amounts are also validated to match those from post /orders and post /change orders across recurring, one time, bundle, high quantity, proration, and billing period override scenarios dependencies and limitations tenants must have a self service license and products published for this endpoint to work tax is not provided as part of the invoice preview, and will only be available for a draft order related resources check out https //api docs nue io/invoice preview article for detailed information about this feature fetch customer‑scoped product catalog this release adds a new endpoint, get /customers/\ customerid/products, that returns your published product catalog automatically filtered to only the pricebookentries (pbes) that are eligible for a specific customer based on their account‑level pricing attributes products with no matching pbes are excluded, and the response shape matches the existing get /catalog/products endpoint so existing client parsers continue to work unchanged why it matters reduce integration effort for headless and api‑first customers by replacing 4–5 separate api calls and custom pbe‑filtering logic with a single call that returns “what this customer can buy, at the right price,” mirroring what nue would show if a sales rep opened a quote for that account enable in‑product upsell, cross‑sell, and customer‑facing checkout flows to show only eligible, correctly priced products and bundle options for the signed‑in customer, improving conversion and avoiding mispriced offers learn more customer use case use case 1 a headless plg customer is building an in‑product upsell experience on their account dashboard when a user signs in, they wants to show a “what you can upgrade to” section that only lists products and add‑ons that are actually sellable to that customer, based on their account type and other pricing attributes today, their team must fetch the full catalog, look up the account, replicate nue’s pricing attribute mappings, and write custom filtering logic to decide which pbes apply with the new get /customers/\ customerid/products endpoint, they pass the customer id once and receive a already‑filtered catalog that only includes eligible products and pbes, so the ui can safely render upgrade options without duplicating pricing logic use case 2 a developer building a customer‑facing checkout needs to let end users pick products by sku and quantity without exposing or managing internal pbe ids previously, they had to query /catalog/products, fetch account details, manually filter pbes by account type and other attributes, and then pass a resolved pbe id into the order api now they can first call get /customers/\ customerid/products to obtain a catalog that already reflects the customer’s account‑level pricing attributes, then drive the checkout ui from those scoped products how it works the client calls get /customers/\ customerid/products; the customerid identifies the customer whose catalog eligibility should be evaluated for each product’s pricebookentries, the service evaluates each pricing attribute’s mapping (for example, quote accountid type) against the customer’s account fields, treating any and empty pricing‑attribute sets as always eligible, and includes only pbes where all account‑level conditions match products whose pbes are all filtered out are removed from the response, and bundle product options are filtered using the same rules, so bundle configurations only surface options that are valid for that customer dependencies and limitations the tenant must have products and pbes published into the self‑service catalog (via the existing catalog publish pipeline) so that /catalog/products returns the full product list to be scoped if products have been previously published, customers will have to republish all products for the endpoint to provide accurate information only account/customer‑level pricing attributes are considered at catalog time; quote‑ or order‑level attributes (for example, order header custom fields) are not applied related resources check out https //api docs nue io/fetching customer products article for detailed information about this feature enforce subscription version guard for change orders this feature adds a subscription “version guard” between nue and salesforce so that change quotes and change orders in lifecycle manager cannot be saved or activated against stale subscription data created by self service changes that have not yet synced when self service is enabled for a tenant, nue automatically enables a stale data prevention setting and keeps salesforce in sync, so revops teams are protected by default from dirty data in downstream billing and reporting configure pending sync status in salesforce for orders the pending sync order status is not deployed automatically by the nue managed package self service customers must manually activate a new picklist value pending sync to order → status in salesforce setup (category draft) this value is required for the subscription version guard to quarantine orders while version checks run why it matters protects revenue and billing accuracy by blocking change quotes and orders that are based on outdated subscription versions when customers have already changed their subscription in self service, eliminating incorrect invoices and revenue leakage from conflicting changes across channels improves customer experience by ensuring salesforce always reflects the same subscription state the customer sees in the self service portal, avoiding confusion when a rep sells on top of an “old” version of the subscription that the customer thinks they already changed or cancelled reduces operations and support overhead by preventing dirty data up front—stale changes are blocked at save, suspect orders are quarantined in a pending sync/error state, and the system auto corrects salesforce subscription versions, cutting down on manual cleanup, back billing, and support tickets learn more customer use case use case 1 a sales rep at a saas company opens lifecycle manager in salesforce to upsell more seats on an existing subscription that the customer has already upgraded through the self service portal earlier that morning because the nue→salesforce sync has not finished, the salesforce subscription still shows the old quantity when the rep clicks save in the line editor, the version guard compares the salesforce subscription version with the nue platform version, detects that the nue version is higher, and blocks the save with a clear “subscription data may be stale” error the rep is prevented from creating an incorrect change order, waits for sync to complete, and then successfully resubmits once salesforce has the latest version use case 2 a sales rep closes an opportunity as closed won using a change quote that was created days earlier, before the customer cancelled the subscription via self service between quote creation and closing the deal, self service generated a new subscription version in nue that has not yet synced to salesforce when the opportunity is closed, an order is created but the version guard intercepts activation and moves the order to pending sync while an asynchronous job calls nue to reconcile versions the job finds that salesforce is behind, updates the salesforce subscription version to match nue, and leaves the order in an error/pending sync state revops can then choose the correct next action, and the stale order never activates with bad data how it works when self service is enabled for a tenant, nue automatically sets preventstaledatachanges = true in tenant configuration and syncs this to the tenant’s salesforce org by creating or updating a systemsetting c record named preventstaledatachanges on line editor saves for change quotes and change orders (quick save or save and exit), salesforce calls a new validator that identifies nue‑managed subscriptions on the change lines, calls nue’s orders service via graphql to fetch current subscription versions, and blocks the save with a stale subscription data error if any salesforce subscription version is behind nue’s version (fail‑closed behavior) on activation (activate button, express checkout “as active orders”, cpq apis, or close‑won opportunity), an ordermanager trigger checks whether the order contains nue‑managed subscription changes and, when protection is enabled, moves the order to a pending sync status and enqueues a validation; that job compares versions against nue, automatically activates the order if versions match, or keeps the order in a quarantined state while updating salesforce subscription versions if a mismatch is found dependencies and limitations self service must be enabled for the tenant and the selfserviceuser license must be configured so that nue can publish tenant license changed events; this is what drives preventstaledatachanges to true in salesforce and turns on the guard for that tenant customers must add a new pending sync picklist value to the standard salesforce order status field (draft category) so that orders intercepted by the activation guard have a dedicated status to land in while the async validation job runs and while revops investigates related resources check out docid\ goewmdsoxpchsjenz4bss article for detailed information about this feature bug fixes below is a summary of key issues addressed in this release, along with more detailed explanations of what was happening and how the fixes improve reliability and usability lifecycle manager faster loading experience in quote line editor for large change orders what was the issue? the quote line editor could take noticeably long to load for quotes and change orders with a large number of line items, complex bundles, or multiple historical changes this slowed down everyday workflows for sales and operations teams what we fixed and why it matters we optimized queries, reduced unnecessary recalculations on initial load, and tuned client side rendering for large datasets the line editor now opens more quickly and remains responsive, even for complex scenarios, enabling users to work through change orders without performance related interruptions renewal + upgrade change orders handle date logic correctly what was the issue? when combining renewal and upgrade actions in a single change order, misaligned effective dates could cause validation errors or incorrect term calculations users sometimes had to split changes into multiple orders to avoid conflicts what we fixed and why it matters we clarified and enforced a consistent model for how renewal and upgrade dates interact, including validation rules that prevent invalid combinations and accurately derive new term boundaries complex “renew + grow” scenarios now work in a single flow, reducing rework and preserving a clear audit trail billing account and tax information carry over correctly what was the issue? in some change orders, the billing account and associated tax settings were not consistently copied from the original order or subscription this risked incorrect taxation or billing against an unintended account what we fixed and why it matters we strengthened field mapping for billing account and tax attributes so that they are preserved across change orders unless intentionally overridden this maintains tax correctness and billing continuity while still allowing administrators to change billing ownership when needed renewal + swap change orders handle dates correctly what was the issue? in renew + swap scenarios (renewing a subscription while replacing one product with another), misaligned dates between the old and new products could cause errors or unexpected proration what we fixed and why it matters we refined how effective dates are validated and aligned during swaps as part of renewal old and new products now share a consistent term boundary, and proration behaves predictably this allows teams to restructure product mixes at renewal time without surprises in billing or term length quantity tier attributes configuration changes no longer impact active orders unexpectedly what was the issue? adjusting certain quote to activate (qta) configuration or metadata could inadvertently affect active orders, leading to confusion about which settings applied at the time of activation versus post activation what we fixed and why it matters we separated configuration that applies at quote/activation time from the data persisted with active orders updates to qta settings now influence future activations without retroactively altering existing active orders, preserving historical accuracy and preventing unexpected behavior in live subscriptions partner percentages carried through in change orders what was the issue? when creating change orders, partner revenue share / payout percentages were not always propagated correctly from the original subscription or quote this could lead to manual recalculation or incorrect payouts what we fixed and why it matters we ensured that partner related fields (such as partner percentages or tiers) are consistently copied and respected in change orders, including downstream pricing and reporting this improves trust in partner compensation calculations and reduces the need for manual reconciliations change quotes now work cleanly with partner payout logic what was the issue? certain change quote flows were incompatible with partner payout logic, causing conflicts when both complex subscription changes and partner attribution were involved what we fixed and why it matters we aligned the change order data model with partner payout rules so that partner information remains intact and correctly interpreted across the lifecycle teams can now manage complex changes on partner involved deals without losing payout visibility or accuracy createquote global method no longer returns internal error what was the issue? calls to the createquote global method could intermittently fail with a generic internal error, even when the input data looked valid with dynamic product options involved in bundle products this made it difficult for integrators to rely on the method for automation what we fixed and why it matters we improved input validation, defaulting, and error reporting within the global method invalid calls now return clear validation messages, and valid calls complete reliably this makes it safer to build custom automations, flows, and triggers that depend on programmatic quote creation create quote api correctly resolves total committed amount what was the issue? the create quote api occasionally failed to populate or correctly calculate the total committed amount field, especially in cases with complex term structures or multiple revenue components what we fixed and why it matters we updated the calculation pipeline to consistently factor in quantity, term, discounts, and pricing model when computing total committed amount this value is now reliable for approvals, forecasts, and downstream analytics, reducing the need for manual recalculations in reports manage existing subscriptions respects custom fields what was the issue? when using manage existing subs , some configured custom fields on subscriptions or line items were not surfaced or preserved correctly in the line editor this limited the usefulness of custom metadata during change operations what we fixed and why it matters we synchronized the custom field mappings so that relevant custom fields are available and round trip correctly when managing existing subscriptions this allows teams to base changes on their full data model (not just standard fields), improving accuracy and reducing the risk of losing important annotations fixed zero quantity pricing for product options and usage fixed an issue where 0 quantity line items ignored price tag tiers starting at 0 and incorrectly fell back to list price zero quantity lines in line editor and apis now correctly apply configured price tags and discounts , ensuring consistent pricing across ui and api clearer error messaging when closing opportunities having primary quotes with no quote line items what was the issue? a cryptic trigger error could appear when closing opportunities in salesforce, without clearly indicating which configuration or data caused the problem this made it hard for admins or users to resolve the issue without support what we fixed and why it matters we improved validation and error messaging so that failures to close opportunities now specify which record or configuration needs attention (for example, missing required mappings or inconsistent subscription state) this shortens troubleshooting time and reduces dependency on engineering or support product configuration page reliably loads bundles what was the issue? the product configuration page could fail to load when users opened bundles with a large number of options or complex relationships, resulting in an error screen instead of the configuration ui what we fixed and why it matters we optimized how bundle metadata and line items are queried and rendered large and complex bundles now load consistently, allowing users to configure and adjust bundles at scale without encountering unexpected errors renewal uplift now carries over to auto renewals what was the issue? configured renewal uplift percentages or amounts were not always propagated to auto renewed subscriptions this could result in renewals being booked without the intended uplift, requiring manual corrections what we fixed and why it matters we adjusted the renewal logic so that uplift settings are applied consistently to automatically renewed terms, subject to your configured rules this ensures renewal pricing behaves as expected and that uplift driven revenue is captured without extra manual steps quantity tier attributes defaults when mapped field is null now behave safely what was the issue? when a field mapped into qta (quote to activate) logic was null , the system sometimes defaulted to using actual quantity in a way that could surprise users, affecting pricing and activation outcomes what we fixed and why it matters we introduced safer defaulting and clearer rules for handling null mapped values in qta the system will now either fall back to a predictable, documented default or surface a validation warning, rather than silently switching to actual quantity this reduces unintended quantity changes and preserves pricing expectations arr rollups calculated correctly for parent accounts what was the issue? in account hierarchies, parent accounts did not always show the correct aggregated recurring revenue (arr) derived from their child accounts this limited the usefulness of rollup views for enterprise customers what we fixed and why it matters we improved the aggregation logic to ensure all eligible child subscriptions roll correctly into their parent account’s arr this provides more accurate portfolio level views and supports better reporting for multi entity or multi division customers custom report types fully usable beyond development status what was the issue? some custom report types remained effectively stuck in a development or partial state and were not available for general use, even after configuration was complete what we fixed and why it matters we resolved the status synchronization so that once custom report types meet the necessary criteria, they can be used in standard reporting flows this unlocks your configured reports and reduces reliance on ad hoc exports or external tools grandfather tiers respected in manage existing subscriptions what was the issue? grandfathered pricing tiers for example, legacy discounts or locked in rate plans were not always preserved when updating subscriptions via manage existing subs , risking unintentional price changes for long standing customers what we fixed and why it matters we reinforced the logic around grandfathering so that when a subscription is flagged as grandfathered, its tier and associated pricing are maintained through permissible changes this protects negotiated legacy pricing and reduces the risk of billing surprises for existing customers large bundles no longer hit ui limits in product bundles what was the issue? very large bundles (with hundreds of quote line items) could hit ui or platform limits, resulting in an aura or generic error when adding or editing the bundle what we fixed and why it matters we streamlined how large bundles are constructed and saved to stay within platform constraints while still capturing all line items teams can now manage large, complex bundles without encountering blocking ui errors service milestones persist correctly on save & exit what was the issue? when configuring service milestones on a quote or order, using save & exit could occasionally fail to persist those milestones, leading to missing implementation or delivery details what we fixed and why it matters we adjusted the save pipeline to ensure milestones are saved atomically with the rest of the quote or order, including partial edits milestones now reliably persist, which improves coordination between sales, services, and customer success teams change order pricing applied correctly via manage existing subscriptions what was the issue? change orders initiated via manage existing subscriptions did not always apply the same pricing behaviors and adjustments as those initiated from other entry points (e g , direct quote flows) this could lead to differences in discounts or net prices what we fixed and why it matters we unified the pricing pipeline so that changes initiated from manage existing subs go through the same evaluation and calculation logic as other flows this ensures consistent pricing regardless of where a change is initiated, reducing confusion and the need to cross check multiple flows bundle product option screen no longer shows blank what was the issue? the bundle product option screen could load as a blank page in certain configurations, preventing users from adding or modifying options for a bundle what we fixed and why it matters we fixed the ui initialization path and error handling for the bundle options view the screen now consistently loads with the correct options, even when bundles are complex or metadata is large this restores a smooth configuration experience for sales and operations users everything billing invoices no longer incorrectly marked as paid what was the issue? in specific edge cases, invoices were being set to a paid status even though no corresponding payment had been recorded this could happen when downstream updates or sync events incorrectly interpreted certain state transitions as “payment complete ” what we fixed and why it matters we hardened the validation logic around invoice state changes so that an invoice can only move to paid when a valid payment record is linked and reconciled this prevents false positives in your a/r, keeps dashboards and reports aligned with reality, and reduces the risk of stopping collections activity prematurely correct application of cash pool credits for taxable deposit invoices previously, when a taxable deposit invoice funded a cash type deposit cash pool, the pool was correctly funded only with the pre‑tax subtotal however, when activating a later invoice that burned from this pool, the activation flow attempted to apply credits equal to the full deposit invoice total (subtotal plus tax), instead of capping at the true pool balance (the pre‑tax amount) this caused the system to try to draw more credit than was actually available in individual credits and led to activation failures with errors like “the credit … doesn’t have enough balance,” sometimes without a clear message in the ui with this fix, nue now correctly treats only the pre‑tax subtotal of the deposit invoice as reusable cash credit in the deposit cash pool when activating a consuming invoice, the system caps the automatically applied credits at the true pool balance (the pre‑tax amount), rather than using the original deposit total (charges plus tax) order resync from salesforce no longer fails with server errors what was the issue? when attempting to resync orders from salesforce into nue, some orders failed with a 500 internal server error this typically occurred when an order contained missing or inconsistent data that the sync pipeline didn’t handle gracefully what we fixed and why it matters we improved validation, error handling, and defaulting in the order resync pipeline orders with unusual but valid configurations are now accepted, and invalid records fail with clear, actionable validation errors rather than generic 500s this ensures salesforce and nue stay in sync, which is critical for downstream billing, revenue recognition, and reporting usage at subscription end date now rates successfully what was the issue? usage records that occurred on or near the subscription end date could fail to rate, leaving the final period of usage unbilled or requiring manual clean up this was most visible for subscriptions with tight end dates and daily/hourly usage windows what we fixed and why it matters we refined the time window and term boundary logic in the rating engine so that usage on the last day (or last window) of a subscription is included correctly this ensures complete coverage of the subscription term in both rating and invoicing, avoiding under billing and reconciliation gaps at the end of term usage rating for renewed bundle overages no longer errors what was the issue? when a bundle was renewed and then generated overage usage, rating those overages could fail with an internal error this typically occurred when the renewal created a new term but the overage pricing logic still referenced the prior term’s configuration what we fixed and why it matters we updated the renewal and rating logic to consistently bind overage usage to the correct subscription term and bundle configuration overages for renewed bundles now rate successfully, so you can bill accurately for post renewal consumption without manual interventions or custom workarounds docusign integration declined docusign envelopes can be resent what was the issue? once a docusign envelope was declined , the integration treated it as terminal, and users could not re send the same document from within the integration teams had to create a brand new envelope, reattach documents, and reconfigure recipients what we fixed and why it matters we adjusted the docusign status handling to allow re send flows for declined envelopes where appropriate users can now correct issues (e g , recipient email, terms) and re initiate the signing process without rebuilding the envelope from scratch this shortens contract cycles and reduces operational friction for sales and legal teams improved date and currency formatting in generated documents what was the issue? in some generated quote and contract documents, dates and currency values were formatted inconsistently (for example, mixing mm/dd/yyyy and dd/mm/yyyy, or omitting currency symbols/iso codes) this could cause confusion for customers and internal reviewers, especially in multi region deployments what we fixed and why it matters we standardized how date and currency formats are derived based on tenant and locale configuration, and ensured that templates consistently use those formats generated pdfs and documents now present dates and monetary values clearly and predictably, improving professionalism and reducing ambiguity in customer facing materials netsuite integration “buy now from quote” orders now sync to netsuite previously, self service orders created via “buy now from quote” could fail during invoice generation because a required internal “ischange” flag was not being carried from quote line items to the resulting order products with this fix, invoices now generate successfully for self service orders created from quotes, and the “ischange” flag is correctly populated on order products, ensuring smoother downstream billing and netsuite sync flows self service orders now complete successfully at invoicing what was the issue? for certain self service orders, the integration failed at the invoice creation step in netsuite while orders were created, the invoicing handoff could encounter validation issues that surfaced only as a generic error, leaving the order stuck without a corresponding invoice what we fixed and why it matters we aligned field mappings, required values, and error handling between nue and netsuite for self service invoice creation the flow now validates inputs earlier, applies sensible defaults where allowed, and surfaces clear messages when data is incomplete this results in a reliable end to end path from self service checkout to invoice in netsuite multi currency invoices include full currency information what was the issue? some multi currency invoices sent to netsuite were missing the currencyisocode or related currency metadata while the amounts were correct, the absence of explicit currency information could cause reporting issues or require manual editing what we fixed and why it matters we updated the integration to always populate required currency fields based on the invoice and account configuration all multi currency invoices now carry consistent and explicit currency data, improving financial reporting, consolidations, and audit readiness across systems nue platform – template builder / pdf quote pdf formatting now matches on screen preview what was the issue? in some cases, the generated pdf did not exactly match the on screen preview of the quote—things like spacing, line wrapping, or section breaks could differ what we fixed and why it matters we aligned the rendering rules and styles used for the preview and the final pdf output what you see in the preview is now a faithful representation of what customers will receive, which reduces the need for test exports and manual visual checks conditional filters on quote pdf work as expected what was the issue? conditional filters in quote templates (e g , “show this section only when a certain field is set”) were not always honored, causing some sections or line items to appear or disappear unexpectedly what we fixed and why it matters we corrected the evaluation of conditional expressions during pdf generation so that template conditions behave deterministically this allows admins to design templates that only show the right content for each scenario, keeping customer documents clean and relevant