Guides / Integration
Every traveler, every clock-in, every PO and every invoice you have keyed in is sitting in a database. The data isn't missing. It just isn't in a shape you can use, and getting it there's a specific piece of work.
JobBOSS runs on a SQL Server database, and everything your operation has recorded is in it. That's genuinely good news, and it's where most conversations about this go wrong, because people conclude that if the data is there, getting it out should be easy. Getting from a database full of history to a number you can use Tuesday morning is the whole job.
A system that's been running for years is full of decisions somebody made years ago for reasons nobody wrote down. The same number often sits in three places, and working out which one your operation actually uses takes real digging. It's why the answer to so many questions ends up being "export it to Excel and figure it out."
On top of that, every install differs. Two operations running the same version will have configured things differently, used fields for purposes nobody documented, and built up conventions that only make sense to the people who work there. Any generic answer is wrong somewhere, and the places it's wrong are exactly the places that matter to you.
I'm not going to publish a map of anybody's database internals, and you should be wary of people who do. That knowledge comes from working inside customers' systems. Publishing it isn't fair to them or to the vendor. It's also a poor trade for you: a generic map wouldn't match your install anyway, for all the reasons above.
What is genuinely useful is the ability to work it out properly against your system, carefully, and turn it into something that answers your questions. That's the work I do.
One limit worth knowing: this only reads what your operation actually recorded. If something isn't being captured, or is being captured somewhere it doesn't belong, no amount of integration invents it. Finding that out is usually part of the value, and it's the first thing a Diagnostic establishes.
A paid Diagnostic first, where I look at your install and the questions you keep asking, and establish what your data can honestly support. Then a Build quoted up front, so you know the price before it starts, with no hourly billing. I host it and keep it running, with an ongoing care plan covering hosting, monitoring, fixes and adjustments as your operation changes.
I have built API connectors between a manufacturer's ERP and its accounting system, then the jobs that read both overnight and deliver a morning brief and a monthly KPI briefing off them. Also a quote-to-actual feedback loop that compares quoted against programmed against actual times. All in production at a mid-size manufacturer, on the systems it already ran.
See selected work →It depends on how your install is hosted and what access is available, which is one of the first things the Diagnostic settles. There's usually a workable route; it's worth establishing early rather than assuming.
It shouldn't, and that's a design consideration rather than an afterthought. Reads get scheduled for quiet hours where they're heavy, which is also why an overnight job is the usual shape.
Worth checking your own agreement, and I would rather you did than not. Reading your own data for your own reporting is normal, but your contract is yours and it's a reasonable thing to confirm before starting.
Same work, different system. There are notes on each: E2 Shop System reporting, M1 ERP reporting, Global Shop Solutions reports, Made2Manage reporting and Epicor Kinetic reports.
Related reading. If what you actually want is a clean daily number rather than an integration, start at the manufacturing KPI dashboard nobody opens. If the books are the other half of the problem, that's JobBOSS QuickBooks integration.
First call's free. About 30 minutes, a straight conversation about how your operation really runs, not a demo. If there's something worth building, I'll say so; if there isn't, I'll say that too.