Every product in this category binds the hold to a contract term. We bind it to a cash decision. A release group is created by a person, links the customer invoices that fund the work to the vendor bills held against them, and lets go when those invoices are collected. That one move is what the rest of the design falls out of, and it is why this works for the roughly half of holds that have no pay-when-paid clause behind them at all.
The mechanism is NetSuite's own. Group membership drives the native payment hold, a check on the vendor payment record refuses the save on every route including imports, and a nightly sweep does the routine releasing so nobody is waiting on someone's attention. The workbench below exists for the exceptions: the afternoon a controller learns the customer paid this morning and wants the bill in today's check run.
This prototype is live. Every filter, chip, sort, checkbox and button works, groups really get created and released, and toasts name the records NetSuite would actually write. The seed data is built out of the awkward cases rather than the tidy ones.
Everything above is designed and reviewed: the workbench on both of its mounts, the link builder and the release confirm. The two record panels are designed too, in their own mockup, because they live on native NetSuite records rather than in this app. One thing is left, and it is a sentence rather than a screen.
Both render as inline HTML on the record's main tab rather than in a sub-tab. The bill panel answers one question for an AP clerk who has hit a wall, why will this not pay and what clears it, and carries the only in-context action in the product. The invoice panel is read only and tells whoever applies a receipt what that receipt just released.
They sit outside this prototype because they are components on someone else's page. See
mockups/05-06-record-panels-inline-v1.html.
An earlier build had one, with five controls. Three were removed rather than moved: two of them configured a warning that does not exist, since the past-due signal is a colour and a tile and nothing emails or escalates anyone, and the third asked a controller to tune a SuiteScript governance limit.
The two that survived were real, and they belong somewhere else. Who may create groups and who may release are custom permissions, assigned in Manage Roles beside every other NetSuite permission, rather than a role list on a record no admin would think to audit. The release threshold is a script deployment parameter. Vendor terms, which decide every due date in the product, were always NetSuite's.
The hold is enforced in four layers, and the third is the real guarantee: a check on the vendor payment record that refuses to save when any applied bill is held. It fires on every route, including imports and the Electronic Payments SuiteApp.
It renders in NetSuite's own error banner, which cannot be styled. The only design surface is the sentence: Bill 8871 from Acme Supply is on payment hold under release group RG-00042. Release it before paying.
Design prototype for BlueCollar Pay-When-Paid. Data is fabricated. Amounts, vendors, projects and customers are invented for illustration and do not represent any real company or transaction. Built against the BlueCollar design language, and intended to be read alongside the approved UI decisions document.