Bid award notification
A bid award is the moment a months-long bid response becomes real revenue. The cascade has to handle a big asymmetry: NetSuite needs the contract + programs + pricing committed quickly, but the customer-facing acknowledgement should be polished and personalized.
Risk level 4 (high) because the cascade commits real pricing rows into pricing_master that will drive invoices for the contract term. Mistakes here ripple to AR.
The contract is in workflow_definitions WHERE workflow_type='bid_award_notification'. Cascade tables: bids, bid_lines, pricing_master, customer_programs, proposed_actions.
Trigger conditions
- Email arrives at bids@ with an award letter attachment.
- A portal webhook fires from NYC DOE / NJDOA / similar with award details.
- Mike manually triggers from /intake.html when the award arrives off-channel (phone, mail).
- The bids dashboard cron detects a bid moved to "awarded" status externally.
Precondition bid_open blocks if the bid status isn't in (open, pending_award). This catches the "we already processed this award last week" duplicate path.
The 4 beats
-
01
Commit pricing from bid_lines → pricing_master
Each non-deleted
bid_linesrow INSERTs a correspondingpricing_masterrow tagged withsource='bid_award_{bid_id}'. This is the moment the contract's prices become live. -
02
Stage customer_programs (PPI, etc.)
For each new program defined in the contract (PPI, MDF, contract-specific rebates), a
proposed_actionsrow stages withaction_type=create_customer_program. Mike approves the program details before they go live. -
03
Notify fulfillment team
A draft email to the fulfillment team lists the awarded contract, start date, expected weekly volume, and any production heads-up notes. Status=pending_review.
-
04
Customer acknowledgement
A draft email to the awarding customer thanks them, confirms contract terms, and notes the operational handoff. Mike polishes and approves before send.
What's different after the workflow runs
pricing_masterhas one row per awarded bid line, all tagged withsource=bid_award_{bid_id}.- New customer_programs proposals sit in Mike's queue.
bids.status='awarded'andawarded_atis stamped.- Fulfillment has an email waiting — they can start production planning.
- A customer ack draft is ready to polish + send.
- reflexion_log carries a
bid_awardtagged row with bid_id and customer.
What can go wrong and how to recover
Precondition blocks. Likely the award arrived twice; check bids.status and bids.awarded_at. If genuine re-issue, contact the issuer.
If pricing_master INSERT fails midway, the bid stays in pending_award. Retry with POST /admin/bids/<id>/recommit is idempotent — already-committed lines skip via source tag check.
If the contract terms mention a PPI without clear tier mapping, the proposed_action stages with severity=warn. Mike fills in the tier manually before approving.
Some bids are renewals — fulfillment already plans for them. Mike can reject the draft fulfillment email; it logs as rejected in outbound_email_log.
Adjacent workflows + diagrams
Code paths + invariants
| Concern | Where |
|---|---|
| Workflow contract | workflow_definitions WHERE workflow_type='bid_award_notification' |
| Pricing source tag | pricing_master.source='bid_award_<bid_id>' |
| Award status | bids.status='awarded', bids.awarded_at |
| Customer program tier | customer_programs.program_type + value |
| Reflexion tag | bid_award,bid_id:<id>,customer:<id> |
| Risk level | 4 |
| Expected duration | ~60 min |
| Trigger | event · sources=inbound_email, portal_webhook, manual |