Salesforce for Construction Companies: Past the Bid

Salesforce for construction companies usually gets judged on the wrong half of the business. The sales half works fine: you track who you’re bidding to, what the number is, and whether you won. Then the bid closes, the Opportunity turns green, and the CRM stops paying attention at the exact moment the job starts changing. My position is simple: a contractor’s CRM should follow the money past the award, and the standard model can’t, so you build the three objects that can.

Closed Won Is Where Construction Starts, Not Where It Ends

The Opportunity object was designed around a sale that finishes. You agree on a price, the deal closes, and the amount is the amount.

Construction doesn’t work that way. The contract you sign is an opening position. Over the life of the job the scope moves: the owner adds a floor of tenant fit-out, the drawings get revised, the site turns up something nobody priced. Each of those is a change order, and each one changes what the job is worth.

So the number on your Closed Won Opportunity is accurate for about a week. After that it describes what you sold, and nobody in the company is asking that question anymore. They’re asking what the contract is worth today, how much of the change work is approved versus still being argued about, and which jobs are drifting.

Most contractors answer those questions in a spreadsheet the project manager owns. The CRM keeps the original amount forever, like a photograph of a building that has since been remodeled.

One Project, Four Bids, a Pipeline That Lies

The second break happens before the award, and it hits subcontractors hardest.

A project goes out to bid. Four general contractors are chasing it, and you send a number to each of them. In a standard Salesforce setup that’s four Opportunities on four Accounts, because an Opportunity belongs to one Account.

Only one of those general contractors can win. At most one of your four Opportunities can ever close. But your pipeline report adds all four, so one building shows up as four times the work. Multiply that across every project you’re pursuing and the forecast is fiction.

People patch this with naming conventions, or by logging only the “most likely” bid, or by a report filter someone has to remember. Every one of those patches throws away information you actually want: which GCs you bid to, at what number, and who you tend to win with.

The real problem is that the building has no record of its own. There is nothing in the org that says “these four bids are the same job.”

The Three Objects a Contractor Actually Needs

None of this needs an exotic design. It needs three custom objects sitting next to the standard ones.

Project. The thing being built: the address, the owner, the architect, the bid date, the size. It exists whether or not you win it, and it’s the record everything else points at.

Job. The awarded work. It’s created when a bid is won and it carries the original contract value, the project manager, the start and substantial completion dates, and the current status.

Change Order. One record per change, belonging to a Job, with an amount, a status (pending, approved, rejected), a reason, and the dates it was submitted and approved.

Your bids can stay as Opportunities. You don’t need to replace the object your sales team already knows. Each Opportunity just gets a lookup to the Project it’s a bid on, which is the one field that makes four bids recognizably one building.

If you want a picture of how small a build like this is, we walked through the same shape (object, fields, relationships, deploy) in building a Salesforce custom object with AI.

Make Change Orders Roll Up, and Decide It Before You Load Data

The relationship between Job and Change Order is the design decision that matters most, and it’s worth getting right the first time.

Make Change Order the detail side of a master-detail relationship to Job. The reason is roll-up summary fields. Salesforce only lets you define one on the master side of a master-detail relationship, and it can count the detail records or take the sum, minimum, or maximum of a field on them, with a filter on which records are included.

That gives you three fields on the Job that update themselves:

• Approved change orders: the sum of Change Order amounts where the status is approved.
• Pending change orders: the same sum where the status is pending.
• Current contract value: a formula adding the original contract value to the approved total.

Those three numbers replace the project manager’s spreadsheet. Nobody maintains them. They’re a consequence of the model.

Four Platform Rules to Know Before You Build

Three of them come straight from Salesforce’s own considerations for object relationships. A custom object can have up to two master-detail relationships. Deleting a master record also deletes its detail records, so deleting a Job takes its change orders with it, which is the behavior you want here and a reason to lock down who can delete Jobs. And you can’t create a master-detail relationship on a custom object that already contains data, so settle the relationship before you backfill a single change order.

The fourth decides the shape of the bid side. Standard objects can’t be the detail side of a custom object in a master-detail relationship, so an Opportunity can only look up to a Project. That means no native roll-up from bids to Project. If you want “number of bids out” or “highest bid” on the Project record, that’s a small piece of automation, the same pattern covered in roll-up summaries without a master-detail relationship.

What the Model Lets You See

The objects are plumbing. Here’s what they buy you once they exist.

A pipeline counted by building. Report on Projects with open bids instead of on Opportunities, and each job counts once. The individual bids are still there underneath, so you can finally answer which general contractors you win with and which ones just collect your numbers.

Unapproved work in one place. Pending change order value across every active Job is the money you’ve likely already spent labor and material on and can’t bill yet. It’s the most uncomfortable number in a contracting business and most companies can’t produce it without phoning every project manager.

Stale change orders, flagged. Any Change Order sitting in pending past the number of days you choose gets surfaced to the project manager and their boss. If the approval itself has several sign-offs, with thresholds by amount, that’s the territory covered in what to build when approval processes outgrow Flow.

Jobs that have grown. Current contract value against original contract value, per Job, sorted. The jobs at the top of that list deserve a conversation, whether the growth is good news or scope creep nobody is managing.

A clean handoff. When a bid is marked won, the Job gets created with the contract value, the Project link, and the estimator’s notes carried over, and the other bids on that Project close as lost automatically. That’s one specific case of the Salesforce automation that should run after the deal closes.

What Doesn’t Belong in This Build

I’d keep a hard line around this. Don’t try to turn Salesforce into your estimating system or your job-cost accounting.

Estimating has its own tools and its own logic, and takeoff is not a CRM problem. If your bids involve configurable line items and price rules, that’s a quoting question, and we’ve covered the honest options in CPQ alternatives for quote automation and in Salesforce quoting for manufacturers.

Job costing lives in accounting, and it should stay there. The CRM’s job is to hold the commercial truth: what we bid, what we won, what the contract is worth now, and what’s still unapproved. If you later want billed-to-date or retainage visible on the Job, pull those figures in from accounting as read-only fields. Don’t re-key them, and don’t make Salesforce the system of record for them.

Scope discipline is what keeps this from becoming a six-month project.

Why This Used to Be a Consulting Engagement

Three custom objects, a master-detail relationship, roll-ups, a formula, an aging alert, and a handoff automation. That list isn’t hard. It has just always been developer work, which means a statement of work, a discovery phase, and a timeline measured in weeks for something a contractor would describe in two paragraphs.

That’s the part that changed. When your AI can connect to your Salesforce org and build in it, “create a Change Order object as a detail of Job, with these fields and these three roll-ups” is a sentence you type, not a ticket you file.

Sentinel is what gives the AI those hands. Changes go to a sandbox first with tests, every change is logged, and a snapshot is taken before each deploy. I’ll be exact about the limits: none of that stops an AI from making a poor design choice. It makes every change visible and every deploy recoverable, which is what lets you move quickly and undo when something isn’t right. Pricing is flat per Sentinel and is covered on a short demo call.

Start With Change Orders on Your Active Jobs

Don’t model the whole business on day one. Build Job and Change Order, and nothing else.

Create a Job for each project you have under contract right now. There are fewer than you think. Enter the original contract value, then log the change orders already in flight with their real status. Put the three roll-up fields on a list view your project managers open every morning.

That alone answers what your work is worth today and how much of it is unapproved. If it earns its place, add Project and the bid lookup next, and fix the pipeline.

The contractors who run tight aren’t the ones with the most software. They’re the ones whose system describes a job the way a job actually behaves: it starts at the award and keeps moving until closeout.

Want to see this model built in an org like yours? Book a Demo Call and bring your messiest job.