Microsoft is pushing hard on the Dynamics community to lean towards Microsoft Flow and try to replace custom coding by leveraging the Power Platform. To achieve this they rebuild the Microsoft Flow connector for business central (cloud), based on the out-of-the-box API. I had some the first projects where we took the opportunity and try to leverage flow. Below are the things I’ve learned along the way.
I’ll flip the sequence so we can end this post on a positive note 😉
The bad
Let’s start with the stuff that just doesn’t work. The BC connector contains some line tables:
- SalesQuoteLines
- SalesOrderLines
- SalesInvoiceLines
- PurchaserOrderLines
- PurchaseInvoiceLines
One would assume you can specify the header (parent) record inside the Flow step to attach the lines towards the parent record… sadly this is not the case. When we look at the API docs we can see that the DocumentID field should be used to pass the GUID of the parent record. The DocumentID field however is not present in the SalesInvoiceLines entity.
This renders the connector useless in complex business scenario’s and questions the level of detail put into the creation of this connector.
How can we fix this situation? By splitting the creation into two separate steps:
First, create the Sales (Invoice) header from the default BC connector:
Afterwards we call the standard API from the Flow HTTP connector and provide the DocumentID (GUID link towards the parent header) from the previous step inside the request URL.
This will create a new invoice with some G/L entry type lines. You finish by using the ‘Execute Action’ step to post the invoice by passing the id from the newly created Invoice header.
The ugly
Syncing customers between Business Central companies
So child-parent entities are a no-go. Let’s try the more simple stuff, like using Microsoft Flow to re-create a customer inside multiple companies inside the Business Central tenant.
So we start by using the ‘When a record is created’ trigger in combination with the ‘Customer’ table:
Here we encounter the first problem. In Business Central the ‘record’ is created instantly when the Customer No is defined and committed towards the database. So the Flow event is fired and only contains the newly created Customer No. A downside of not having a save button inside Business Central…
So we have the customer number in for our synced Customer, but we need the other fields as well. So we can fall back on the ‘When a record is modified’ trigger and look for updates on our Customer card to sync this towards our other company.
Second problem arises here, the output from the modified step is for some strange reason only a fraction from the data stored on the customer in the database. I speculate on this by assuming the record only contains the modified fields, but this was some hit and miss in my testing.
To fix this we receive the record again by pulling the record using the ‘Get Item’ trigger. Our Flow now contains these two steps to get the complete Customer record.
We now can sync customer data between multiple BC companies. But darn we are missing some important fields that are not published on the standard API customer page.
This takes us towards the third problem:
Extending the customer API fields in Business Central
The API in business central consists of some specific pages that contain the default published fields, in our example the ‘Customer’ record is using the ‘Customer entity’ (5471) page. So like all pages inside BC we can create a page extension and add the missing fields.
It would be super neat if these fields would show up in the Flow connector once we extend the page. It doesn’t… in fact it get worse. Extending the default API pages breaksthe Flow connector:
So back to square one.. . I’ve brought this ‘feature’ to the attention of Microsoft and the claim this is by design. I quote ‘we want to keep the API pages the same for all tenants, the solution is to create your own ‘Customer’ API page’. The fact that we can’t see custom API pages inside the flow connector is a minor setback.
The fix? Once again resulting towards the HTTP action in Flow in combination with a custom customer API page.
The good
So in conclusion, the Microsoft Flow connector for Business central is holding its ‘preview’ badge with pride. There is a lot of work to be done to leverage the power of Microsoft Flow and use it in a meaningful way. Let’s not get deviated by the current limitations for the obvious potential, I am a huge Flow believer and expect this issues to get solved in the distant future.
In the meantime, the Parse JSON and HTTP connectors will become your new Flow friends.
More information about the Business Central API can be found at https://docs.microsoft.com/en-us/dynamics-nav/fin-graph/