Dynamics 365 / Practical guide
Dynamics 365 Finance & Operations Integration: From Process to Platform
A Finance & Operations integration succeeds when a business event remains understandable as it moves between people, legal entities, records and services. The first task is not choosing an endpoint. It is defining the process, the authoritative record, the company context and the acceptance evidence that will prove the connection works.
Start with the process, not the connector
A request such as “connect our CRM to Finance” hides several different processes. A customer may become a prospect, an account, a sales order, an invoice or a payment. Each transition has a different owner, timing and failure mode. Map the process that matters first, including the people who approve it and the records they expect to see.
The map should show the triggering event, the source record, the destination record, the responsible company and the point at which the business considers the work complete. This creates a useful boundary for an integration proposal. It also keeps a technical team from promising a broad two-way sync when the business really needs one controlled handoff.
- Name the business event and its owner
- Identify the source and destination records
- Define success, retry and manual-review states
- Separate the first workflow from future automation
Treat company context as part of the data
Finance & Operations is used across legal entities, operating units and environments. A record that looks complete without its company context can be unsafe to move or reconcile. The integration contract should state which company creates the record, which company receives it, how the relationship is represented and whether the operation is allowed across companies.
The same discipline applies to currency, financial dimensions, sites, warehouses, tax groups and document numbering. These are not decoration added after the payload is designed. They can change whether a transaction is valid and who is responsible for correcting it.
| Contract area | Question to answer | Evidence to accept |
|---|---|---|
| Company | Which legal entity owns the transaction? | A test record with explicit company context |
| Identity | Which user or service acts on the record? | Role and permission review |
| Dimensions | Which financial and inventory dimensions are required? | Validated values in a representative scenario |
| Status | When is the handoff complete? | Source and destination status reconciliation |
Choose data and service boundaries deliberately
Data entities and OData can be useful when the public entity already represents the required business contract. A custom service or extension may be more appropriate when the process needs a controlled operation, a calculated value or a business validation that should not be recreated in an external client. The choice belongs in the design record, with ownership and security documented beside it.
Do not infer a table-to-entity mapping simply because two names look similar. Confirm the fields, keys, company behavior, nullability, enumerations and related records. When a required value is calculated or comes from an extension, decide whether the integration should call an approved service, expose a supported entity field or retain the calculation inside Finance & Operations.
- Describe the business contract
- Confirm the supported entity or service
- Record keys, dimensions and company behavior
- Test permissions and representative records
- Document unsupported fields and manual exceptions
Design for retries and exceptions
A successful HTTP response is not the same as a completed business process. The destination may accept a message while a later validation fails, or an external service may return after the source has timed out. Use an integration identity, an idempotency key where the operation supports one and a durable status that operators can inspect.
Exceptions should be useful to the team that resolves them. Store the business reference, company, attempted operation, response category and next action without exposing secrets or unnecessary payload data. Retrying a failed read is different from retrying a create or posting operation. The retry policy must follow the operation’s side effects.
- Use stable business references
- Keep transport status separate from business status
- Make duplicate handling explicit
- Provide a manual correction path
- Mask credentials and sensitive records in diagnostics
Make acceptance a business conversation
Acceptance should use records and decisions that finance, operations and support teams recognise. A technical test can show that a request was sent, but business acceptance must show that the right company, dimensions, document status and downstream responsibility were preserved.
For a first release, choose a small set of scenarios: a valid transaction, an invalid dimension, a duplicate message, a missing reference and a recovery after an external timeout. Record the expected result before testing. This gives the project a clear boundary and prevents a green integration log from being mistaken for a complete operational result.
- Valid transaction reaches the intended business state
- Invalid data is rejected with an actionable reason
- Duplicate delivery does not create an unintended second record
- Timeout recovery is visible to an operator
- Finance and operations owners sign off the result
Primary sources
Sources and further reading.
These platform references support the technical guidance. Available features, versions and implementation requirements should be checked against your environment.