A step of its own in the editor
No HTTP call for someone to assemble by hand. You pick the OneConnector step from the list, choose the query and map the fields.
Business Central moved to the cloud, and the database in your own server room stayed. AutoFlow connects the two, so nobody pulls an export file every morning any more.
Moving to Business Central Online was the right call. But not everything moved with it: the specialist application with its own database, the production data, the legacy system nobody wants to touch because it has run reliably for years.
While Business Central ran in your own building, that was a query against the server next door. In the cloud, Business Central can no longer reach that database, and somebody fills the gap by hand.
Export from the local database, tidy the file, import it into Business Central. It is quick as long as it works. Miss a day and sales works from yesterday's figures, and nobody notices straight away.
Where no export runs, things get entered twice: the same customer, the same item, the same status in two systems. The differences only show once they have consequences: a wrong delivery, a wrong invoice, a stock figure that is off.
The clean answer would be to replace the legacy system. But it works, it is paid for, and a migration just so Business Central can reach the data rarely pays off. So the workaround stays, and it grows a little every year.
Penduline's OneConnector runs inside your network and connects to your database. There you define in SQL what Business Central may read and write, no more and no less.
In AutoFlow, OneConnector is a step of its own. You pick the query, hand it values from the document and carry on with the result: on release, on posting, or in a scheduled process that keeps data in step.
In OneConnector, in SQL: which table, which fields, which condition.
Choose the OneConnector step and pick the query, at the point in the process where you need the data.
Customer, item, document number: whatever the query needs comes straight from Business Central.
Check it, take it over, write it back, and the process carries on.
No HTTP call for someone to assemble by hand. You pick the OneConnector step from the list, choose the query and map the fields.
Business Central sees exactly what your SQL queries allow. The database itself stays behind OneConnector.
Status, quantities, approvals: what happens in Business Central lands in the local system too.
A query when a document is released, or a sync every night: the same step, a different trigger.
If the database cannot be reached, it is in the log and goes out as a message.
The morning export stops, and with it the question of whether the figures in Business Central are today's. The legacy system carries on as it always has, and Business Central works with its data as if it were next door.
SQL databases, which is what legacy systems and specialist applications almost always use. Whether yours is among them, we settle in the first conversation, together with Penduline.
No. That is the point: the data stays where it is, and Business Central uses it anyway. Whether you migrate later is a separate decision, and no longer an urgent one.
No. OneConnector sits in front of the database, and only the queries you set up are available from outside. Which tables and fields Business Central can reach, you decide in each query.
Not for the process, which is built graphically. The queries need someone who can write SQL and knows the database. Usually that is the person pulling the export today.
Nothing. The logic does not sit in the BC core as an object extension; it sits beside it as configuration. There is nothing to recompile at update time.
Discover our AutoFlow experts. They set the process up with you in a workshop.
You can build and test in the sandbox as long as you like, without limits. And two active flows stay free forever in your production tenant — not a trial that runs out.