How Commerce 365 integration works
Overview
Commerce 365 for Magento is a Business Central extension that synchronizes your Business Central data with your Magento 2 webshop. When you create or update items, customers, categories, inventory, or other entities in Business Central, Commerce 365 detects those changes and sends them to Magento through the Commerce 365 API.
The integration works in one direction for catalog data: from Business Central to Magento. Orders and other transactional data flow from Magento into Business Central through a separate import mechanism.
The outbound synchronization follows a three-stage pipeline:
- Change Detection: Commerce 365 detects that a record was inserted, modified, renamed, or deleted.
- Queueing: The detected change is placed in the Synchronization Queue as a queued entry.
- Synchronization: The queued entry is processed, transformed into an API payload, and sent to Magento through the Commerce 365 API.
How stage 1 (change detection) works depends on which Integration Method you choose. Stages 2 and 3 are the same regardless of the method.
Integration Methods
Commerce 365 supports three integration methods. The method is configured in the Commerce 365 Setup page under the Application section.
Active
The default method. Commerce 365 hooks into Business Central's database trigger system. Every time a record is inserted, modified, deleted, or renamed in a monitored table, the change is intercepted in real time and recorded in an intermediate Integration Entry table. The entry is marked for synchronization with a flag.
When the synchronization job queue runs, all flagged Integration Entries are transferred to the Synchronization Queue and processed. An integration hash mechanism prevents unchanged records from being queued — if a record is saved but no monitored field values actually changed, it is skipped.
This method provides reliable real-time change detection. The trade-off is a small amount of processing in the user's session for every write operation on a monitored table.
Active (background)
Like Active, this method uses real-time database triggers to detect changes. The difference is in how changes are queued. Instead of writing to an Integration Entry table during the user's transaction, the system creates a lightweight Integration Task record and schedules it for execution via Business Central's Task Scheduler.
The background task runs in a separate session, typically within seconds, and creates the corresponding Synchronization Queue entry. This means the user's transaction completes faster because the queueing work is offloaded.
If the Task Scheduler is unavailable (for example, during an upgrade), the task falls back to processing in the current session.
Passive
This method does not use real-time database triggers for inserts, modifications, or renames. Instead, change detection happens at synchronization time by polling. Commerce 365 queries each monitored table for records where the system modification timestamp (SystemModifiedAt) is newer than the Last Queue Load timestamp stored on the Integrated Entity. All matching records are placed in the Synchronization Queue and processed.
The one exception is deletions. Because deleted records cannot be discovered by polling, deletions are still intercepted in real time via database triggers.
This method has the lowest performance impact on day-to-day user operations. The trade-off is that changes are not detected until the next synchronization run, so there is a delay equal to the job queue recurrence interval.
Choosing a Method
| Active | Active (background) | Passive | |
| Change detection | Real-time triggers | Real-time triggers | Polling at sync time |
| Impact on user sessions | Moderate | Low | Minimal |
| Time to queue | At sync time (batch transfer) | Seconds (background task) | At sync time (polling) |
| Deletion handling | Real-time | Real-time | Real-time |
| Maturity | General Availability | Preview | Preview |