Eidea Integration Suite is an integration platform built natively for Microsoft Dynamics 365 Finance & Operations.

Bring integration orchestration into Dynamics 365 F&O.

Instead of building integrations around external API calls to F&O, orchestration and processing are moved into F&O. The Integration Suite handles both inbound and outbound integrations through configurable message- and file-based endpoints. Integration Suite handles events, message processing, validation, business logic, error handling and monitoring natively inside F&O — without making external systems responsible for orchestrating API calls into F&O.

30+ ready-to-use services
Start with predefined business services for common F&O master data and transactional processes instead of building every integration from scratch.

F&O in control
Integration orchestration and business processing run inside F&O, reducing dependency on externally orchestrated F&O API calls and their associated prioritization, timeout and throttling constraints. And most importantly F&O retains control over business logic, validation, and processing.

One integration engine
Send, receive, validate, process, log and monitor integrations through one configurable, multi-threaded integration framework. 

Configure endpoints. Don't rebuild integrations.

The Integration Suite comes with 30+ predefined integration services that can be configured and connected to one or more endpoints. A service represents the business area and contract – for example, Customer, Vendor, Project, Fixed Assets or financial journals – while the endpoint determines where data should be sent or received. This means that the same Customer service can, for example, be activated against several different recipients without having to rebuild the underlying integration logic. The endpoints are divided into two main types: Send and Receive. 

Event-driven outbound integrations

Outbound integrations are event-driven. The Integration Suite can capture insert, update and delete on data that is part of an active service. Validation can be done right down to the field level.

For example, if Customer Service is only supposed to react to specific customer fields, a change in other fields will not generate a message. Furthermore, an event is only created if the service has one or more active endpoints.

When a relevant change occurs, Integration Suite creates a separate outbound message for each active endpoint associated with the service.

This provides a natural one-to-many model:

Business event → Service → Endpoint A + Endpoint B + Endpoint C

Each endpoint can thus be processed and monitored individually.

Controlled inbound processing

Inbound integrations follow the same standardized model.

When a message is received from, for example, a queue or topic, the original payload in JSON/XML is first stored as raw data in the endpoints History log.

The message is then validated before being sent to the service's import process.

Here, the actual F&O business logic is executed, which determines whether data should be created, updated, or deleted.

This means that the transport layer is kept separate from the business logic:

Endpoint → Message → Validation → Service → F&O business logic

An API where the Integration Suite retrieves data with GET is treated in the same way as an inbound endpoint. It can be included in the central batch process or have its own execution if this particular integration needs a different frequency.

One engine for integration processing

Send and Receive are handled by a centralized multi-threaded batch engine in F&O.

The number of threads can be configured, so that the processing capacity can be adapted to the installation and the integration volume.

This eliminates the need for each integration to establish its own mechanism for scheduling, processing and execution. Integration Suite offers one common runtime for the integrations.

Built-in traceability and error handling

Each message is processed individually.

If a message fails due to, for example, data validation, duplicates or other business logic, a separate error log is created associated with the message.

Together with the ability to store the original JSON/XML payload, this provides traceability from the received or generated message to the processing result.

Integration Suite also includes a separate service for exporting integration errors, so that errors and status can be forwarded to external monitoring and observability solutions.

Master data and transactional services

The service model is not limited to one record per message.

A service can represent master data, for example Customers, Vendors, Projects and Fixed Assets, where a message typically represents one business entity.

It can also represent transactions, where multiple records together constitute a single payload and must be treated as a single business entity. This is particularly relevant for integrations with journals - General Ledger, Accounts Payable, Accounts Receivable, Fixed asset and Project.