Sage 300 and Microsoft Dynamics 365 Sales integration

What moves between them

Customer records flow from Sage 300 AR into Microsoft Dynamics 365 Sales accounts. ARCustomers from Sage 300, including customer number, name, address, and AR status, are mapped to Dynamics 365 Sales account records. Contact records can be created from Sage 300 AR contact information. The sync runs on a polling schedule since Sage 300 offers no webhooks, with OData filters to retrieve only new and changed records since the last poll. Changes to Sage 300 customer records are picked up on the next scheduled sync and upserted into Dynamics 365 Sales accounts.

How ml-connector handles it

ml-connector stores the Sage 300 API URL and uppercase Basic Auth credentials encrypted, and it stores the Dynamics 365 Sales OAuth 2.0 client credentials encrypted. For Sage 300, it encodes credentials into the Authorization header on every request and polls the ARCustomers endpoint with OData filters on DocumentDate and pagination to retrieve customer records in batches. Because Sage 300 is pull-only with no webhooks, polling is scheduled on a regular cadence that you define. For Dynamics 365 Sales, ml-connector refreshes the OAuth 2.0 bearer token before expiry and writes accounts via the Dataverse Web API. It maps Sage 300 customer attributes to Dynamics 365 Sales account fields such as name, address, phone, and custom fields. If a 256 KB webhook payload limit is hit on the Dynamics 365 Sales side, ml-connector batches the write operations to stay under the limit. Every sync carries a full audit trail with timestamps, record counts, and error details.

A real-world example

A mid-market wholesale distributor runs Sage 300 for accounts receivable, inventory, and purchasing, and uses Microsoft Dynamics 365 Sales for pipeline and opportunity management across a national sales team. Before the integration, the sales team entered new customers into Dynamics 365 Sales manually, and AR staff created them in Sage 300, leading to duplicate records, mismatched credit limits, and confusion about which system held the truth. Sales reps called AR to confirm customer status before closing deals. With Sage 300 and Dynamics 365 Sales connected, new customers created in Sage 300 appear automatically in the CRM, sales reps see current AR balance and payment status on the account record, and credit holds in Sage 300 sync to Dynamics 365 Sales so reps are prevented from creating orders for customers on credit block.

What you can do

• •Sync Sage 300 AR customers into Dynamics 365 Sales accounts with address, phone, and custom field mapping.
• •Keep customer master data aligned between the financial system and the CRM so sales and AR work from the same record.
• •Poll Sage 300 on a scheduled cadence and upsert new and changed customers into Dynamics 365 Sales accounts.
• •Authenticate Sage 300 with HTTP Basic Auth and uppercase credentials, and Dynamics 365 Sales with OAuth 2.0 client credentials.
• •Track every sync in an audit trail with record counts, errors, and timestamps so you can verify data integrity.

Questions

Which direction does data move between Sage 300 and Microsoft Dynamics 365 Sales?

The main flow is from Sage 300 into Dynamics 365 Sales. Customer records from Sage 300 Accounts Receivable are synced into Dynamics 365 Sales accounts. Changes to customer details in Sage 300 flow into Dynamics 365 Sales on the next scheduled poll.

Does ml-connector support real-time sync between Sage 300 and Dynamics 365 Sales?

Sage 300 has no webhook system, so ml-connector uses polling on a schedule you define. Dynamics 365 Sales supports webhooks, so once a record is in Dynamics 365 Sales, ml-connector can optionally receive real-time notifications of changes. The initial customer sync from Sage 300 is always poll-based.

How does ml-connector handle authentication for both systems?

Sage 300 uses HTTP Basic Authentication with uppercase username and password, which ml-connector encodes in the Authorization header on every request. Microsoft Dynamics 365 Sales uses OAuth 2.0 client credentials, which ml-connector exchanges for a bearer token via Microsoft Entra ID. Both credential sets are stored encrypted.