On its own schedule — not tied to the accept_470 click — El Nova pushes district and contact data into the CRM. It checks for existing records first; new Accounts (board 18176632844) and Contacts (board 18176633260) are only created if they don't already exist (dedup logic). Sales reps never manually create these records.

When vtg-bid-intake fires after accept_470, it performs a district name search to auto-link the Account and Contact to the new Bids #3 item. The 5-second retry loop in vtg-bid-intake exists specifically because El Nova may not have written the Account/Contact yet at the exact moment the bid item is being created. This is the dependency between Phase 0 and Phase 1.

⚠ Runs when called — today that is only backfill.mjs, run by hand. No monday automation triggers it (checked Oct 1 2026). When it does run, vtg-sf-account-sync upserts both the Account and Contact objects into Salesforce using Monday_Item_ID__c as the external ID — creating new SF records or updating existing ones idempotently. After the SF upsert, the Worker writes the Salesforce Account ID back to the UID column (text_mm6s8adk) on the monday.com Accounts board, completing the cross-system link. A backfill script (backfill.mjs) ran against all 791 existing accounts to populate Salesforce and stamp the UID column. Complements vtg-monday-sf-sync which syncs Bids — this Worker handles the CRM Account/Contact layer.

El Nova pushes inbound Form 470 opportunities to the El Nova Leads board (ID 18181651809). Each lead carries a district name, 470#, and Opportunity Score extracted from the USAC PDF via two-layer decode (ASCII85 + FlateDecode) — done by vtg-lead-score when the Customer Summary PDF lands, writing Opportunity Score (numeric_mm5w3j).

Every new Leads item is screened before anyone works it. vtg-bid-intake POST /lead-created compares the lead name (the bare 470 number) against Bids #3 470__. One 470 never covers two separately-bid RFPs — so a 470 already on a live bid means this lead is an addendum, not a new opportunity, and working it produces a duplicate bid. On a match the Worker attaches the addendum document to the bid’s Addenda column, increments Addendum #, stamps Last Addendum Date and sets Addendum Status to Received - Unreviewed, then posts a courtesy update on the lead so nobody clicks accept_470 on it. The bid’s stage never moves — it stays where it is and gets flagged. If a district cancels a 470 it issues a whole new one, which is a genuine new opportunity (old bid → Lost); and by law no addendum can arrive after the submittal date, so there is no post-submittal path. Currently running with ADDENDUM_DRY_RUN = true: matches are logged, nothing is written.

The 470 feed usually adds an addendum to the existing lead’s RFP Documents or Form 470 column rather than creating a new lead. vtg-bid-intake POST /lead-files-changed checks whether the lead’s 470 belongs to exactly one live bid; if so, only the new files are copied to the bid’s Addenda column, the bid is flagged, the bid owner and the lead’s Sales Executive are notified, and the lead goes back to Accepted Leads — no second intake form. vtg-sp-folders then copies the addendum into the bid’s SharePoint folder. Leads with no live bid are left alone. Dylan’s two “Accepted Leads → New Leads” addendum automations were deactivated Oct 1.

Rep clicks accept_470. Automation 7920733007 sets Status → Pending Intake, which fires webhook 632506055 to vtg-bid-intake; the Worker writes the 📋 Intake Form link onto the lead and the rep opens the form from it in a new tab. Rejected leads simply close the lead — no webhook fires, no Bids item created.

The vtg-bid-intake form now includes all intake fields in one place: Sales Executive, ScopeStack Blueprint(s), delivery method, partner, manufacturer, distributor, bid due date, and bond required. Blueprint selection inside the form triggers the ScopeStack API to auto-create a proposal. On submit, the Worker patches all columns to Bids #3, writes the SOV Builder link to link_mm591mdg, and creates a bond subitem + email if bond is required. The accept also sends a trigger to El Nova, which creates the Accepted Monitor board item.

The accept trigger sent to El Nova causes El Nova to create an item on the Accepted Monitor board. This board runs in parallel to the main bid flow — it polls USAC automatically on a schedule to watch whether the 470 is funded. It is an FYI / watchdog board; the main Bids #3 flow does not gate on it. Rejected leads do not appear here — reject simply closes the lead.

Worker creates a new item in Bids #3 (board 18176633000) under New Bid Folder Creation. Auto-links Account (18176632844) and Contact (18176633260) via district name search with 5s retry. Writes the "📋 Open Intake Form" link and the 📊 SOV Builder link (link_mm6vbks) to the bid item.

When the bid is created at Folder Creation, vtg-sp-folders builds its SharePoint folder in cust_ERATE{FY}RFPs: named after the bid without the colon, the Base Bid Docs folders copied in with their files, and the Lead’s 470, RFP and Customer Summary in the folder root. It writes the SharePoint Link column and sets both Folder Creation subitems to Complete. If anything fails, the subitem goes to Stuck with an update explaining why. Bids that already have a SharePoint Link are skipped.

Rep opens the form link and completes: delivery method, partner, manufacturer, distributor, bid due date, bond required. Worker patches all columns. If bond required, subitem created and email fires to bonds@vtgus.com + CHC-Surety@alliant.com.

Branden submits to manufacturer portals (Ruckus, Cisco, etc.). dealreg.py (Playwright) is built and field-mapped but not fully live — dynamic portal elements on Ruckus are causing failures.

When a bid item is created, automation 482374765 immediately creates 23 subitems covering every stage from Folder Creation through Awaiting Results. Each task is pre-tagged with its Bid Stage, pre-assigned to the relevant person, and given a due date counted back from the bid due date in business days by vtg-bid-task-dates (bids created after Sep 24 2026). Tasks are never re-created per stage — the full lifecycle checklist exists from day one, with future tasks in "Still To Do" or "Create Item" status until needed. The three per-person parent columns (Alan / Jake / Dylan Subitem Status) are driven by automations: they flip to Due Today at 11am ET when a task's date arrives, and clear when the task is marked Complete.

Mark pulls distribution pricing and builds cabling scope. vtg-sov-builder is available for multi-tab SOV creation — generates the SOV as a PDF and an Excel workbook, versioned, into the Bids #3 SOV PDF column; vtg-sp-folders copies each version into the bid’s SharePoint folder (Base Bid Docs/3 -SOV). SOV payload includes vendorPOs array pre-grouped by vendor for future NS PO creation.

Dylan compiles all components and submits on the USAC EPC portal. Each stage change syncs to Salesforce via vtg-monday-sf-sync (upsert on Monday_Item_ID__c).

USAC issues FCDL. Won bids → Post-Sale. Lost bids → Lost sub-board. Wins also archived in Wins Archive sub-board.

When Bids #3 → Post-Sale (webhooks 562741747 + 483153616), vtg-cs-form generates a CSOP PDF, emails to erateops@vectortechgroup.com and Sales@vtgus.com (both TO) with KV deduplication, and auto-creates a monday subitem checklist. On form submit, vtg-cs-form creates a Projects #4 item, appends 6 PM subitems (Project Kickoff Meeting, Site Access Coordination, Installation Scheduling, Weekly Status Updates, Project Documentation, Project Closeout) tagged 'Project Management — E-Rate' — skipped only for Equipment Only bids or when Network Infrastructure Deployment – PM is already selected — and stamps the UID on the new Projects #4 item by reading the Account's UID (text_mm6s8adk) and writing it to text_mm76zvbz. Updated Sep 10 2026; UID stamp added Sep 14 2026. New Client Setup (live Sep 28 2026): when the account has no NetSuite Customer ID, Section 1B collects Cari’s new-client fields and the submit creates or links the NetSuite customer through vtg-ns-so-backfill, writing the NS ID back to Accounts #1. Simultaneously, automation 482374746 creates 6 Post-Sale subitems on the bid item: (1) Letter of Intent signed + uploaded to SharePoint (Jon), (2) Create Contract in ConnectWise Sell — CW Sell paused Sep 29 2026, (3) If SPI: FCDL uploaded to SharePoint or N/A if BEAR (Alan+Jake), (4) If SPI: FCDL templated email sent or N/A if BEAR (Alan+Jake), (5) Purchase Order issued by customer + uploaded to SharePoint (Alan+Jake), (6) Update SOV, get Disty quote to match, upload to SharePoint (Alan+Jake).

ConnectWise Sell is not part of VTG’s plan, so CPQ work is paused unless that changes. vtg-cs-form still calls vtg-monday-cpq on every CS Order submit (it clones the E-Rate Contract template and writes Quote # / CPQ Status back to Bids #3 when the call completes); line items were never built. Direct-to-NetSuite ordering stays on the Planned list.

Rep or Kevin confirms customer PO and E-Rate funding. vtg-po-sync (live Aug 25 2026) syncs the NetSuite Vendor PO # and PO Status back to Projects #4 via cron every 4h + webhook on NS SO# column change.

Jon creates the Projects #4 item (board 18176626554) linked to the winning bid. Project Year dropdown auto-set by vtg-set-project-year. Stages advance (live labels): Accept → Procurement → Installing → Closeout → Ready for Invoicing → Closed. Deactivated but still on the board: Waiting for Product → All Product Received → Kick Off → Pre-Install Staging → Installing.

vtg-revenue-month keeps Revenue Month (date_mm39fh8x) equal to the end of the project Timeline. When the stage reaches Ready for Invoicing or Closed, it stamps that day’s date and ticks Revenue Month Locked (boolean_mm7a4044), so later timeline edits no longer move it. A daily cron re-syncs unlocked projects that have drifted.

Field crew installs. When stage → Installing, automation (ID 7922447604) auto-populates the Materials Log link column (link_mm6mhdcx). Jon or PM opens vtg-materials-log, selects fiber/copper parts from SKU_CATALOG, and submits. The project card shows Client, Stage, UID, NS Sales Order #, and Monday Item ID pulled live from Projects #4. v4 (Sep 16 2026): On submit, cabling lines are PATCHed directly onto the NS Sales Order and an Item Fulfillment is created — drop-ship SOs get a warehouse note instead. NS result (IF# or confirmation) is posted to the monday thread and stored in KV. Re-push to NS button available on the locked page for retries.

vtg-meeting-sync receives Sembly meeting output. Each action item is matched to a Projects #4 subitem (fuzzy match, scoped to one project when a project code is in the text) and that subitem’s Status is updated, with a note posted on its project. Meeting notes that carry a project code are posted as an update on that project.

Materials log submission advances stage to Ready for Invoicing, stamps date_mm54qwps, posts thread update, and triggers vtg-billing-ready → email to eratebilling@vtgus.com. Automations: 7920569056, 7920172789, 7917999463, 7920230690.

Finance receives billing notification email and manually creates the NetSuite invoice. No automated handoff from monday.com to NS for invoice creation today.

Every 4 hours vtg-ns-so-backfill finds each project’s NetSuite invoices — by Customer PO, else by the project’s SO — and writes Invoiced to Date (numeric_mm7d9sf4), Remaining to Bill (numeric_mm7db7yk = Total Project Amount − invoiced), Last Invoice Date and Billing Match. Invoiced only — no AR, no credit memos. Projects that SO Check flags as Duplicate project, Mismatch or Cannot verify are skipped until they are cleaned up.

When Projects #4 → Ready for Invoicing, vtg-ns-mcp-sync fires the Ready to Invoice → NS Invoice flow. Auth is live (prod cert ID _Xm9jPsUb1H7DXPj5SmbJQNNKy3l7VU05MVPgGG4TSk). Blocked by: the NS service item internal ID needed from Kevin/Cari. The Worker’s 15-minute cron currently fails on every run (the integration role cannot read transaction). vtg-ns-compare was deleted Oct 1 2026; customer mapping is now the NS Customer Internal ID on Accounts #1, which this Worker does not read yet.

Once invoiced and paid, Projects #4 → Closed. Stage-change automation populates Actual Revenue Month (date_mm4tatyy) feeding the Forecast vs. Actual widget on the Pipeline dashboard (board 18419943586).

When a Bids #3 item enters the Post-Monday group, automation 559103546 creates an item on the E-Rate Deals board (18406412794) in the E-Rate Operating System workspace. Fields populated: District, FRN, Contract Value, Funding Year, Category, Sales Owner. Status starts at Pipeline. This is the current active flow — the older automations that created a Projects #4 item directly (482374713) and notified CS/PM (482374738) are both inactive.

The E-Rate Deals status (Pipeline → Submitted → Awarded → Booked) is not consistently maintained — it's unclear who updates it and when. This status is the trigger for the next step, so inconsistent updates mean the E-Rate Projects item may not be created reliably.

When E-Rate Deals Status changes from Pipeline → Awarded, automation 7917669964 creates an item on the E-Rate Projects board (18406413755). The item mirrors data from both Bids #3 (Account, Contact, Bid Value, 470#, SharePoint Link, Projects #4 link, Bid Name) and E-Rate Deals (District, Booking Date, Contract Value, Funding Year).

Jon maintains the E-Rate Projects item as the financial and scheduling view of the project — distinct from Projects #4 which tracks physical delivery. Fields managed: Execution Status (In Execution / Ready / Substantial Completion / Complete / Billed), Billing Status (Ready / Sent / Paid / Not Ready), Planned Start Window (Q1/Q2/Q3/Q4/Summer/Post-Funding), Planned + Actual Start Dates, Completion Date, Risk Flag (Delayed / At Risk / Missing Start / None), PM, Project Owner, Notes.

When E-Rate Deals Status → Booked, automation 7917670450 automatically stamps today's date into the Booking Date column, which mirrors into E-Rate Projects via the Linked Deal relation.

For the sales team, Salesforce is the system of record for commercial (non-E-Rate) pipeline — "If it's not in Salesforce, it didn't happen." Routing: no E-Rate / FCC funding → Salesforce; E-Rate work → monday.com; on a split-funded deal the non-E-Rate portion is tracked in Salesforce separately. Written up in the VTG Salesforce SOP (VTG_Salesforce_SOP.html, v2.1 — Sep 9 2026).

⚠ Revised Sep 24 2026 — Salesforce is a reporting layer, not a link in this chain. It exists to give the sales team a view of pipeline; it is not part of the order-to-invoice flow, and no step below should depend on it. Salesforce integration work is stopped until Salesforce settles its final product. The replacement direction: the monday client form creates the new customer directly in NetSuite, taking Salesforce out of the middle. The existing sync Workers keep running — they are how the UID gets written back — but nothing new is being built on them.

Account creation order, agreed Sep 28 2026: the account is created in monday first, then the customer is created in NetSuite, then Salesforce, and the Salesforce UID comes back to both monday and NetSuite. The NetSuite customer is created at won/order, not at lead — no NS record for something that may never become an order. Salesforce still receives the data, but last and for reporting; that is also what satisfies Bill’s new-client checklist automation. This reconciles the two positions above: Salesforce is not in the critical path, but it is not cut off either. Worth knowing why it matters — sales reps do not want to create accounts in Salesforce and only do it when forced to, which is non-E-Rate jobs; an automated flow is what keeps SF populated at all.

Commercial leads come through the MSP portal, which triggers the vtg-msp-csop Worker. Unlike E-Rate, this flow bypasses Bids #3 entirely and lands directly in Projects #4. The CSOP form auto-builds the task list (subitems) for the project.

Commercial track skips the entire Bid Building phase. Task list built by the CSOP form serves as the project scope and work order from day one.

Jon works the subitems in Projects #4 as a task checklist. No separate bid compilation or SOV step. Stage advances through the same Projects #4 stages as E-Rate (New → Installing).

Same flow as E-Rate: stage → Ready for Invoicing fires vtg-billing-ready → billing email to eratebilling@vtgus.com. Ready for Invoicing Date stamped (date_mm54qwps).

Finance receives billing notification and manually creates the NS invoice. Same planned automation path as E-Rate: vtg-ns-mcp-sync Ready to Invoice → NS Invoice flow once unblocked.