# One job record behind every site, crew and invoice.

> A specialist construction services contractor’s sales, jobs, site documents, technician hours and invoicing lived in separate systems. SynconAI connected them through Salesforce, keeping the field tools its crews already use.

- Source: https://synconai.com/case-studies/construction-services-contractor-one-job-record
- Publisher: SynconAI (https://synconai.com)
- Type: Case study
- Evidence: Real delivery work, written up by industry. The client’s identity and the detail of their systems stay private.
- Organisation: A specialist construction services contractor running sales, site crews and subcontractors across multiple projects at once
- Industry: Commercial & Business Services
- Products: Sales Cloud, Field Service, Salesforce Platform, Apex REST, Lightning Web Components, Xero, QuickBooks Time, Dashpivot
- Service: Salesforce Field Service (https://synconai.com/salesforce-field-service)
- Reading time: 6 minutes

## In short

We connected a specialist construction services contractor’s sales, field jobs, site documents, technician hours and invoicing through Salesforce. Sales Cloud runs quotes and jobs, work orders drive scheduling, and custom Apex REST integrations keep QuickBooks Time, Dashpivot and Xero in step, so each job runs on one record from quote to paid invoice.

## Key points

- For a contractor, the job is the unit of truth. Every system should read from it and write back to it, or the business ends up reconciling several versions of the same job.
- Custom Apex REST was the right call here. The volumes were moderate and the logic was specific, so a middleware layer would have added cost without adding control.
- Automate the work breakdown people create the same way every time. Generating the detailed tasks from the job removed a whole class of missed work.
- Write links back. A site document nobody can find from Salesforce is a document the office will ask the crew for again.

## 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

| Area | Before | After |
| --- | --- | --- |
| Quotes | Terms varied by who wrote the proposal | Standard terms on every quote from Sales Cloud |
| Job setup | Tasks discovered on site | Work orders created by automation |
| Technician hours | Re-keyed from timesheets | Synced two-way from QuickBooks Time to the work order |
| Site documents | Searched for by hand | Workspace created from the job, links on the record, forms pre-filled |
| Invoicing | Waited on manual matching | Raised in Xero from the job, invoice file attached |
| Visibility | Several systems, several versions of a job | One job record that every team reads |

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.

## Questions

### Why build custom integrations instead of buying connectors?

Each connection had specific rules: which hours count against which work order, which forms are pre-filled for which kind of job, and when an invoice is allowed to be raised. Off-the-shelf connectors handled the simple fields but not those rules. Custom Apex REST let us put the rules where the job lives and test them with the rest of the org.

### Did the crews have to change how they work?

As little as possible. Technicians kept clocking hours in QuickBooks Time and filling site forms in Dashpivot, because those tools suit the field. What changed is that both now start from the Salesforce job and report back to it, so the office no longer copies information between them.

### Can this approach work with Field Service licences later?

Yes. The job, work order and appointment model maps onto Salesforce Field Service, so the contractor can add optimized scheduling and the mobile app later without rebuilding the integrations or the data model.

---

SynconAI. https://synconai.com/case-studies/construction-services-contractor-one-job-record