Manufacturing SystemsERP Platform

Salesforce Field Service + ERP AI

Salesforce Field Service AI Integration: Private AI Joined to ERP Stock and Contracts

Short answer

Private AI for Salesforce Field Service reads WorkOrder, ServiceAppointment, ServiceResource and Asset records through Salesforce APIs, joins them to ERP inventory, contracts and cost, and answers with the query and sources shown. It complements Salesforce's own AI where data must leave the CRM or the model must stay on your hardware.

ERP
Salesforce Field Service
Industries
Industrial Equipment, Medical Devices, Electronics, Energy
Written for
Head of Field Service Operations

Salesforce Field Service is built from familiar Salesforce objects: WorkOrder and WorkOrderLineItem for the job, ServiceAppointment for the visit, ServiceResource and ServiceTerritory for who and where, Skill and ServiceResourceSkill for capability, Asset and MaintenancePlan for the equipment, and ProductItem, ProductRequired and ProductConsumed for parts. A scheduling optimiser decides the visits. What it cannot see is the manufacturer's ERP.

That gap defines the useful AI work. Dispatchers want to know whether the part for tomorrow's appointment is truly in the technician's location. Service finance wants to know whether a contract is profitable after parts and labour. Quality wants to link a field repair to the production lot. Each answer starts in Salesforce and ends in the ERP.

Salesforce provides its own AI capabilities for service, and for CRM-contained questions they are the simplest route. Netray's role is narrower: where regulated data cannot go to a hosted model, where open-weight models are required, or where the answer needs live ERP tables that Salesforce does not hold.

The approach is retrieval over Salesforce and ERP data with the asking user's permissions applied, models served inside your boundary, and anything written back held as a draft for a person to approve.

What usually gets in the way

The problems we hear most from head of field service operations teams running Salesforce Field Service.

Scheduling optimisation ignores real ERP stock

ProductItem balances in Salesforce are only as current as the sync from the ERP. Appointments get booked against parts that were consumed or reserved elsewhere hours ago.

Service contract profitability is invisible

Revenue sits in the ERP general ledger, costs in work orders and parts consumption. Nobody sees margin by contract line without a manual join.

Asset records drift from what was shipped

The Asset in Salesforce may not match the ERP serial, revision or configuration, which causes wrong parts lists and wrong warranty dates.

Report building is a queue

Operations leaders request cross-object reports from a small admin team. By the time the report arrives, the question has moved on.

Hosted AI is blocked by data policy

Security teams in defense, medical and critical infrastructure restrict customer site and equipment data from third-party model endpoints.

Where AI earns its place in Salesforce Field Service

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Appointment readiness check

For tomorrow's ServiceAppointments the agent checks ProductRequired against ProductItem and ERP warehouse balances and lists appointments at risk of a part shortage.

Touches: ServiceAppointment, WorkOrderLineItem, ProductRequired, ProductItem, ERP item warehouse balance and open PO lines

Outcome: Dispatchers see risk lists before the day starts, which reduces same-day reschedules caused by parts.

Contract margin explanation

A finance analyst asks why a service contract's margin dropped. The agent joins ProductConsumed, labour time and ERP cost to the ServiceContract and ERP invoice lines.

Touches: ServiceContract, ContractLineItem, WorkOrder, ProductConsumed, ERP invoices and standard cost

Outcome: Margin commentary traceable to source records, instead of hand-built spreadsheets.

Asset and ERP serial reconciliation

The agent finds Assets whose serial, product or install date disagree with ERP shipment records and proposes corrections for review.

Touches: Asset, Product2, ERP shipment lines, serial master

Outcome: A prioritised clean-up list that improves warranty and parts accuracy over time.

Skill gap and territory coverage questions

A manager asks which territories lack technicians with a certain skill for the installed base there. The agent combines ServiceResourceSkill, ServiceTerritoryMember and Asset density.

Touches: ServiceResource, ServiceResourceSkill, ServiceTerritoryMember, Asset, ServiceTerritory

Outcome: Training and hiring decisions grounded in coverage data, with the logic visible.

Repeat visit root cause review

The agent groups work orders that required a second visit within a window and reads closing notes to summarise causes such as wrong part, missing skill or unclear diagnosis.

Touches: WorkOrder, ServiceAppointment, work order notes, ProductConsumed

Outcome: A defensible breakdown of first-time-fix failures to focus on, with representative cases.

Maintenance plan generation review

For MaintenancePlan and MaintenanceAsset records the agent compares generated work against actual failures and ERP part usage, proposing interval reviews.

Touches: MaintenancePlan, MaintenanceAsset, WorkType, WorkOrder, ERP part issues

Outcome: A shortlist of plans to revisit; the service engineer decides.

Return and RMA follow-up

The agent tracks ReturnOrder records against ERP receipts and credit memos and flags returns that have not closed in the ERP.

Touches: ReturnOrder, ReturnOrderLineItem, ERP RMA receipts, credit memos

Outcome: Fewer orphaned returns and faster credit processing.

Reference architecture

A Salesforce connector and an ERP connector feed a governed retrieval layer. Open-weight models answer inside your boundary, and every response cites its queries and records.

  1. 1

    Salesforce connector

    REST API and SOQL for queries, Bulk API 2.0 for backfill, Change Data Capture for updates, using an integration user with a permission set scoped to Field Service objects.

  2. 2

    ERP connector

    Read-only SQL views or APIs onto items, warehouse balances, purchase orders, invoices, serials and cost.

  3. 3

    Semantic layer

    Definitions for first-time fix, repeat visit, parts-on-hand and contract margin, so numbers are consistent across questions and users.

  4. 4

    Model serving

    Llama, Qwen, Mistral or gpt-oss class models on vLLM or Ollama in your data centre or private cloud, with versions pinned.

  5. 5

    Guardrails and audit

    Role-aware retrieval, visible queries, logged answers and an approval step for any proposed update to Salesforce or the ERP.

Integration notes for your ERP team

  • Use a dedicated integration user and permission set covering WorkOrder, ServiceAppointment, ServiceResource, Asset and parts objects only.
  • ProductItem balances reflect the last inventory sync, so the AI should read ERP balances directly for availability questions and show both values.
  • Salesforce API request limits are per org, so plan Bulk API 2.0 backfills and Change Data Capture to avoid starving other integrations.
  • Honour sharing rules, territories and field-level security when filtering retrieval.
  • Map Asset to ERP serial and item before building any warranty answer; decide the system of record for each attribute.
  • Keep appointment scheduling in the Salesforce optimiser; the AI should explain and recommend, not override schedules.

Deployment options

On-prem models, controlled Salesforce egress

Regulated manufacturers with strict AI data policies

Inference and indexes stay in your data centre. Salesforce reads are limited to approved objects and fields over a defined network path.

Private cloud in your tenancy

Companies that need regional residency but lack GPUs

The stack runs in your cloud account with private networking, customer-managed keys and no shared endpoints.

Sandbox-first pilot

Teams that must prove accuracy before production access

A partial copy sandbox with masked customer data is used to test question quality and permission behaviour.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

ITAR and EAR

Controlled equipment data is processed inside the boundary you define. Netray does not claim export registration; the design supports your own controls.

GDPR and local labour rules

ServiceResource locations and performance data can be excluded or pseudonymised in the index to support works council agreements.

ISO 13485 and FDA QMSR for device servicing

Read-only access and reviewed drafts keep service records under your quality system's control.

SOC 2 and customer security reviews

Integration users, audit logs and network paths are documented so your security team can assess them. No certification is claimed by Netray.

How an engagement runs

Phase 1 . 2 weeks

Discover

  • -Object and field map for Field Service in your org
  • -Priority questions and source systems
  • -Security and deployment boundary decision

Phase 2 . 4 weeks

Build

  • -Salesforce and ERP read connectors
  • -Semantic definitions for service KPIs
  • -Sandbox environment with masked data

Phase 3 . 4 weeks

Pilot

  • -Assistant for dispatch or service finance
  • -Accuracy and permission tests
  • -User feedback log

Phase 4 . Ongoing

Operate

  • -Production rollout and monitoring
  • -Approval workflow for write-back
  • -Quarterly review of definitions and models

Questions to ask any vendor, including us

A short list that separates real Salesforce Field Service AI work from a chatbot demo.

  1. What can Salesforce's own AI answer without an ERP join?
  2. Which Field Service objects and fields are indexed?
  3. How is ProductItem staleness handled against live ERP stock?
  4. How are territory and sharing rules enforced?
  5. What API call volume will the connector consume?
  6. Can answers show the SOQL and SQL used?
  7. Where do models run and who controls updates?
  8. What is logged and for how long?

Frequently asked questions

Does Salesforce Field Service already have AI?

Salesforce offers AI features for service, and they work best on data inside Salesforce. A private layer makes sense when answers need live ERP data, when data policy blocks hosted models, or when you want open-weight models you operate. It is a complement, not a replacement for the scheduling optimiser.

Can the AI change appointments or dispatch automatically?

It can propose, but we recommend it does not. Scheduling stays with the Salesforce optimiser and dispatchers. The AI explains why an appointment is at risk and suggests actions that a person approves, which avoids conflicts with optimisation rules.

How does it avoid showing data a user should not see?

Retrieval is filtered by the asking user's sharing rules and field-level security, or indexes are partitioned by role. The pilot should include tests using low-privilege users to prove restricted records do not appear in answers.

What ERP data does it need?

Typically item master, warehouse balances, open purchase orders, serial or lot records, invoices and standard cost. Access is read-only through SQL views or APIs. The exact tables depend on whether you run NetSuite, SyteLine, SAP, Dynamics or another ERP.

How current is the data?

Change Data Capture keeps Salesforce data close to real time, and ERP reads for availability questions go to the live source. Notes and documents are indexed in batches or on change events. Each answer should state the data timestamp.

Is on-prem possible with a cloud Salesforce?

Yes for the AI layer. Models, indexes and ERP connectors run on your infrastructure and pull only approved Salesforce fields over a controlled path. Salesforce itself remains a cloud service, so residency of the CRM data is decided by your org's region.

How long does a first version take?

A scoped pilot, such as appointment readiness for one territory, usually takes about two months from discovery to a working assistant, depending on ERP access and data quality of serial and item keys. Broader rollouts depend on how many questions and teams are included.

Talk it through with an engineer who knows Salesforce Field Service

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.