Response from the report, not from the handling
The order appears in the moment the ticket appears — at night, at the weekend, during the team meeting. The time that used to disappear between the report and the record is back for the actual work.
- Respond
- Service
- Integration
Service orders from your ticketing system
The ticket becomes the order the moment the ticket appears — with the right customer, the right contract, and nobody typing it a second time.
The problem
The customer has reported it. Your system just doesn't know yet
The ticket is there, with a description, a priority and a customer number. Until it becomes a service order in Business Central somebody has to retype it — and until that happens the job simply does not exist for dispatch, for billing or for any report.
When the customer asks where things stand, the answer is that someone will have to check. And checking means: in a different system from the one the order should be in.
What it costs you
The gap between report and order is the most expensive point in your service process
Response time you don't control
Response times are in the contract, but the clock starts at the report — not at the moment somebody transfers it. Every hour a ticket sits untransferred comes off the time you have for the actual work. With tight commitments, that hour is the one that decides.
Work you do and don't bill
If the order is created without reference to the maintenance contract, it gets billed wrong — sometimes against the customer, sometimes against you. And anything that never becomes an order at all, because the ticket got lost in the day, appears on no invoice. These are not large amounts per case; there are just a lot of cases.
The same job, created twice
Because nobody is sure whether it has been transferred, a second person transfers it to be safe. Then two appointments go out for the same problem, or the customer gets two responses to one incident. That does not just cost time, it costs confidence — and in service, confidence is the product.
Why more customers doesn't mean more revenue
The transfer scales linearly with ticket volume and depends on a handful of people. When the service side grows, the back office grows first — before the extra revenue arrives. That is exactly the point at which companies stop actively selling service contracts.
The fix
Let the ticketing system tell Business Central itself
As soon as a ticket appears, the ticketing system tells AutoFlow. The process looks up the matching customer, checks whether an active service contract exists, and creates the order with the description from the ticket — carrying the ticket number as a reference, so it is later clear what belongs to what.
The most important part is what the process does not do: if it cannot find the customer, it does not guess. It reports the case to the office with the full ticket, so a person can assign it.
How it works
-
The ticket announces itself
The ticketing system reports as soon as a case appears. Nobody has to watch an inbox.
-
The customer is matched
If the customer number matches nobody, there is no guessing — the case goes to the office in full.
-
The contract is checked
An active service contract determines how the order is created and how it is billed later.
-
The order exists
With the description from the ticket and its number as a reference — schedulable and billable.
No duplicates
The ticket number on the order answers whether the case already exists. A second call changes nothing.
The contract is there from the start
The contract link is checked when the order is created, not patched in at billing time.
No particular external system needed
Anything that can send a webhook works — and practically every ticketing system can.
Exceptions stay visible
Unknown customer or unexpected fields: the case goes to a person rather than into half an order.
How you know it paid off
At month end. When the clean-up does not happen — no hunting for jobs without an order, no correcting mis-assigned contracts, no argument about duplicate visits — the process has returned more than the two days it cost.
How it's built
The process in the designer
The ticket arrives by webhook, the customer is looked up, the service contract checked, the service order created. Anything that does not go through reaches customer service as a mail rather than disappearing.
Questions we get asked
Is it really set up that quickly?
The process is built in one to two days. The honest caveat: it stands or falls on the mapping between the customer in the ticketing system and the customer in BC. If that exists cleanly, it is quick. If not, that mapping is the actual job — and it would need doing without AutoFlow too.
Do I really not need a developer?
Not for the process. What you need is someone allowed to set up a webhook in the ticketing system — usually a checkbox and a URL. Reading the message and creating the order you click together graphically, without code.
What happens at a Business Central update?
Nothing. There is no extension in the BC core to recompile. If something changes it is more likely on the ticketing side — and if that starts sending different fields, the process goes down the error branch rather than creating a half-filled order.
What happens with an unknown customer?
The process creates nothing. It sends the full ticket to a configured address so a person can assign it. That sounds like a gap but it is deliberate: an order automatically created against the wrong customer costs more time than it saves — and often only surfaces at billing.
How safe is a webhook from outside?
The call has to be authenticated; without valid credentials nothing happens. On top of that the process checks whether the message is plausible rather than trusting anyone who knows the URL. What arrives is in the log — including what was rejected.
Can it also report back when the order is done?
Yes, that is the other direction and a process of its own. It is worth building one direction first and running it for a few weeks — the callback is worth much less while the outbound path is not yet reliable.
Try it yourself
Starting with AutoFlow costs nothing
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.
- Unlimited testing in the sandbox
- 2 active flows free forever
- No credit card needed
Discover more interesting use cases
File invoices to SharePoint automatically
When a sales invoice is posted, AutoFlow renders the PDF, files it in the right SharePoint folder and writes the link back onto the document.
Read the use case
Reordering at the reorder point
When stock drops below the reorder point, AutoFlow checks open orders and creates the matching purchase order automatically.
Read the use case