ServiceTitan and Salesforce Integration: Where the Boundary Actually Belongs

01Who Actually Needs Both Systems

ServiceTitan already includes CRM functionality for managing residential and commercial customer records, so running Salesforce alongside it means the business has chosen to keep a separate sales system in the stack. A business may choose to run Salesforce alongside ServiceTitan when it wants Salesforce to remain the system used for a separate or more complex sales process while ServiceTitan handles field-service execution: possible scenarios include a longer or more complex commercial sales cycle, account-based selling into multi-location customers, a sales team working opportunities that don't map cleanly onto a single service call, or reporting and pipeline needs the business has chosen to build in a dedicated CRM rather than inside ServiceTitan's own CRM module. If none of those scenarios apply, configuring ServiceTitan's own CRM more fully, rather than adding a second CRM, may be the simpler fix. This guide is written for the business that already has a real reason for both systems to exist and needs to define the boundary between them.

02What Belongs in Salesforce, What Belongs in ServiceTitan

One clear version of this boundary treats Salesforce as the system that owns the sales process, before there's a confirmed, schedulable piece of field work, and ServiceTitan as the system that owns everything from a confirmed job forward: scheduling, dispatch, technician assignment, job completion, and invoicing tied to that job. In ServiceTitan's own API structure, jobs, appointments, and projects live under a separate namespace from customers and locations, which are grouped under ServiceTitan's CRM API; that split mirrors the architectural boundary worth drawing between the two platforms, Salesforce owning early-stage account and opportunity data, ServiceTitan owning the customer-of-record and location data once real field work is involved.

03When Does a Customer Record Get Created?

ServiceTitan's own documentation is explicit that a customer ID and a location ID have to exist before a job can be booked, customer and location records are a prerequisite for scheduling, not something created as a side effect of it. That makes the sequencing question concrete: does a customer and location record get created in ServiceTitan the moment a Salesforce opportunity reaches a stage where field work is likely, or only once the opportunity is actually won and a job is ready to be scheduled? Creating the record too early risks populating ServiceTitan with customers who never convert; creating it too late risks a scheduling delay while dispatch waits on a record that doesn't exist yet. A practical design is to tie ServiceTitan customer and location creation to a defined, late-stage Salesforce trigger, an opportunity reaching a "ready to schedule" stage, rather than either extreme.

04When Does a Sold Opportunity Become Operational Work?

The handoff moment itself, an Opportunity closing in Salesforce and a Job needing to exist in ServiceTitan, is where the two systems' different data shapes matter most. ServiceTitan's Jobs API supports creating, retrieving, updating, holding, canceling, and rescheduling jobs, along with the appointments, job types, and call reasons that go with them, which means the integration's job is mapping a closed Salesforce Opportunity onto a specific ServiceTitan job type and an initial appointment window, not just "creating a job." What job type gets selected, and what information from the Opportunity (service address if it differs from the customer's on-file location, scope of work, any commitments made during the sales conversation) needs to travel with it, is a mapping decision specific to each business's service catalog, not something either platform's default configuration decides on its own.

05What Service and Job Information Should Flow Back to Salesforce

For a sales team working account-based or repeat-business relationships, whether renewals, maintenance contracts, or expansion opportunities within an existing commercial account, visibility into what ServiceTitan actually did on a job (completion status, invoice amount, any additional work identified on-site) is what makes a follow-up sales conversation informed rather than a rep asking a customer to recap their own service history. Useful candidates to sync back include job completion status and invoice totals, since those are the two data points most directly tied to a renewal or expansion conversation; more granular data (technician notes, specific parts used, on-site photos) is available through ServiceTitan's API but is a judgment call on whether a sales-facing system actually needs that level of operational detail, or whether it adds noise a rep has to filter through.

06Duplicate Customers: An Important Failure Mode

One important practical failure in a two-CRM setup like this is the same customer or location existing as two separate, disconnected records, once in Salesforce as an Account and independently in ServiceTitan as a Customer, created by two different people or processes without either system knowing about the other's record. Preventing this requires a deliberate matching strategy before records are created, checking for an existing ServiceTitan customer by a stable identifier (a phone number, an address, an existing account reference) before creating a new one, rather than creating first and reconciling duplicates afterward. Once a match is found or a new record is created, storing the counterpart system's ID directly on the record, the ServiceTitan customer ID on the Salesforce Account, the Salesforce Account ID as a custom field on the ServiceTitan customer, is what gives every later sync attempt a reliable key instead of matching on name and address every time.

07What Happens When One System Changes Customer Information

A customer's contact information, billing address, or account details can change in either system first, a rep updates a phone number in Salesforce during a call, or a technician corrects a service address in ServiceTitan on-site, and the integration needs an explicit answer for which direction that change is allowed to flow, and what happens if the same field changes in both systems before a sync runs. Treating one system as authoritative per field, similar to the ownership pattern used in any CRM-to-ERP build, rather than allowing both systems to freely overwrite each other, is what reduces the risk of a change made correctly in one place being silently reverted by a stale sync from the other.

08Authentication and What's Actually Available to Build On

Both platforms expose real, documented APIs for this kind of integration. ServiceTitan's developer portal documents OAuth 2.0 with a machine-to-machine grant flow, separate integration and production environments, and functional API groupings that include Dispatch (jobs, appointments, projects), CRM (customers, locations), Accounting (invoices, payments), Pricebook, and Payroll. Salesforce's own REST and platform APIs are well-documented in their own right. What's worth confirming before assuming a specific data flow is possible: not every ServiceTitan account has API access enabled by default, developer access is requested and provisioned through ServiceTitan's own developer portal, and the specific fields and objects available can vary by which ServiceTitan modules a given business has licensed. Confirming actual API access and object availability for the specific ServiceTitan account in question is a real prerequisite step, not a formality.

09Native Integration, iPaaS, or Custom Build

The official ServiceTitan sources reviewed for this article, ServiceTitan's own integration marketplace, its published "Available ServiceTitan Integrations" help page, and its Partners & Integrations page, did not identify a ServiceTitan-maintained Salesforce connector as of this review; the integration platforms that show up for this pairing (Tray, Zapier, and Workload among others) are third-party iPaaS tools connecting to both systems' APIs rather than a purpose-built connector maintained by either vendor. Without a ServiceTitan-maintained Salesforce mapping identified in the sources reviewed, the implementation may require explicit decisions around matching logic, field mapping, and sync direction. For a business with straightforward field-mapping needs and moderate volume, an iPaaS platform can implement the matching and sync logic described above without a fully custom build; for a business with more complex matching requirements or high job volume where sync reliability and error handling need tighter control, a custom integration built directly against both APIs may be the more durable choice.

10Why This Buyer Is Worth Building For

A business running both Salesforce and ServiceTitan has already made the decision to separate at least part of its sales process from its field-service execution. That makes the handoff between the two systems commercially important: customer context, sold scope, job creation, and service outcomes can cross a boundary between two systems instead of remaining inside one platform. For NewMotion, that creates a legitimate systems-integration problem to solve without assuming every ServiceTitan customer needs Salesforce.

11A Narrower Version of This Integration

Not every business in this situation needs a fully bidirectional, real-time sync. A field-service company whose commercial sales team mainly needs visibility into whether an account's jobs are being completed on schedule, without Salesforce actively driving job creation, can implement a much narrower version: a one-way, lower-frequency sync of job status and invoice totals from ServiceTitan into Salesforce, with customer and job creation still handled manually or through ServiceTitan's own workflows. That's a meaningfully smaller build than the full bidirectional handoff described above, and it's worth being explicit about which version a given business actually needs before scoping the larger one by default.

12Testing the Handoff Before It Touches Real Customers

Because those matching and mapping decisions are implementation-specific, they should be tested before the integration runs against live customer and job data. ServiceTitan's developer portal provides separate integration and production API environments specifically so a build can be validated against realistic data without touching a live account, and the same discipline applies on the Salesforce side using a sandbox org. Running a duplicate-customer scenario deliberately, the same customer name and address submitted twice, is worth testing directly, since that is the exact case the matching logic described above is built to catch, and it is far cheaper to find a matching-logic gap in a sandbox than in a live dispatch queue.

13Frequently Asked Questions