How should SYSPRO integrate with Dynamics 365 Sales?

A useful SYSPRO integration gives a salesperson an availability-to-promise answer, not a copied stock number. Dynamics 365 Sales should show what quantity can be supplied, from which warehouse and on what date, while SYSPRO remains responsible for inventory, demand, planned supply, manufacturing jobs and production lead times.

That boundary is specific to a manufacturing and distribution ERP. It makes this project different from a customer-and-order synchronization with Sage 300 or a broad SAP architecture exercise.

What should a salesperson see before promising a delivery date?

The salesperson needs a dated, attributable promise: quantity, warehouse, earliest supply date and the time SYSPRO checked it. A single “in stock” field is insufficient because existing sales allocations, production demand, purchase orders, jobs and transfers can change what is genuinely available for a new customer commitment.

SYSPRO documents an Inventory Available to Promise query for a stock-code and warehouse combination. Its ATP view can include planned supply and demand from sales orders, work-in-progress allocations and supply-chain transfers. The CRM should surface the result needed for the sales decision, not reproduce the calculation.

The timestamp matters. An answer checked yesterday is context, not a commitment. Before a quotation becomes an order, the integration should request a fresh decision or require an explicit revalidation.

Why is stock on hand not a delivery promise?

Stock on hand describes physical quantity; availability subtracts commitments, and ATP also considers dated future supply and demand. A warehouse may physically contain units that are allocated to other sales orders or production. Conversely, a future job or purchase order may support a later promise even when today’s available quantity is zero.

For example, 100 units on hand and 90 already allocated can leave only 10 currently available. That still does not answer whether 40 more units can be promised next week: the date depends on planned production, incoming supply, new demand and the warehouse rules applied by SYSPRO.

Multi-warehouse distribution adds another decision. Stock at a second site is not automatically sellable from the first one; transfer time, permissions, replenishment rules and the customer’s delivery route can matter. Dynamics 365 should not merge all warehouse balances into one reassuring but unusable total.

Should production structures be copied into Dataverse?

Detailed bills of materials, operations, component allocations and production jobs should normally remain in SYSPRO. Dynamics 365 Sales needs the commercial consequence of that structure: whether an item can be supplied, the expected date, the relevant configuration, a job milestone and any exception that requires customer communication.

Copying an entire bill of materials into Dataverse creates a second manufacturing model that must be secured, synchronized and reconciled after every engineering or planning change. It also tempts CRM automation to infer a delivery date without the complete planning context.

A deliberately small CRM projection can include:

• the SYSPRO stock code and sellable description;
• make-to-stock or make-to-order classification when useful to sales;
• a configuration or revision label required on the quotation;
• manufacturing lead time as reference information, not a live promise;
• the latest promised quantity, date, warehouse and checked-at timestamp;
• a high-level job or fulfilment status after order acceptance.

SYSPRO’s lead-time calculation can incorporate operations, movement, non-working days and subcontract conditions. A static number copied to CRM must therefore be labelled as reference data and never presented as a newly calculated commitment.

Which SYSPRO interfaces are suitable for the integration?

Microsoft’s connector catalogue does not list a first-party SYSPRO connector as checked on 14 October 2026. The supported route starts with the interfaces available in the customer’s SYSPRO release: read-only OData for controlled queries and licensed e.net business objects, exposed through supported SYSPRO services, for business logic and transactions.

Power Automate can fit a limited business-owned process. Azure Logic Apps or a dedicated integration service is more suitable when the availability call is operationally critical, must cross a private network, needs queueing, or requires technical monitoring and controlled replay.

This resembles the interface discipline described in Sage 300 and Dynamics 365 Sales integration, but the business decision is different: SYSPRO must contribute manufacturing and warehouse evidence to a delivery promise.

Why is direct database access rejected?

Direct SQL is not an operational integration interface. SYSPRO’s own guidance recommends e.net business objects for business logic and identifies OData as the controlled read-only alternative. Direct access weakens traceability, ties the solution to internal tables, complicates upgrades and can affect performance, availability, service levels and licensing.

The prohibition is strongest for writes. Creating or changing customers, orders, jobs or allocations directly in tables can bypass validations that the ERP applies through its business-object layer. A successful SQL statement does not prove that SYSPRO accepted a valid business transaction.

Read-only analytics against a governed platform is a separate requirement. Even there, the current SYSPRO documentation positions OData and Business Activity Queries as the managed routes, especially because direct database access is unavailable in SYSPRO Cloud ERP.

Which system should own each industrial data decision?

SYSPRO should own production, warehouse and fulfilment facts; Dynamics 365 should own the opportunity, relationship and next commercial action. Shared records need field-level ownership, but the decisive rule is simpler: CRM may display an ERP conclusion without becoming the application that recalculates or silently overwrites it.

This table is a decision framework, not a universal configuration. A make-to-order manufacturer and a distributor can use the same products while requiring different validation, ownership and response-time rules.

How should an availability-to-promise request flow?

The first integration flow should answer one bounded sales question and retain enough evidence to audit the answer. Start with a product, requested quantity, required date and permitted warehouse context; return a SYSPRO result with a correlation identifier, timestamp and explicit outcome rather than synchronizing the whole manufacturing model.

1. The salesperson selects the SYSPRO-linked product, quantity and requested delivery date in Dynamics 365.
2. Dataverse validates that the product has a stable SYSPRO stock code and that the account is correctly matched.
3. The orchestration layer attaches a correlation identifier and resolves the eligible company and warehouse context.
4. The supported SYSPRO interface retrieves the availability or ATP evidence required by the agreed rule.
5. The response returns quantity, date, warehouse, status and checked-at time; a technical failure returns no promise.
6. Dataverse stores the response as a quotation snapshot and displays its age to the salesperson.
7. Before order submission, the flow revalidates the promise and uses a separate, idempotent transaction to create the SYSPRO order.

The read and the commitment are deliberately separate. A quotation check must not reserve stock unless the business process explicitly defines that behaviour, and a sales-order submission must not be replayed blindly after a timeout.

What changes between make-to-stock and make-to-order sales?

Make-to-stock selling starts from inventory and planned replenishment; make-to-order selling starts from the capacity to produce a configured quantity by a required date. The CRM screen can look similar, but the SYSPRO evidence, confidence level and point at which a date becomes binding are different.

For a manufactured item, a published lead time is not automatically the answer. It may assume materials are available and capacity conditions are satisfied. The integration should present the result of the agreed SYSPRO planning decision, not add a lead-time number to today’s date inside CRM.

What must happen when the promised date changes?

A changed promise must create a visible commercial exception, not silently overwrite yesterday’s date. The integration needs to identify the affected quotation or order, preserve the previous answer, show the revised SYSPRO result and assign a next action to the person responsible for customer communication.

The monitoring design should distinguish:

• a component shortage or production-job delay;
• new demand that consumes previously available supply;
• a warehouse transfer or replenishment change;
• an invalid product, customer or warehouse mapping;
• an authentication, endpoint or network failure;
• a timeout after a transaction may already have succeeded.

Each exchange requires a correlation identifier and an idempotency rule. Operational alerts should name the business object, affected customer commitment and recovery owner; a generic failed-flow notification is not enough for a sales team to act.

What must be known before estimating the integration?

A credible estimate requires the actual SYSPRO environment and one precisely defined sales decision. “Connect SYSPRO to CRM” does not reveal whether the first flow is a read-only warehouse query, an ATP request, a customer match or a transactional sales-order submission, and those scopes carry different risks.

Confirm these ten points before estimating:

1. SYSPRO release, deployment model and companies in scope;
2. licensed e.net functional areas and Data Connector - OData availability;
3. supported endpoints, network path, authentication and certificate ownership;
4. first sales question to answer and the user action that triggers it;
5. make-to-stock, make-to-order or mixed fulfilment model;
6. products, bills of materials, jobs and warehouses involved;
7. ATP rule and the authority that validates the promised date;
8. average and peak request volume and acceptable response time;
9. replay, reconciliation and exception-ownership rules;
10. named SYSPRO specialist responsible for ERP configuration and acceptance.

Benly Consulting delivers the Dynamics 365, Dataverse, mapping and Microsoft orchestration scope. The customer’s SYSPRO administrator, partner or specialist validates the ERP release, licences, endpoints, business objects, security and manufacturing rules. Our ERP integration approach explains that responsibility split.

Use the Dynamics 365 budget estimator for an initial range. The project amount is confirmed only after the supported interface and first industrial flow are validated; no SYSPRO-specific project price is invented here.

Verified official sources

Sources checked on 14 October 2026:

• SYSPRO Help — SYSPRO OData Service
• SYSPRO Help — Inventory Available to Promise Query
• SYSPRO Help — Warehouse Maintenance for Stock Code
• SYSPRO Help — Lead Time Calculation
• SYSPRO Help — Business Objects
• SYSPRO Help — Best practice for connecting to SYSPRO
• Microsoft Learn — Power Automate connector catalogue
• Microsoft Learn — custom connectors overview
• Microsoft Learn — use upsert with Dataverse