Deal Risk Without a Developer
Ashford Services wants three things on sales orders: a 'Deal Risk' field with values Low, Medium and High; a required justification note whenever risk is High; and approval by the services director before any High-risk order over $100,000 can be approved. Volume is about 60 orders a day. In addition, 40,000 historic orders must be back-filled with a risk rating from a legacy system export, and the sales director wants a dashboard showing open high-risk orders by sales rep. The current 'approval' is a manual email to the director. The company has one part-time NetSuite administrator with no scripting experience, and an IT team that can write SuiteScript but works on a two-week change lead time. The custom body field already exists and is on the order form.
1. Should this be built in SuiteFlow or SuiteScript? Defend the choice.
Read the worked answer
Give this to SuiteFlow. The requirement is state-based and declarative - conditional mandatory field, threshold approval, locked state afterwards - and the part-time admin must be able to change it without a code deployment. IT's two-week lead time is incompatible with a live problem, and a user event script enforcing mandatory fields would be harder for the admin to maintain later. Build it as a workflow on Sales Order triggered on create and edit that sets the justification field to mandatory when risk is High, then moves the record to a Pending Approval state when risk is High and amount exceeds $100,000, with the services director as approver and a locked state after approval. Reserve SuiteScript for the narrow case workflow handles poorly - for example a user event that enforces the same rule on entry points workflow does not cover, such as web services. Keep the script optional and separately deployable so the approval flow is never blocked by a code release.
2. How would you run the 40,000-record back-fill, and what is the trap specific to this design?
Read the worked answer
Use the Import Assistant in Update mode, keyed on internal ID or an external ID you control. Three things to get right. First, the header must use the field ID rather than the label, and values must match the custom list exactly - 'high' when the list says 'High' will fail or leave blanks. Second, and specific to this design: by default an import does not trigger workflows or run server-side user event scripts. Leave the 'Run Server SuiteScript and Trigger Workflows' option off, because if it is on, every historical order set to High will enter the approval workflow and could email the director thousands of times while consuming governance. Third, batch it. 40,000 rows is too many for one comfortable file, so import in chunks of a few thousand, validate a small sample first, and reconcile counts by risk value before and after. Consider restricting the field's edit rights afterwards so migrated values stay stable.
3. Design the dashboard search for 'open high-risk orders by sales rep' and explain the choices.
Read the worked answer
Build a sales order search with summary enabled. Criteria: main line = true so amounts are not multiplied by line count, status not Closed or Cancelled, and Deal Risk = High. Group by Sales Rep, then add a Count of Document Number and a Sum of Amount. That returns one row per rep, which is what a dashboard portlet needs; a non-summary search over 40,000 historic orders will hit result limits and be slow to load. Add a second portlet listing the five largest open high-risk orders using a sorted, limited search, because aggregated totals hide the single deal that actually needs attention. Publish through the Custom Search portlet, restrict it to the roles that should see commercial data, and confirm every field shown is in the search's Results tab before adding it - a field that exists in Criteria but not Results renders as blank on the portlet. Use a joined employee field rather than a formula on the rep name.