Custom integrations have a mediocre reputation, and often it is deserved. At many manufacturing companies a linking script still runs somewhere that nobody fully understands, written by someone who left long ago. It works, until the day it does not, and then nobody dares to look inside.
Still, sometimes there is no standard route. That one ERP with its own custom fields, the home-grown planning tool, the customer portal that expects document packages in its own structure: whoever wants to connect to those ends up with a custom integration between CAD software and their own system. That does not have to turn into a permanent headache. The difference between an integration that lasts for years and one that creaks right after delivery sits almost entirely in the approach. That approach, in four agreements, is what this article is about; a platform like Thundercad plays the role of maintained base in it.
One thing we will not repeat here: the build-or-buy trade-off. We covered that earlier in iLogic or a ready-made toolbox: when to choose what. Here we assume the conclusion is custom work, and the question is how to keep that project small and manageable.
First check whether it is truly custom
A fair share of the wishes that arrive labeled as custom work turns out to be covered by standard tooling. Exporting drawing packages in bulk, delivering the BOM in your own Excel template, consulting ERP articles while building an assembly: nobody needs to commission code for those. So walk the standard route first and determine where it ends; Connecting Inventor to your ERP: where do you start? describes a ladder of integration levels that helps with exactly that.
Real custom work starts where your process demands a handover no standard function covers. Think of a planning tool that wants to receive hours per production step, or a customer portal expecting a document package with its own folder structure and naming for every delivery. Those handovers are specific to your company, and that is precisely where custom work belongs.
Start from the dataset that is already right
An integration moves data; it does not improve it. Connect a source in which half the article numbers are missing or duplicated and you will from now on spread that mess automatically, which wrecks trust in the integration faster than any outage. So the first question of an integration project is not technical but substantive: which dataset is already reliable here?
At a machine builder that is, for example, the BOM of a released assembly, with article numbers and descriptions already under discipline because purchasing works with them. That is a fine first handover. iProperties nobody has made agreements about are not; you bring those under control first, before a system starts depending on them. Starting small with clean data also gives both sides, engineering and the administrator of the other package, a quick success to build on.
Define one handover: fields, moment, direction
The difference between a manageable project and a swamp sits in a single sentence. Not "the systems need to talk to each other", but for example: "at release of an assembly these eight fields of the BOM go to the planning package, one way." Such a sentence forces every choice that matters:
| Question | Example of an answer |
|---|---|
| Which fields | article number, description, material, weight, quantity |
| Which moment | at release, no continuous synchronization |
| Which direction | from CAD to the other system, one way |
| Who owns the data | CAD for geometry and weight, ERP for commercial fields |
| What when in doubt | the integration reports, a human decides |
Anything not on this list does not exist in version one. Two-way traffic, extra fields, live synchronization: all fine ideas for later, after the first handover has proven itself in practice. Guarding scope is not bureaucracy in custom work, it is self-protection.
Want to see what such a handover looks like in practice? In the Thundercad trial month you explore how the standard tools work together with your ERP, before anything gets built.
Try 30 days freeBuild on a maintained base, not on loose scripting
The classic pitfall is the loose script: quickly built, exactly right for today, and completely dependent on that single author. At every new Inventor release it is a gamble whether it still runs, documentation is rare, and a second pair of eyes has never looked at it. That is how the ghost integrations from the first paragraph of this article come into being.
The alternative is custom work as a thin layer on a base that is already maintained. Within Thundercad, the Dashboard is the place for that: it is where you manage the tools and connect them to your ERP or other software. One example is Article Manager, which lets engineers consult ERP articles without leaving Inventor; hooking that tool up to your article database is a small, well-bounded job compared to a complete custom build. The custom part then shrinks to the translation step for your system, while updates and maintenance of the base simply continue.
The rule of thumb: the smaller the part that is built uniquely for you, the smaller the part that only your supplier or that one colleague understands. The sheet from the previous section should be able to describe the custom part completely.
Agree who manages the integration
Integrations rarely die of technology and almost always of neglect. Someone renames a field in the ERP, the folder structure on the server changes, and three weeks later it turns out planning has been calculating with old weights the whole time. Not because the technology failed, but because nobody felt like the owner.
So pin down five agreements before anything gets built:
- one named owner for substantive questions: is what comes across correct;
- one maintenance party for the technology, with an agreement on who updates what and when;
- the field list sheet as a living document: if a field changes, the sheet gets updated first;
- a fixed test moment after every change in the ERP or the CAD environment;
- a fallback route: how does the department keep working when the integration is down, and who notices first.
If ownership cannot be assigned, do not start building. That sounds strict, but an integration without an owner inevitably becomes the script nobody dares to look into anymore.
Frequently asked questions
How long does a custom integration project take?
The lead time rarely sits in programming and almost always in data work and decisions: getting the dataset clean, settling the field list, walking through test cases. With a clean source and a handover that fits on one sheet, it stays a manageable project; with a polluted source, the project effectively starts with the cleanup.
Do we need to be able to program ourselves?
No. Your role as the customer is substantive: deciding which fields go across, when, and what should happen in case of doubt. The builder, your supplier or a colleague with development experience, takes care of the technology. Above all, get the substantive choices on paper before building starts; it saves discussion afterwards.
Can we start small without launching a project right away?
Yes, and that is the sensible thing to do. Start with the standard tools and see how far you get without custom work; whatever remains is the real custom question. Download the Thundercad trial, explore the Dashboard and only then put the remaining wishes in front of a builder.