Dynamics 365 integration consultant in Melbourne

What I build

• Finance and ERP integrations. Customers, invoices, payments and reference data moving between Dynamics 365 and the finance system, in whichever direction it needs to go.
• Payment processes. Getting a payment from a request in Dynamics through the finance system and back, with the status visible to the people who asked.
• Azure Functions and Service Bus. The middle layer that does the calling, queuing, retrying and logging, so Dataverse isn't waiting on another system during a save.
• Plugins in C#. Validation, data shaping and the trigger that hands work off to Azure. Kept small and fast.
• Power Automate where it fits. Lower-volume, less critical integrations where a flow is easier for your team to look after.
• Fixes to existing integrations. The ones that drop records, time out on busy days or fail without anyone noticing.

Plugin, flow or Azure Function?

The first decision on any Dynamics 365 integration, and the one that causes the most trouble later when it's made by habit. A rough guide:

Plugin

Good for logic that has to run inside the save: validation, setting values, blocking a bad record. Plugins run in a sandbox with a two-minute limit, and a synchronous one holds up the user while it runs. So a plugin shouldn't wait on another system. If it needs to talk to one, it should hand the work off and let something else do the calling. And on Update, give it filtering attributes so it only runs when the columns it cares about are in the save.

Power Automate

Good for low to moderate volumes, simple mappings and integrations your own team wants to own and change. Easy to see the run history. Less good when you need tight control over retries, ordering, high volumes or detailed logging, and flows outside solutions are a common deployment headache.

Azure Function (often with Service Bus)

Good for anything critical, high volume, or that talks to a system you don't control. Dataverse posts a message, the function picks it up, calls the other system, retries if it's down and logs what happened. If the finance system is offline for an hour, nothing is lost. It just catches up.

Most real integrations end up as a mix: a small plugin to validate and hand off, Azure to do the work, and sometimes a flow for the simple bits. The point is choosing on purpose.

What makes an integration last

Most integrations work on the day they go live. The ones that cause pain are the ones nobody can see into six months later. What I put in every build:

• One place to see failures. A failed call shows up with the record, the payload and the error, not as a user noticing missing data a week later.
• Retries that don't double up. If a call is retried, it doesn't create a second invoice or a second payment.
• Settings per environment. URLs, keys and IDs in environment variables and Key Vault, not hard-coded, so the same build deploys to test and production unchanged.
• Deployed through a pipeline. The Dataverse solution and the Azure resources released together, the same way every time.
• Written down. What moves where, when, and what to do when it fails. So your team or the next contractor isn't guessing.

When to bring me in

• You're about to connect Dynamics 365 to a finance, ERP or payment system and want it designed properly from the start.
• An existing integration keeps failing and you can't tell where.
• A plugin calling another system is timing out under load.
• Your partner built the Dynamics half and someone else built the Azure half, and the gap between them is where things go wrong.
• You need a senior developer on an integration project alongside your team, on a contract.

If you're not sure what state your current integrations are in, they're part of every Dynamics 365 health check.

Recent integration work

Client name left out on purpose. Happy to go through it on a call.

• Large public-sector organisation. Integrated Dynamics 365 with Oracle Financials and built a faster payment process on top of it.