Release 2603.1

🚀 release 2603 1 is now live in sandbox ! 🗓️ production deployment is scheduled for april 29, 2026 this release enhances quoting and lifecycle management with smarter automation e signature recipients are now scoped to individual quotes to prevent misrouting, partner payout columns auto reveal when a payout percentage is entered, and bundle true ups can now be applied to all add on children in a single action on the developer side, teams can now configure failure notification webhooks for salesforce syncs and run pricing plugins on self service orders for consistent pricing across all channels several bugs were also resolved, including fixes for percent of total pricing on mid term amendments, grandfathered tier preservation across renewals, and performance improvements for large nested bundle reconfiguration feature enhancements lifecycle manager default e signature recipient matching for quotes when an account has multiple open opportunities and quotes, it can be confusing which docusign recipient should be used for each quote this update makes recipient selection quote aware, so the right person is auto populated for the right quote, reducing mistakes when sending for e signature why it matters prevents misrouting of docusign envelopes when multiple opportunities and quotes are open for the same account by ensuring recipients can be scoped to an individual quote instead of only to an account or globally reduces seller confusion and user error in high‑volume environments by automatically pre‑selecting the most relevant recipient per quote based on explicit quote/account/global scoping rules improves revops governance and reporting over who is configured to sign which quote by storing an explicit quote lookup on the recipient record, enabling better audits and safer automation around default signers learn more customer use case use case 1 a sales rep is working on two active opportunities for the same enterprise customer, each with its own quote and different business unit signers historically, when they opened the “send for e‑signature” flow on the second quote, the system could auto‑populate the recipient from the first quote because both recipients were only tied to the shared account with this enhancement, revops creates recipients that point directly to each quote now, when the rep sends quote q1, only q1‑scoped recipients appear and auto‑populate when they send quote q2, only q2‑scoped recipients are used the rep no longer has to double‑check which signer is loaded, and the risk of sending the wrong order form to the wrong business unit is eliminated use case 2 a global sales team sells to a parent company where different subsidiaries sign their own contracts, but all roll up to a single salesforce account for one quote, the signer is a legal director; for another, it is a regional finance lead revops maintains a small library of recipient records some scoped at the account level for shared internal approvers, and others scoped directly at the quote level for external signers when reps launch the e‑signature flow, the system first checks for quote‑scoped recipients, then account‑scoped ones, then finally any global routing inbox recipients this ensures the right legal or finance contact is always suggested first, while still allowing shared internal approvers to be reused across quotes how it works ruby recipient c gains a new lookup field ruby quote c that links a recipient to a specific quote when opening “send for e‑signature” on a quote, the recipient picker filters recipients into three scopes quote‑scoped (ruby quote c = current quote), account‑scoped (ruby account c = quote’s account), and global (no account and no quote), showing only what is relevant for that quote and account auto‑default selection follows a strict priority and tiebreaker quote‑linked recipients are chosen first, then account‑linked, then global; within any one level, the most recently modified recipient record is chosen as the default for non‑signer roles like “needs to view” and “receives a copy,” the same account/quote/global scoping and filtering logic is applied so that view/copy recipients do not leak across quotes or accounts and remain consistent with signer defaults disable the default template checkbox when generating quote pdfs this feature adds an admin setting that controls whether sales reps see the checkbox “set the selected template as the default for this quote” in the generate quote pdf modal when disabled, the checkbox is hidden and generating a pdf no longer updates the quote’s default template; when enabled (default), the current behavior is preserved why it matters reduce confusion for reps in flows with only one allowed quote template by removing a control with no meaningful choices that often raises questions prevent accidental changes to a quote’s default template, which can lead to mismatched previews and final pdfs in later steps, and downstream errors in e signature flows that rely on the default template id learn more customer use case use case 1 business uses a single approved quote template for all orders when reps open the generate quote pdf modal, they see the checkbox “set the selected template as the default for this quote”, even though there is only one template to choose from admins disable the new setting so that this checkbox is removed from the modal reps can simply click generate pdf without making a confusing “default” choice they don’t actually have, and template governance remains fully admin controlled use case 2 a revops admin notices that some enterprise reps have been checking the default template checkbox on the quote pdf modal without understanding that it changes the quote’s default template id later, when others preview or regenerate pdfs, they get the “wrong looking” layout the admin disables the new setting from that point on, generating pdfs no longer changes the default template; only centrally configured rules determine which template is used by default, reducing noisy support issues enable true up to quantity tiers for bundle add‑ons this feature will be available in the production release slated for 04/29/2026 this release adds full support for “true up” pricing on bundle subscriptions so that when an account’s quantity tier attribute moves to a new tier, you can true up the bundle parent and all add‑on children in a single action in lifecycle manager, the adjust price dialog for bundle subscriptions now shows an apply to all add‑ons apply to all add‑ons checkbox when you choose the true up option when checked, nue automatically recalculates the correct quantity tier based price for every child subscription in the bundle, not just the parent each child independently resolves to its own correct quantity tier based on its configured quantity tier attribute and price tag setup in terms of apex global methods, globalchangeorderservice and pricing engine now honor a top level applytochildren flag on true up adjust price requests, so a single api call against the parent bundle can true up all children and return nested order or quote line items that reflect the new tier pricing why it matters reduces manual effort and errors when quantity attributes change by allowing aes and csms to true up an entire bundle (parent plus all add‑ons) in one action instead of adjusting each child subscription individually ensures revenue accuracy for usage based pricing models by correctly moving every bundle line to the right quantity tier whenever the underlying attribute crosses a threshold, including during renewals and mid‑term amendments simplifies integration and reporting by generating properly nested change lines for bundle parents and children (both in quotes and orders) from a single api request, which aligns billing artifacts with how customers think about bundles and their add‑ons learn more customer use cases use case 1 a monitoring vendor sells an observability platform observability platform bundle that includes core monitoring plus several add on modules (log analytics, apm, synthetic checks) pricing for the bundle and modules is tiered by the total number of monitored hosts initially, the customer runs 200 hosts and sits in a lower tier as they roll out new services, host count grows to 800, pushing them into a higher tier the ae opens lifecycle manager, clicks adjust price on the bundle subscription, selects the true up option, and checks “apply to all add ons ” nue automatically recalculates the correct quantity tier for the parent and each add on module based on the updated host count and creates a change quote with adjust price lines for all affected subscriptions, without needing to touch each child individually use case 2 a payments platform bundles core processing, fraud protection, and chargeback management pricing is based on annual processed volume tiers defined by a quantity tier attribute that aggregates committed transaction volume on the quote or order mid term, a large merchant increases their committed volume significantly rather than manually repricing each add on, the company’s integration calls ruby globalchangeorderservice changeorder with one globaladjustpricerequest for the bundle parent, setting trueupprice = true and applytochildren = true nue recalculates the correct tier for the bundle and each financial add on based on the new committed volume and generates nested adjust price lines that match the updated commercial agreement use case 3 a data warehouse provider offers a bundle of core storage plus data sharing and governance add ons, all priced on the number of active data workspaces a customer operates over a multi year term, the customer adds more business units and doubles their workspace count at renewal time, the revenue operations team wants to both renew the bundle and true up all charges to the new tier in one step in lifecycle manager, they create a renewal for the bundle and choose adjust price → true up adjust price → true up with apply to all add ons apply to all add ons checked the renewal quote includes renew and adjust price lines for the bundle parent and each add on, with each child’s price recomputed from its own tier table based on the new workspace count, ensuring the renewal reflects the customer’s actual scale auto‑reveal partner payout & net seller columns in line editor this feature will be available in the production release slated for 04/29/2026 this feature automatically shows partner payout partner payout and net seller columns \[net seller total & net seller price] net seller columns \[net seller total & net seller price] in the quote line editor & order line editor when a sales rep enters a non‑zero partner payout % on the header the columns stay hidden when partner payout is not in use, auto‑reveal as soon as partner payout % > 0, and remain visible thereafter, with full support for manual hide/show via the column chooser and persistence across page refreshes why it matters increases quoting and ordering efficiency by eliminating the need for reps to configure columns every time they work with partner deals; the grid and price summary surface partner‑specific metrics exactly when partner payout % is entered, and remain uncluttered when partner payout is not in use improves partner revenue transparency once partner payout % is set, sales, deal desk, and finance can immediately see partner discount %, partner payout amount, net seller total, and net seller price on each line and in the header summary, ensuring deal economics are clear without extra clicks or reports learn more customer use cases use case 1 a sales rep is building a new quote that does not involve a partner they open the quote line editor and see only standard pricing columns (list price, discount, net sales price, total price) partner columns are hidden, so the grid stays focused on the customer price later in the negotiation, the deal becomes a channel opportunity the rep enters a 15% partner payout % at the quote header as soon as they tab out, four new columns partner discount %, partner payout amount, net seller total, and net seller price appear automatically in the grid and the header price summary updates to include partner metrics the rep can now review both the customer‑facing price and what their company will earn after the partner share, without spending time hunting for columns in the configuration dialog use case 2 a deal desk analyst re‑opens an existing quote that was previously saved with a 10% partner payout % when they first load the quote line editor in a fresh browser session, the system detects that the underlying quote already has partner payout % > 0 and immediately shows all four partner columns on first paint the analyst can validate partner payout and net seller values as part of an approval review without any extra setup, and if they refresh the browser or come back later, the partner visibility is preserved based on the saved header percentage rather than fragile per‑browser settings developer experience configure system webhook failure notifications this feature lets you attach an optional failure notification webhook to system generated salesforce sync webhooks (like order activated, subscription updated, customer updated) so that when a sync from nue to salesforce fails after all retries, nue sends a structured failure payload to your own endpoint, allowing you to immediately be notified with the reason for failure the failure notification is configured as a sub webhook under the locked, auto registered salesforce webhook entry, with its own https endpoint, name, and secret headers, and it only fires on terminal failures of that specific sync why it matters when order activated / subscription updated / customer updated syncs to salesforce fail today, nothing is sent to customer endpoints; the only signal is a failed webhook log in transaction hub failure notifications turn each terminal sync failure into an outbound webhook to your systems, so revops and platform teams can see and act on broken syncs in real time you can configure multiple salesforce sync webhooks to share the same failure notification endpoint (and even reuse an existing primary endpoint url), so every failed sync—from orders, customers, or subscriptions—lands in a single ipaas flow, alerting channel, or incident pipeline instead of being buried in transaction hub the failure payload includes both the original business event (e g , order with line items) and the error details from salesforce, and the event log “view failure webhook” modal shows the exact payload and http response that gives teams everything they need to understand why salesforce is missing a record and fix mappings or field constraints before downstream teams are blocked learn more customer use case use case 1 a revops manager relies on the auto registered order activated webhook to create orders in salesforce whenever self service customers activate orders in nue one morning, a salesforce validation rule starts requiring a new field on order, causing the sync to fail previously, the only sign would be failed events in transaction hub and missing orders in salesforce with the failure notification attached to the order activated salesforce webhook, every terminal failure now sends a post to the company’s monitoring endpoint, which opens a ticket tagged “salesforce order sync failed” and posts into a revops slack channel with the original order and salesforce error message the team sees the pattern within minutes and updates the mapping, instead of discovering missing orders days later use case 2 a platform engineering team maintains complex customer provisioning logic that depends on customer updated and subscription updated syncing into salesforce they attach failure notifications to the locked salesforce sync webhooks for those events, all pointing to a single “salesforce sync failures” endpoint in their ipaas when any customer or subscription sync into salesforce fails after retries—because of field level security, missing reference data, or api limits—the ipaas flow fan outs to slack, jira, and a runbook dashboard this central stream of salesforce sync failures lets them prioritize fixes and protect downstream analytics that depend on salesforce being complete how it works auto registered salesforce sync webhooks appear as locked rows in settings → webhook endpoints; each such row shows a bell icon clicking the bell opens an “add failure notification” / “edit failure notification” dialog where you configure a child webhook (name, https endpoint, optional description, and secret headers) after the primary salesforce sync webhook finishes all its retries and is logged as failed, nue checks whether there is an enabled failure notification for that parent if so, it creates a new failure event and sends it through the standard async webhook pipeline, posting a structured failure payload (including original event, error, and metadata) to the configured failure endpoint, and exposing that delivery via a “view failure webhook” button on the failed primary event in the event log dependencies and limitations only failed system webhooks will create an event on the sub webhook succesful system webhooks will silently proceed more details available at webhooks docid z6xbd98qskku1fifbj5y enable pricing plugins for self‑service orders pricing plugin support for self‑service orders lets you run the same salesforce pricing engine plugins on nue’s self‑service apis so that end‑customer flows use the exact same custom pricing logic as sales‑led flows in salesforce salesforce remains the system of record active calculation plugins (ruby pricingplugin c) are automatically synced to nue via a platform‑event pipeline and stored per tenant, then automatically attached to every eligible self‑service pricing call—no plugin payloads or flags are needed in the api request revops and developers can monitor sync status and manually repair issues in settings → self service → pricing plugins, which surfaces all synced plugins, their active state, and whether nue is in sync with salesforce why it matters when you create a pricing plugin, the same pricing plugins you already rely on in salesforce run automatically on self service apis that means your end customer portal, plg flows, and internal tools all return the same prices and discounts your reps see in the line editor—no more channel specific pricing drift or reconciliation work if your current pricing model depends on plugins (grandfathered tiers, volume overrides, partner discounts, custom ramps), you no longer have to block or special case those skus for self service you can send normal post /orders and change order calls, and trust that your existing plugin logic will execute, so you can expand self service coverage without rewriting or duplicating pricing rules learn more customer use case use case 1 you’re a revops manager who already uses pricing engine plugins to implement complex volume based discounts in salesforce previously, sales reps get the correct results in the line editor because your beforecalculation and aftercalculation plugins run there, but your self service checkout (powered by post /orders) has to fall back to simple list based pricing with this feature, you don’t change your plugins at all—you just confirm they show as synced in settings → self service → pricing plugins the next time a customer configures a high volume order in your portal, the same volume discount plugin fires in the pricing engine and your self service response shows the same discounted totals and system discounts your reps see in salesforce use case 2 you own a self service “add seats” experience for existing subscriptions your current change order pricing logic depends on plugins that cap uplifts and adjust ramps, so in salesforce you can confidently quote complex renewals and mid term changes without plugin support, your portal can’t safely call post /change orders, so you either over simplify pricing or send everything through a rep with this feature, you point your front end to the standard change order apis, and the pricing engine automatically loads your synced plugins your “add 10 seats and extend term” flows now return the same uplift and ramp structure that salesforce would, without any custom server side pricing code in your portal how it works you continue to create and maintain pricing plugins in salesforce (ruby pricingplugin c) with the trigger events and plugin types you already use (beforecalculation, aftercalculation, afterrampgeneration; headerobject / lineitem / any) when you save or change a plugin in salesforce, salesforce automatically syncs that plugin to nue, where it’s stored per tenant and kept up to date when you call nue’s self service apis, nue automatically loads your active calculation plugins for that tenant and passes them into the pricing engine—no extra plugin parameters in your api requests the pricing engine then executes your plugins with full context (header object, line items, ramps, pricing attributes), and the prices it returns to your api clients already include whatever adjustments your plugin logic makes dependencies and limitations since plugins are arbitrary javascript, a bug in your plugin (for example, throwing an error or writing non numeric values into price fields) can cause pricing calls to fail with server error you should treat plugin changes as production critical test them in sandbox, use logging (console debug) to diagnose issues, and keep a clear process for disabling or rolling back plugins if needed if a plugin fails to sync from salesforce to nue, pricing can diverge please ensure that you visit the self service tile after creating a new pricing plugin in salesforce to ensure it has successfully synced to nue more details available at pricing engine plugins docid\ sfevbc77ak6u2zaj4ghpx integrations multi subsidiary support for netsuite this feature lets nue route customers, sales orders, invoices, credit memos, and payments to the correct netsuite subsidiary based on nue entity, instead of a single hard coded default subsidiary it introduces an erp subsidiary id on entity, a multi subsidiary toggle and mapping in the netsuite connector so every downstream transaction consistently lands on the right subsidiary in netsuite oneworld why it matters ensure compliant financials for multi entity enterprises, where legal entities across multiple countries must each post revenue and ar to the correct netsuite subsidiary in multiple currencies eliminate misrouted revenue and reversals by keeping the same subsidiary across the full lifecycle — sales order → invoice → credit memo → payment — so each legal entity’s books, ar aging, and tax reporting stay accurate without manual netsuite clean up support “one customer, many entities” scenarios by allowing the same nue customer to place different orders under different entities and subsidiaries, while the connector automatically maintains netsuite’s allowed subsidiaries (subsidiarytab) and prevents invalid mixed entity orders from ever reaching netsuite for further documentation on the setup and use case, please refer to the following documentation https //docs nue io/integration setup#multi subsidiary support for netsuite https //docs nue io/integration setup#multi subsidiary support for netsuite bug fixes lifecycle manager percent of total pricing now works on mid term amendments what was happening before ? when users created a mid term amendment and added only a percent of total (pot) product to an existing bundle (without changing any of the base bundle products), the pot product’s price was not calculated correctly instead of pricing as a percentage of the bundle total, the pot line would either show $0 or a blank price in some paths, or be added at its full list price, ignoring the configured percent of total percent of total relationship this issue did not occur on net new quotes, where percent of total pricing worked as expected it was specific to the add only mid term amendment add only mid term amendment path, where the existing subscription lines are read only and were not being included in the calculation context for pot pricing this behavior blocked key use cases for customers, who rely on accurately pricing add on products as a percentage of an existing bundle’s total during mid term changes what we’ve fixed & why it matters we’ve updated the percent of total calculation logic used during change orders so that sales teams can add percent of total add ons to existing subscriptions mid term and trust that pricing will reflect the correct percentage of the bundle total, without manual workarounds or plugins existing flows where pot was already working (such as net new quotes) continue to behave as expected, with regression coverage in place across change order scenarios customers like vanta can now move forward with launches that depend on mid term percent of total pricing (e g , vantagov), using native nue io functionality instead of custom plugins change order checkout to existing quote fails with internal margin calculation error what was the issue? when users tried to check out a change order against an existing quote, the process sometimes failed with an error related to an internal margin calculation this prevented users from completing certain change orders for affected quotes what we fixed & why it matters we corrected how the system evaluates and queries the internal margin calculation during change order checkout so it no longer triggers errors this makes change order checkout more reliable and ensures users can successfully complete amendments without manual intervention or salesforce admin support product filter now correctly limits options to the active price book for upgrade, downgrade & swap what was the issue? during upgrade, downgrade and swap actions, the product selector did not always properly filter out products that were not part of the same price book this could expose products that were not actually sellable under the customer’s current price book configuration, causing confusion or invalid quote setups what we fixed & why it matters we updated the product filtering logic for upgrade, downgrade and swap actions so that only products in the active price book are shown when users select replacement products this reduces configuration errors, keeps pricing consistent, and ensures sales users only select valid products for each lifecycle action upgrade & swap options missing in lifecycle manager for subscriptions with valid upgrade/swap product relationships what was the issue? for some active subscriptions, valid upgrade products existed but the upgrade options did not appear in lifecycle manager users could not easily process upgrades even though the product relationships were configured correctly what we fixed & why it matters we fixed the logic that determines which upgrade options display for a subscription in lifecycle manager so that all valid upgrade relationships show up as expected this restores the intended upgrade workflow and helps teams execute upsell motions smoothly directly from lifecycle manager changing product status from active to inactive no longer fails due to soql limits what was the issue? when some customers attempted to change a product’s status from active to inactive, the operation failed with a soql limit error this blocked them from retiring products cleanly in environments with larger data volumes or complex relationships what we fixed & why it matters we optimized the queries executed when deactivating products so they stay within salesforce governor limits customers can now safely mark products as inactive without encountering soql errors, improving catalog hygiene and governance at scale grandfathered tier now preserved across subsequent renewals and expansions performed via quote line editor manage existing subscriptions option what was the issue? for customers using grandfathered tiers, the grandfather tier was retained at the first mes renewal, but then lost on subsequent renewals or expansions after the first renewal opportunity was closed this could cause customers to lose their expected grandfathered pricing or tier treatment in later renewals what we fixed & why it matters we corrected the renewal and expansion handling logic so that grandfathered tiers are consistently carried forward across all subsequent mes renewals and expansions, not just the first one this protects existing commercial agreements and ensures customers stay on their promised grandfathered terms over time line bucket ui – specific fields no longer default to selected what was the issue? in the line bucket ui, certain specific fields were incorrectly defaulting to checked in the “ default ” case this made lines appear incorrectly even when users did not intend to label them that way what we fixed & why it matters we changed the default behavior so that those field values are unchecked by default users now have to explicitly check lines corresponding to specific field labels, reducing accidental misclassification and improving reporting accuracy on contract health recalculate on saved quotes with bundles incorrectly shows “reapply price tags” warning what was the issue? when users saved quotes that included bundles with price tags/multi attribute pricing and then clicked recalculate, the system could incorrectly show a “reapply price tags” warning even when no pricing attributes had actually changed this created confusion and often forced users to remove and re add bundles just to proceed what we fixed & why it matters we corrected how the system compares pricing attribute values between the quote/opportunity and the price book entries so that matching values are no longer treated as mismatches this makes recalculate on saved quotes more reliable, eliminates unnecessary “reapply price tags” prompts, and lets users update bundle pricing without disruptive workarounds or admin intervention improved reliability of quote line editor when reconfiguring large, nested bundles what was happening before? when users tried to reconfigure certain large, deeply nested product bundles from the quote line editor, the configurator would sometimes hang indefinitely after clicking reconfigure show an apex error such as “apex heap size too large” or hit cpu time limits never fully load the bundle, leaving reps unable to view or adjust bundle options what we changed? we introduced several optimizations in bundleservice and related apis to reduce resource usage for complex bundles single pass pbe collection pbes are now collected once and reused, instead of being re collected at each nested level, eliminating redundant work and extra in memory lists more efficient recursion the bundle building logic now uses accumulator patterns so that recursive calls share one collection, avoiding intermediate list copies that inflated heap usage smarter dynamic option handling for dynamic options that already apply their own pricing filters, we no longer pre load all pbes into cache only relevant dynamic options that actually use the cache are precomputed early context based filtering (cpu optimization) pricing attribute conditions from the quote/order are now pushed into the pbe queries during bundle tree construction this means we only bring in pbes that match the quote’s context instead of loading thousands and then discarding 99% of them afterward impact of the fix for end users (sales reps and operators working in the quote line editor), this fix delivers reliable reconfiguration of large, nested bundles significant performance improvements on complex bundles greater stability under salesforce governor limits integrations preventing duplicate customers when updating names in netsuite previous behavior when a customer’s name was updated in nue and synced to netsuite, netsuite sometimes created a new customer record instead of updating the existing one, resulting in duplicates and multiple transaction hub records with the same nue id impact customer updates now correctly maintain a single customer record in netsuite, reducing duplicates and confusion in downstream data and reporting single quote customer names now sync correctly to netsuite previously, customers with a single quote in their name (for example, “o'brien” or “mcdonald's”) caused netsuite lookup queries to fail, preventing those records from syncing correctly with this fix, customer and payment term lookups now safely handle names containing single quotes across all affected netsuite workflows, eliminating the sql parse errors seen during sync this ensures orders for customers with these names activate and sync end to end without manual intervention payment sync error cleared for netsuite manual payments previously, manual payments processed in netsuite (such as wire transfers) synced back to nue and correctly marked invoices as paid, but the transaction hub still displayed a false error for one step of the payment workflow because it was expecting stripe based payments only with this fix, netsuite originated payments are handled correctly without creating transaction hub errors, improving the accuracy of payment status visibility this results in a smoother experience for customers using hybrid payment setups across netsuite and stripe