One job record behind every site, crew and invoice.

#The starting position

The contractor delivers specialist services on commercial construction projects. Its work is high in compliance and low in tolerance for error: what was done, with which products and by whom has to be evidenced, because a project cannot be signed off without it.

Before this engagement, that work ran across several disconnected tools. Sales lived in Salesforce, but only as a list of opportunities. Jobs were tracked in spreadsheets. Technicians clocked hours in QuickBooks Time. Site forms, photos and records sat in Dashpivot. Invoices were raised in Xero. None of them shared a job number anyone trusted, so the office spent its week copying details from one system to the next, and every copy was a chance to get a site address, a scope line or a billable hour wrong.

The cost showed up in three places. Quotes went out with inconsistent terms. Jobs started without a complete breakdown of tasks, so work was discovered on site. And invoicing waited on someone matching timesheets and site records by hand, which slowed cash collection on every project.

The business was also growing. More projects meant more crews, more subcontractors and more documents per week, and the manual hand-offs that were tolerable at a smaller size were becoming the limit on how much work the office could take on.

The brief was clear: one operating backbone for sales, field jobs, documentation, time and accounting, without forcing crews off the tools that work in the field.

#What we built

01 Sales Cloud as the commercial front end

We rebuilt the sales process on Sales Cloud for the way the contractor actually wins work: leads from builders and head contractors, opportunities by project, and quotes that carry the company’s standard terms. Quote terms were added as a delivered enhancement, so every proposal now goes out with the same conditions, which matters when a variation or a dispute arrives months later.

02 Jobs and work orders

A won opportunity becomes a job, and the job drives the work orders beneath it. Custom automation creates the detailed work orders from the job, because projects of the same kind need the same set of tasks every time. The system now creates them instead of relying on someone to remember them.

03 Scheduling synced two-way with QuickBooks Time

Appointments are scheduled in Salesforce and pushed to QuickBooks Time, where technicians already clock on and off. We deployed the production scheduler and built a two-way integration, so hours worked return to the right work order without anyone keying them in. The office sees planned against actual on the job.

04 Dashpivot site documentation

Dashpivot was delivered in two phases. The first creates the site documentation workspace from Salesforce and writes the document links back to the job. The second added document workflows and pre-fill, so forms open on site with the job details already in place. Crews spend their time on the work, and the record is complete when they leave.

05 Xero invoicing with the file on the record

When a job is ready to bill, Salesforce raises the invoice in Xero and attaches the invoice file back to the record. Finance, operations and sales now look at the same job and the same invoice, and nobody has to search a mailbox to answer a builder’s billing question.

06 Operational alerts

We also scoped the Slack requirements for operational workflows, so the right people hear about job events without watching a report.

#How a job flows through the business

A builder asks for a price. The opportunity is created in Sales Cloud, the quote goes out with the standard terms and, once accepted, the same record becomes the job. From that moment every other system is working from the same identifier.

The work orders appear without anyone typing them. The office schedules the appointments, and the crew sees them in the time tool they already use. On site, the forms open with the job details filled in. At the end of each day the hours land back on the right work order.

When the work is complete, the office raises the invoice from the job. The invoice file is attached to the record, so a question from the customer a month later is answered from one place. Sales, operations and finance never need to ask each other which version of the job is correct.

#How we delivered it, end to end

One project, traced end to end. The design started from the path a real job takes, from quote to invoice, and every hand-off between systems on that path became an item on the integration backlog.

Data model before integrations. The job, its work orders and its appointments were settled first, because every integration reads from or writes to them. With that model agreed, each integration had a clear owner record and a clear direction of travel.

Integrations in custom Apex REST. The rules were specific to this business, such as which hours belong to which work order and which forms are pre-filled for which kind of job, so the logic sits inside Salesforce, next to the records it governs, and is tested with the rest of the org.

Delivered in phases. Sales Cloud and the job model came first, then the scheduler went into production, then the site documentation work in two phases, then invoicing. Each phase stood on its own, so the business was using the new process while the next piece was built.

Support and enhancements after go-live. The contractor stays on ongoing support. Quote terms, document pre-fill and work order automation were delivered as later enhancements through that relationship.

#Why the integration design held up

Integrations tend to fail in the same few ways: two systems both believe they own a field, an update arrives twice, or a failure is silent and nobody notices until month end.

The principles we apply against each are simple. Every piece of information has one owner system, and the other systems receive it rather than editing it. Messages between systems should be safe to repeat without creating duplicates. Failures should be visible against the job they affect, so the office can see what did not sync instead of discovering a gap in a report weeks later.

Because the logic lives in Salesforce, it is covered by the same automated tests and deployment process as the rest of the org. A change to a rule is reviewed, tested and released like any other change, which keeps the integrations maintainable by whoever supports the org next.

#The decisions that mattered

Keeping the field tools. It would have been tidier on a whiteboard to move everything into Salesforce. In practice, technicians already used their time and documentation tools well. We made Salesforce the system of record and let the field tools stay the system of entry, which is why adoption was not a fight.

Custom code over middleware. A middleware platform would have added licence cost and another place to debug. For this volume and this rule set, well-tested Apex REST was the cheaper and more transparent option, and it can move to middleware later if volumes grow.

Automating the boring, repeatable parts first. Generating work orders and pre-filling forms are not glamorous. They removed the most frequent errors, and that earned the trust needed for the bigger integrations.

#What changed

The point of the design is simple: with one record per job, the office stops reconciling systems and starts managing the work.

#What we would tell a contractor starting this

Most contractors we speak to already own the right tools. What they lack is a single place where a job is defined, so each tool holds a slightly different version of it.

Start with the job. Agree what a job is, what belongs under it and which system owns each piece of it, before anyone builds an integration. Keep the tools your crews already use well, and make them read from and write back to the job. Then automate the repeatable tasks first, because that is where errors hide and where trust is earned.