Salesforce for Logistics: Build a TMS or Buy a Native One?

Key Takeaways : 

• Buying a native TMS is usually the stronger starting point because mature Salesforce-native products already cover shipments, loads, carriers, exceptions, rating and other transportation workflows.
• Custom development makes the most sense around the TMS, particularly for customer portals, bespoke pricing, exception workflows, compliance processes and proprietary carrier logic.
• High-volume telematics should not be pushed into custom Salesforce objects, with Data 360 providing the more appropriate architecture for tracking data at scale.
• Native TMS products have a security advantage in regulated freight, because they inherit Salesforce’s platform security and compliance posture rather than introducing another independently audited system.

Quick Answer: No Salesforce logistics cloud, but mature native TMS products exist. Work Order and Asset are standard Field Service objects; don’t build those either. A native TMS inherits Salesforce’s security posture, which removes a second vendor audit in regulated freight. The real custom work is customer portals, pricing logic, and the integration layer. And telematics volume belongs in Data 360, not custom objects.

Logistics is the industry where custom-building on Salesforce is hardest to justify, and it’s not because Salesforce ships a logistics cloud; it doesn’t.

It’s because the native TMS ecosystem is genuinely mature. Neurored, Revenova and FTM all run inside Salesforce rather than integrating with it, and each already has the Shipment, Load, Carrier and Exception model you’d otherwise spend six months building.

That doesn’t mean you should never build; it means the bar is higher here than in any other industry we cover.

Where Standard Salesforce Stops for Logistics

Sales Cloud handles the customer relationship, shippers, brokers, accounts, and quotes. That’s genuinely useful, and it’s where many logistics businesses start.

What it doesn’t handle is the freight. A shipment moving through multiple legs and carriers. A load with weight, dimensions, hazmat classification, and equipment requirements. Rating across modes. Exceptions that need working, documentation that customs will actually accept.

None of that is standard, but unlike real estate, where you’re largely on your own, logistics has a well-developed set of native applications that already solve it.

Three Routes and Why Building Is the Hardest to Justify

Three routes for logistics on Salesforce: Buy a native TMS, build custom, or extend a TMS

The native TMS products are the starting point, not an afterthought:

• Build Custom: When your operating model genuinely doesn’t fit one of them, such as unusual multimodal combinations, a niche vertical, or a process that is your competitive advantage. In those cases, custom Salesforce development can make sense when the business case justifies owning the additional complexity.
• Extend a TMS: When the operational core is covered but your differentiator sits elsewhere. This is what most established logistics businesses actually end up doing. 
• Don’t rebuild Field Service: Work Order, Asset, Service Appointment, and mobile scheduling are standard Salesforce Field Service objects. For last-mile, installation and maintenance work, they’re already there.

Related: Configuration vs customization

Native TMS or Integrated TMS? The Audit Question

Comparison of a native Salesforce TMS versus a standalone TMS with integration, focusing on data model, security posture and audit requirements

This is the argument that doesn’t appear in feature comparisons and matters most in regulated freight.

A TMS running natively inside Salesforce inherits the platform’s compliance posture – SOC 1/2, ISO 27001, GDPR, role-based access, field-level security. There’s no separate security audit for the TMS layer because there is no separate system.

A standalone TMS with an integration is a second system with its own security posture, its own audit, and a middleware layer you build and maintain.

Where this genuinely decides the answer:

• Government and Defence Freight: Where accreditation matters. Some native TMS products meet DoD IL5 and FedRAMP Moderate specifically because they inherit the platform’s standing.
• Enterprise Procurement: Where a second vendor security assessment adds months.
• Any contract with a customer audit clause.

The Trade-Off Is Real Though: A native TMS lives inside governor limits. High-volume rating, optimisation and telematics processing may need to happen outside – which is what Heroku exists for. A native TMS still lives inside Salesforce’s governor limits, so teams need to understand those platform constraints before putting high-volume rating, optimization, or telematics workloads inside the org.

The Integration Surface

Table of logistics integration systems including carrier APIs, telematics, TMS, customs, EDI, and track-and-trace with what flows and what to watch for

Volume is the defining technical problem in logistics Salesforce.

A tracking event every few minutes, per shipment, across thousands of active shipments, generates more records per day than almost any other industry. A naive custom object model breaks quickly – that’s a Data 360 conversation, with only material events surfaced into CRM.

Three more things worth planning for:

• Every Carrier API is Different: Rate structures, booking flows, tracking formats, and rate limits vary by carrier, and there are a lot of carriers. This is where integration effort accumulates.
• EDI Is Still The Backbone. X12 and EDIFACT remain how much of the industry actually exchanges orders, invoices, and status. Any partner who only wants to talk about REST APIs hasn’t worked in freight.
• Customs and forwarding Platforms use regulated formats and rarely have modern APIs. Budget accordingly.

Related: Salesforce API integration · Salesforce integration guide

What Logistics Businesses Actually Build

This is where Salesforce Development Services adds value: extending the TMS with customer-facing and operational capabilities specific to your business, rather than rebuilding the transportation core.

• Customer Visibility Portals: Shipment status, documentation, exception notifications, self-service booking. Experience Cloud, almost always custom, because customer experience is where freight businesses compete.
• Pricing and Rating Logic: Fuel surcharges, accessorials, contract rates, spot pricing. Most TMS products handle standard rating; complex or bespoke structures usually need logic on top.
• Exception Management Workflows: Delays, damage, customs holds, failed deliveries. What happens, who’s notified, what the customer sees and how it’s resolved – highly business-specific.
• Capacity And Carrier Matching: Some TMS products now include AI-driven matching; firms with proprietary carrier scoring often build their own.
• Compliance Documentation: Dangerous goods declarations, customs paperwork, driver-hours evidence. Format-specific and consequence-heavy.
• Last-Mile Field Operations: Built on standard Field Service objects, extended for your delivery model.

Compliance Constraints

• Dangerous Goods: Classification, documentation and handling requirements are regulated internationally. Data model decisions here have legal consequences, not just operational ones.
• Customs Documentation: Format and content are specified by the destination authority. Get it wrong, and freight sits.
• Driver Hours and Safety: Hours-of-service rules in the US, tachograph and drivers’ hours regulation in Europe. Where Salesforce holds this data, it becomes evidence – treat retention and immutability accordingly.
• Cargo Liability And Claims: Evidence chains for damage and loss, with financial consequence.
• And The Platform Detail: Record-triggered Flows and Apex run in system mode, ignoring sharing entirely. Where you hold customer rate data – commercially sensitive and different per customer – that’s a genuine exposure route. Because record-triggered Salesforce Flow and Apex can execute in system mode, teams holding commercially sensitive customer rate data need to understand exactly which automation is accessing that information and under what sharing model.

Related: Salesforce compliance and data security

What It Costs

Indicative bands, excluding Salesforce and TMS licences:

• That Last Row Is The One To Think Hard About: It’s what you avoid by buying a native TMS, and it’s rarely the best use of a logistics business’s development budget.
• Carrier Integrations Compound: One is a project; fifteen is a programme. If your model depends on breadth of carrier coverage, that’s the line item that grows – and it’s a strong argument for a TMS that already maintains those connections.

The Mistakes That Cost Most

Building a shipment and load model from scratch when a mature native TMS exists.

• Rebuilding Field Service: Work Order and Asset are standard.
• Putting telematics in custom objects: Volume will overwhelm them.
• Underestimating carrier API breadth: Each one is different.
• Assuming REST APIs: EDI is still the backbone of freight.

Choosing a standalone TMS in a regulated contract without accounting for the second security audit.

Storing customer rate data without checking system-mode exposure.

Where to Go Next

For the build decision, custom Salesforce development and configuration vs customization.

For handling volume outside the platform, Heroku for Salesforce and governor limits.

For integration, Salesforce integration and Salesforce API integration.

For budgeting, Salesforce customization cost.

For access and evidence obligations, Salesforce compliance and data security.

The complete Salesforce development guide is the hub.

Before You Scope a Logistics Build

We’re a development company, and logistics is the industry where we most often recommend buying rather than building.

The native TMS products here are mature in a way that AppExchange apps in other sectors aren’t, and rebuilding a shipment and load model from scratch is rarely the best use of a freight business’s budget.

Where custom genuinely earns its place is the layer above – customer portals, pricing logic, exception handling, and the integration surface. That’s a real conversation, and it usually takes about an hour.

We’re a certified Salesforce Consulting Partner with developers, architects and consultants across the US, UK, Australia, Canada, UAE and India.