FTM vs Aljex:
Brokerage TMS
Architecture Review
Compare Descartes Aljex and FTM through an enterprise buyer lens: brokerage workflow fit, Salesforce-native architecture, reporting ownership, automation, implementation scope, and the operating model your team wants to scale into.
Where Each Platform Fits
Descartes Aljex is a cloud-based TMS built for freight brokers and 3PLs. FTM is a Salesforce-native transportation platform for brokers, carriers, shippers, and mixed operations. The decision comes down to operating model: a dedicated brokerage TMS, or transportation workflows that live inside the same Salesforce environment as customer, financial, and reporting data.
Transportation Platform Evaluation Framework
Organized around the criteria transportation executives, operations leaders, and technology buyers typically use when evaluating a TMS investment.
| Evaluation Area | FTM | Aljex | Buyer Consideration |
|---|---|---|---|
| Salesforce requirement | No existing Salesforce deployment required. FTM can be deployed into an existing Salesforce environment or launched with Salesforce provisioned as part of the implementation | Standalone cloud-based platform. No Salesforce dependency | Determine whether Salesforce alignment is strategically valuable for your organization now or in the future |
| Architecture | Salesforce-native: loads, carriers, quotes, invoices, and customer records live as native Salesforce objects in a single data environment | Standalone broker-focused TMS connected to other systems through EDI and API integrations | Evaluate where transportation data should live relative to your CRM, accounting, and reporting systems |
| Customer visibility | Customer Portal built on Salesforce Experience Cloud, connected to the same customer records used by sales and finance | Shipment visibility and tracking tools for customer-facing updates. Review portal depth and CRM connectivity with vendor | Evaluate whether customer visibility needs to connect to your CRM and account history or operate as a standalone tracking layer |
| Carrier visibility | Carrier records, compliance, and performance data live in Salesforce alongside dispatch and billing activity | Centralized carrier management from a single location, including onboarding and selection workflows | Both platforms centralize carrier data. Evaluate whether that data needs to be visible outside the TMS itself |
| Dispatch management | Real-time dispatch console inside Salesforce with load assignment, milestone tracking, and carrier communication | Core dispatch, load tendering, and carrier matching built specifically for broker workflows | Review dispatch workflows hands-on. The deeper question is what dispatch data connects to after a load is booked |
| Reporting and executive reporting | Native Salesforce Reports and Dashboards combining operational, carrier, customer, and financial data in one environment | Analytics and business intelligence dashboard for tracking the transportation cycle. Review whether reporting extends beyond transportation data | Assess whether executive reporting needs to combine transportation data with financial and customer data in one view |
| Workflow automation | Salesforce Flow and AutoFill automate record creation, matching, and document processing across broker, carrier, and shipper workflows | Automated order entry, load tendering, and invoicing built for broker-specific processes | Map your required automation. Aljex automates broker workflows; FTM automates across broker, carrier, and shipper operations in one system |
| Document management | Native document generation and attachment within Salesforce load records, connected to the same customer and financial data | EDI messaging and document handling for bills of lading, load tenders, and invoicing across trading partners | Evaluate whether your trading partners require EDI connectivity and how each platform supports that requirement |
| Financial visibility | Invoicing and billing connected directly to Salesforce financial and customer records, with no separate export step | Freight invoicing dashboard with detailed financial reporting for transportation activity | Evaluate whether financial visibility needs to connect to broader accounting and business systems or remain transportation-specific |
| Customization and admin flexibility | Configurable through Salesforce: fields, workflows, automation, and reporting adjustable by internal admin without vendor involvement | Configuration options within the platform. Review customization depth and admin control with vendor | Evaluate how much ongoing configuration your team expects to manage internally versus through vendor support |
| Multi-entity operations | Supported through Salesforce architecture and FTM configuration flexibility | Review multi-entity and multi-branch support with vendor before committing | Define multi-entity requirements before evaluation. Platforms vary in how they handle separate business units |
| Workflow coverage | Broker, carrier, shipper, and mixed operations in one Salesforce environment | Broker and 3PL focused. Review carrier, shipper, and mixed-operation requirements with vendor | Map all current and planned workflows. Evaluate whether each platform supports the full scope in one system |
| Implementation approach | Structured rapid deployment; core workflows live in approximately 14 days when scope is aligned | Review implementation timeline, onboarding process, and setup fees with vendor during evaluation | Clarify implementation timeline, setup costs, and the scope definition process with each vendor |
| Scalability | Scales with Salesforce infrastructure. Workflow, data, reporting, and user capacity expand without platform migration | Used by brokerages of varying sizes handling high shipment volume. Review scalability and pricing tiers with vendor as operations grow | Evaluate each platform against your expected volume, entity count, and reporting complexity in three years, not today |
| Best-fit buyer profile | Growing brokerages, mixed operations, and organizations seeking transportation, customer, and financial data unified inside Salesforce | Broker-focused operations with relatively straightforward workflow requirements centered on dispatch and execution | Match platform architecture to where your operation will be in three years, not only where it is today |
| Ready to evaluate FTM? | Book Executive Demo → | ||
Aljex data is provided as general buyer context drawn from publicly available information, not verified vendor claims. Review all capabilities directly with each vendor during your evaluation process.
Two Different Ways to Own Transportation Data
This comparison is less about a feature checklist and more about data ownership. Aljex gives freight brokerages a dedicated TMS environment. FTM puts transportation records inside Salesforce, where customer, carrier, shipment, billing, and reporting data can share one operating layer.
Loads, quotes, carriers, invoices, documents, customer records, workflows, and dashboards live in the same Salesforce environment. Teams use Salesforce permissions, automation, reporting, APIs, and AppExchange extensibility without creating a separate transportation data island.
Descartes Aljex is designed around freight broker and 3PL workflows. That model can work well when dispatch, carrier work, order entry, and freight execution are the center of the evaluation. When CRM, finance, and executive reporting need the same data, buyers should review integration depth, ownership, and maintenance.
Organizations can deploy FTM into an existing Salesforce environment or launch with Salesforce provisioned as part of the implementation. The evaluation should focus on whether Salesforce should become the operating layer for transportation data.
From Freight Document to Salesforce Record
FTM AutoFill is built around the Salesforce record model. The goal is not only to read a document. The goal is to match that document to the right customer, shipment, carrier, charge, pay item, and invoice workflow before a human approves the result.
AutoFill works against existing Salesforce records so the document can connect to the right customer, load, carrier, driver, and financial workflow.
Customer charges, carrier pay items, and invoice staging can live with the same operational record used by dispatch and management.
Teams review uncertain matches and financial values before confirming records. Automation speeds the work without removing human control.
When the TMS runs inside Salesforce, automation can act on customer, carrier, load, and billing records without crossing system boundaries.
What Changes as a Brokerage Matures
A brokerage usually starts by optimizing dispatch. As it grows, the evaluation shifts toward margin visibility, account ownership, financial close, customer experience, and internal control. These are planning questions, not claims against any single platform.
Teams need clear load status, carrier assignment, tracking, and exception handling.
Leadership needs margin, accessorials, billing status, and receivables connected to shipment activity.
Account teams need shipment context next to customer history, service issues, and revenue trends.
Admins need control over fields, approvals, automation, roles, and reporting without rebuilding the platform.
The company needs one answer for where customer, carrier, shipment, document, and billing records should live.
Brokerage teams may add carrier, shipper, portal, or mixed-operation workflows as the business model expands.
Transportation Operations Extend Beyond Dispatch
Dispatch is one component of a transportation platform. FTM supports the full range of freight operations as native Salesforce functionality. Every workflow produces and updates Salesforce records without external system handoffs or data re-entry.
What Transportation Leaders Should Plan For
Implementation scope and change management are among the most consequential decisions in a TMS evaluation. The questions below apply regardless of which platform your team selects.
Decide What Should Own the Freight Record
For broker-focused teams, the platform decision should start with one practical question: should freight records stay inside a dedicated TMS, or should they connect directly to the operating layer used by sales, finance, operations, and leadership?
Before comparing feature lists, define where the source of truth should live for loads, customers, carriers, billing, documents, and reporting.
A dedicated broker TMS can fit teams that mainly need load entry, dispatch, carrier communication, and invoicing inside a focused transportation workflow.
Good question: is dispatch the full operating scope?A Salesforce-native model fits when customer history, carrier performance, freight activity, billing, and executive reporting need to connect without exports.
Good question: who else needs the freight record?Clarify who should own fields, automations, approvals, permissions, dashboards, and workflow changes after launch.
Good question: vendor ticket or internal admin?Review whether brokerage workflows may expand into carrier operations, shipper workflows, portals, onboarding, or document automation.
Good question: what will the platform need to support next?Questions to Ask Any Vendor
Platform fit and commercial fit are separate decisions. Use these questions during any vendor evaluation, regardless of which platform you are considering.
When Each Option Makes Sense
Use this summary alongside a hands-on vendor evaluation. Platform fit depends on your operating model, technology environment, team structure, and implementation priorities. No comparison page replaces a direct product review.
Review your brokerage TMS architecture with FTM.
Discuss brokerage workflows, Salesforce architecture, reporting visibility, automation, implementation scope, and platform fit. No prior Salesforce deployment required.
