Outbridge | Embedded Integration for Microsoft Dynamics 365 Finance and Operations
Run your Dynamics 365 Finance and Operations integrations from inside D365, not from another vendor's cloud.
Outbridge installs as a model inside Microsoft Dynamics 365 Finance & Operations. Configure recurring imports, exports, file flows, and webhook-driven processing in the F&O admin UI; execution runs in the D365 batch framework; run history and payloads stay in the ERP your team already operates. The only external piece is an optional Web Relay for webhook ingress.
What Outbridge handles
Four scenarios, configured in the F&O admin UI.
Four situations F&O teams bring us. If one of them reads like your week, Outbridge was built for it.
Recurring file exchange
Your 3PL wants its feed by 06:00, the bank drops statements on SFTP, and the on-prem warehouse system only speaks flat files. Every one of those flows lives in a different tool today, and failures surface days later.
In Outbridge each flow is one configured data port, either direction: source, target (FTP / SFTP / Azure Storage / SharePoint), schedule; sequencing through port groups. Folder-watch picks up inbound files, the processor pipeline transforms before commit, failed records are quarantined with payloads kept in Run history; fix the data and rerun the port. Systems that only exchange files need no API on their side.
Upgrading from AX 2012
Tons of AX 2012 data have to make it to the cloud: masters, open balances, documents, history. They get exported, transformed, and loaded into D365, usually more than once before the loads come out clean. And the AIF ports that fed AX for a decade do not carry over, because AIF does not exist in D365.
Outbridge turns both jobs into configuration inside D365. You export from AX 2012; Outbridge transforms in the processor pipeline and loads through data entities, rerun until clean, every run logged. File-based AIF flows are re-implemented as configured data ports, recurring API exchanges as request groups. The ports you configure for the migration keep running after go-live.
API integration by notification
The commerce platform announces "invoice 12345 ready", but D365 has no front door for events. So you poll the API every five minutes and pay for the empty calls. And when a new external system needs an API integration on a deadline, standing up middleware for one flow kills the schedule.
The Web Relay is that front door. The external system sends a minimal webhook notification; Outbridge pulls the full document on demand. The flow is configuration in F&O, with no new infrastructure to procure: bandwidth-light, and the source system stays the broker.
Complex integration on a challenging timeline
The external system pushes complete payloads and cannot wait for a fetch. If that system is one you are building, the payload changes every sprint, and each change reopens integration code sitting in middleware the F&O team cannot see into.
The Web Relay accepts the full document; Outbridge processes it asynchronously inside D365. Transforms run on XSLT 3.0 with embedded Python hooks around them, so when the payload changes, the integration is adjusted on the F&O side, quickly. Every payload stays in Run history for later investigation.
Did not see yourself in these four? The architecture review takes your top 5 integrations and names the right home for each: 30 minutes, vendor-neutral.
Inside D365
Configured in F&O. Executed in F&O. Logged in F&O.
No external runtime to provision, no separate cloud to administer, no integration mesh outside the ERP. The optional Web Relay component is a paired lightweight HTTPS endpoint used only for webhook patterns, deployed in the customer's own Azure subscription; everything else lives inside the customer's D365 environment.
Configure source, target, schedule, and processor in the F&O admin UI.
Runs inside the D365 batch framework, as batch jobs your admins already know how to manage.
Port groups orchestrate multi-step flows in D365: sequencing and dependency. A failed run reruns at the port level, against the same file or the same request to the external system.
Single Run history surface. The F&O admin who reads your batch job logs is the same person who reads this. Status, correlation ID, log entries, payload: one view.
All these surfaces live under Modules > Outbridge > Inquiries and reports and Modules > Outbridge > Setup in the F&O navigation; administration stays inside F&O.
Capabilities
What's in the box.
The four scenarios run on a configurable toolkit inside F&O. Every piece below is standard product configuration, and each card links to its page in the product documentation.
Simple text, delimited, fixed width, XML, CSV, data entity (DMF), EDI (EDIFACT, X12, TRADACOMS), API request, and webhook processors, plus an XML-to-JSON converter. A format is a configured processor.
In the docsRequest groups hold variables, with hidden variables keeping secrets out of the UI. API requests support GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS, with header substitution, and reusable templates chain multi-step API choreography.
In the docsJSON-driven mapping pulls a live sample from your environment's own OData endpoint and builds the field map from it. XSLT 3.0 in the Enhanced view covers complex shapes, with a test run before production.
In the docsEmbedded Python hooks run before the request and after the response, under platform-enforced memory and timeout limits.
In the docsEntity event groups subscribe a port to insert, update, delete, or upsert on a data entity, with field-level change tracking. "Only when the credit limit changes" is configuration.
In the docsA primary entity extends with its child entities, so a header-and-lines document exports as one message.
In the docsSettings, ports, and port groups export and import as JSON, so environment promotion moves as a controlled JSON file.
In the docsThe Web Relay authenticates with Basic, API key, or HMAC and enforces IP and domain whitelisting at the relay level, in your own Azure tenant. Outbridge ships maintain and view security roles, and installs as a standard deployable package.
In the docsFailure handling and reprocessing
What happens when something fails.
Partial failures and reprocessing are handled inside the D365 operating model your team already runs.
- Batch framework and run history Outbridge processes inside the D365 batch framework. Every run — including reruns — is logged in run history.
- Partial failure handling A failed file lands in the error folder; records with errors surface in DMF staging with per-record error detail, and failed records keep their payloads in run history.
- Reprocessing Rerun the port against the corrected file or the same request to the external system; an individual record reprocesses from the DMF project log — standard D365 DMF functionality your team already runs.
Operating model
What changes for the F&O team after Outbridge is in.
Before — typical layered estate
- Integration logic split across iPaaS UI + custom Azure Functions + Power Automate flows + native DMF
- Run history scattered across each tool's log surface; correlation across surfaces requires manual work
- Day-2 changes (mapping update, format change, schedule change) require a non-F&O developer
- Service-update wave testing requires regression across each integration platform
- Extra monitoring queue, extra access-control role, another support-team dependency
After — embedded
- Integration logic configured in F&O admin UI, executed in the D365 batch framework
- Single Run history surface, read by the same F&O admin who reads your batch job logs
- Day-2 changes happen in F&O, with no external developer handoff
- Wave testing scope reduces because the integration layer is part of D365's regression boundary
- F&O team owns the surface they already know
Use Outbridge for ERP-anchored, recurring, asynchronous D365 F&O workloads; use iPaaS for broad cross-application choreography across many SaaS systems. Many estates run both: Outbridge inside D365 for the ERP-anchored flows, iPaaS for the cross-application orchestration.
Boundaries
When NOT to use Outbridge.
Outbridge is purpose-built for asynchronous, recurring, ERP-owned integration workloads. Three situations call for a different pattern:
-
1
The integration is fully synchronous and the external system owns orchestration and error handling.
Use native OData with external retry and logging.
-
2
The integration estate is broad multi-application choreography across many SaaS systems.
Use an iPaaS.
-
3
The scope is one narrow, stable integration with low change frequency.
Custom X++ may be acceptable.
If your situation fits one of the three above, the architecture review will say so and point you to the pattern that does fit.
Before adding another platform, review the architecture.
30 minutes, free, vendor-neutral. Bring your top 5 D365 F&O integrations; we classify each by trigger, payload, ownership, and latency, and recommend the right pattern: native D365, Outbridge, iPaaS, or custom X++. You leave with a recommendation and, where Outbridge fits, a size band and a quote.
- Which of your integrations are synchronous vs asynchronous
- Which integrations are owned by D365 F&O vs orchestrated by another system
- Where external integration tooling is adding cost or operational work without improving the architecture
- Which workloads belong in native D365, embedded (Outbridge), iPaaS, or custom-X++ patterns
- Whether Outbridge is relevant for your environment, including a clear "no" if it is not
A practical review of your D365 F&O integration architecture, including where Outbridge is not the answer.