Why Custom Manufacturers Lose Money in Business Central Before a Single Part Ships

Ryan: Imagine you’re standing on the floor of this multimillion dollar manufacturing plant. It’s Monday, May 4, 2026, and you are just watching a complete organizational meltdown unfold in real time.

Emma: Oh, yeah, those are always fun to witness.

Ryan: Right. It’s a disaster. You’ve got this massive custom built industrial conveyor system and it’s halfway assembled, but the production line is just completely slammed to a halt.

Emma: And let me guess, the parts don’t match up exactly.

Ryan: The motor that sales promised the customer, it doesn’t actually fit the frame that engineering sent down to the floor. So the parts are just sitting there, the clock is ticking and the profit margin on this entire job is just evaporating by the minute.

Emma: It’s just vanishing. Yeah.

Ryan: So today we are doing a deep dive into an internal podcast brief we got from InsightWorks. It details a software update called Product Configurator Version 4.1 for Business Central, which is an app you can find [email protected]

Emma: which I know sounds super technical at first glance.

Ryan: It really does. Okay, let’s unpack this. Because While Product Configurator v4. One might sound like, I don’t know, the most niche IT topic imaginable, and it’s actually a magnifying glass on that exact factory floor meltdown we just talked about.

Emma: Yeah, it’s a fascinating look at the chaotic gap between, you know, what a salesperson promises a customer and what a manufacturing facility can actually physically build.

Ryan: Right. Because those are often two entirely different things.

Emma: Oh, absolutely. The disconnect between those two departments is arguably the most universal business problem in custom manufacturing. I mean, most companies running Microsoft Dynamics 365 Business Central, they desperately need a CPQ tool.

Ryan: And CPQ, just as a quick reminder for anyone who forgot, that stands for configure price quote, right?

Emma: Yes, exactly. Configure price quote. But a lot of these shops don’t even know specialized applications exist to bridge that gap. So because they are sort of blind to the software solutions, they end up relying on these incredibly fragile manual workarounds.

Ryan: You just throw people at the problem.

Emma: Right. They throw human labor at what is fundamentally a systemic data problem. And that creates this massive financial drain that, honestly, management often just ignores. Until a major crisis hits the shop floor.

Ryan: Yeah, until everything catches fire.

Emma: Yeah.

Ryan: So to really appreciate the mechanics of a software fix like v4.1 I think you first have to understand the human nightmare operating behind the scenes in what they call a configured order environment.

Emma: It really is a nightmare.

Ryan: It is. So the core breakdown starts. The second sales wins a deal. They build a quote for something complex. Let’s say a highly customized piece of

Emma: packaging machinery which has, you know, hundreds of moving parts.

Ryan: Exactly. The customer signs off, everyone’s happy. But then that sales quote entirely fails to translate into a usable production bill of materials at the barium.

Emma: And it also misses the routing instructions.

Ryan: Right, the routing which actually tells the machines on the floor how to cut the metal. Reading through the brief, it reminds me of this analogy. It’s like being in a restaurant where the waiter takes a highly complex off menu order in French. Right. But the kitchen staff, they only speak Italian.

Emma: Oh, I like that analogy. That’s good.

Ryan: Yeah. And so you end up with the restaurant manager literally physically standing between the dining room and the kitchen, frantically trying to manually translate every single ticket by hand.

Emma: While the food is getting cold.

Ryan: While the food gets cold, the chefs are screaming, and the waiter is already out there taking the next complicated order.

Emma: What’s fascinating here is that the frantic restaurant manager in your analogy isn’t even an exaggeration. Not at all. In the manufacturing world, that person is usually a highly trained, highly paid mechanical engineer.

Ryan: Wait, seriously? An engineer is doing that?

Emma: Yes. Companies will literally have a senior engineer sitting at a desk for hours every single day, and they’re looking at a PDF of a sales quote on one monitor, and they are manually retyping a hundred line bill of materials into Business Central on the other monitor.

Ryan: That blows my mind. You are taking your most expensive technical talent, the people who should be, I don’t know, designing the next generation of your products, and you’re just turning them into highly paid data entry clerks.

Emma: You really are. And furthermore, relying on human data entry for complex logic, it’s just impossible to scale.

Ryan: Because humans make mistakes.

Emma: Exactly. The moment you introduce a new product line, or, you know, the moment your order volume spikes for a busy season, that single engineer becomes a massive bottleneck. They get tired, they hit the wrong key, and suddenly a typo on a subcomponent makes it all the way down to the welding station.

Ryan: Oof. So manufacturing gets a bomb that doesn’t actually reflect the quote.

Emma: Right. Or perhaps even more dangerously, they get a bomb that functions perfectly well on the assembly line. Like it builds a working machine, but it was built using entirely outdated cost inputs.

Ryan: Oh, wow. So you are literally selling the machine at a loss, and you don’t even realize it.

Emma: Precisely. What? You’re bleeding money on every unit.

Ryan: Okay, so we need to figure out why the automated systems designed to prevent this were failing so badly before this 4.1 update. Let’s look at the actual underlying logic.

Emma: Yeah, the rules.

Ryan: And Right, because based on the brief, the previous iteration of configuration rules was, well, for lack of a better term, fundamentally blind to its own environment.

Emma: They really were blind. In any CPQ system, configuration rules exist to prevent physical impossibilities.

Ryan: Like putting a square peg in a round hole.

Emma: Exactly. If you’re configuring, say, a custom commercial door, the rule builder is the engine that physically stops a salesperson from selecting a heavy duty smart lock that is actually thicker than the door panel itself.

Ryan: Right, because that would be impossible to build.

Emma: Yeah, or it stops you from putting a 500 horsepower motor on a frame that’s only rated for 200 horsepower. The rule enforces reality.

Ryan: Hold on, because I read this part of the source material and it completely threw me for a loop. Before this v4.1 update, these rules didn’t actually know where they were running from.

Emma: No, they didn’t.

Ryan: How did anyone even build a functional product configurator if the rule couldn’t see the user specific choices? Like, how does that even work?

Emma: It was a massive technical hurdle, honestly. Imagine having a GPS system that knows your destination, but has absolutely no idea where your car is currently parked.

Ryan: Oh, that sounds incredibly frustrating.

Emma: It was a rule that was triggered from a specific option choice. Let’s say a user is selecting option A on a motor housing. That rule couldn’t reliably identify that it was option A that woke it up. The system completely lacked contextual awareness.

Ryan: So it knew a rule was triggered, but not why or from where.

Emma: Right. And to survive this blind spot, administrators had to build incredibly clunky workarounds. I mean, they would write the exact Same logic rule 10 different times, hard coding a different specific condition into each one just to blanket the entire configuration with safety checks.

Ryan: So instead of one smart rule that just adapts to its surroundings, you had 10 dumb rules taking up space and slowing everything down.

Emma: Pretty much, yeah.

Ryan: It’s like trying to build a modern smartphone using the mechanical switches from a 1950s telephone exchange. Just way too much clunky hardware.

Emma: That is a great way to put it. That structural bloat is exactly what causes complex configurators to just collapse under their own weight. Which brings us to the core mechanism of the v4.1 update, which they call context aware rules.

Ryan: Okay, context aware Rules. How does that change things?

Emma: Well, the development team fundamentally rewired how the logic engine interacts with the user interface. So now when a rule executes, it can dynamically reference variables from the exact record it’s running from.

Ryan: Meaning it actually knows where it is now?

Emma: Yes. If a user selects a specific custom dimension for a table leg, the rule fires, looks at that specific leg, understands its exact position in the broader configuration hierarchy, and runs the math.

Ryan: Wow, that changes the entire architecture of the system. I mean, you’re eliminating those 10 duplicated hard coded rules because you only need one dynamic rule that can basically just read the room.

Emma: Exactly. And it drastically reduces the maintenance burden on the IT team. When you no longer have to duplicate logic endlessly, your configurator becomes agile. You can introduce new product lines in days instead of months because the underlying logic structure finally understands the context of the choices being made.

Ryan: Okay, so the basic logic is finally fixed. The rules know where they are. But then the brief introduces what I’m going to call the Russian doll dilemma.

Emma: Ah, yes, the nested sub configurations.

Ryan: Right. Because industrial products are rarely just a flat list of parts, it’s not like buying a skateboard. You have complex components nesting inside of other complex components.

Emma: Yeah, the brief refers to those nested components as sub configurations. So think about an industrial pump. It isn’t just one item. The main pump is the parent configuration.

Ryan: Right.

Emma: Inside that, you have a motor assembly, which is a sub configuration. And then inside the motor, you might have a custom cooling system, which is yet another sub configuration.

Ryan: Right. Like Russian dolls. Yeah, and before this update, forcing those nested dolls to talk to each other was apparently just a total nightmare.

Emma: Oh, it was a data entry disaster.

Ryan: But with v4.1, these nested components now automatically inherit values from their parent component. So if the parent pump is designated for a high corrosion environment, the sub configurations automatically inherit the requirement to use

Emma: stainless steel, which is huge. No one has to manually go into the nested menus and re enter that data. It slams the door completely shut on transcription errors.

Ryan: Exactly. But here’s where it gets really interesting. Because the biggest danger with these neista configurations wasn’t just somebody typing in the wrong metal type.

Emma: No, it was much worse than that.

Ryan: It was a silent financial killer. It was cost drift.

Emma: Yeah, the cost roll up problem. This is arguably the most critical structural fix in this entire release. Let’s walk through the mechanics of how cost strip actually happens in the real world.

Ryan: Yeah, break that down for us.

Emma: So every physical component in your inventory has a calculated standard cost when the price of raw copper goes up globally, your purchasing team goes into business central and updates the standard cost of copper wire.

Ryan: Makes sense.

Emma: Now, if you have a nested sub configuration, let’s say the copper wiring harness deep inside our custom motor. That sub configuration is supposed to inherit the updated standard cost calculation from the main system.

Ryan: But the update trigger wasn’t firing correctly, right?

Emma: Right. It was failing to sync. The nested components were becoming mathematically detached from the parent item. So the cost of copper goes up globally, but the sub configuration is still calculating its total value based on the old price of copper.

Ryan: Oh, man. And the terrifying part of that is that the final configured product looks completely valid on the salesperson’s screen.

Emma: Yes, exactly.

Ryan: The physical parts match up. The engineering is completely sound. It will build a working pump.

Emma: But the underlying financial reality is rotting away. The child choices, you know, the unit price, the unit cost, the net weight, they all start drifting away from the actual market reality.

Ryan: And because the bwam looks structurally perfect, nobody raises a red flag.

Emma: Nobody notices finance only discovers the problem months later when they run a quarterly margin report and realize the company has just been bleeding cash on every order.

Ryan: If we connect this to the bigger picture, consider a mid market manufacturer doing really high volume quoting. If your sales team is sending out 50 complex quotes a day and the unit cost on a nested sub configuration is drifting by just say 3%.

Emma: It adds up so fast.

Ryan: It does. That tiny invisible error aggregates into a staggering loss of profit over a fiscal year. So what this v4.1 Precision release does is guarantee mathematical cohesion.

Emma: Yes. When a sub configuration is generated, it enforces the calculated standard cost settings through the entire hierarchy. It essentially forces the nested child choices to align perfectly with the parent.

Ryan: Okay, I wanted some quick math on that to really visualize it for you. If we are under costing that custom pump motor by $50 because the nested rule failed to update, which is a

Emma: very realistic number by the way.

Ryan: Right. And we sell 2,000 of those pumps this quarter. That is $100,000 of pure profit just vanishing into thin air.

Emma: Gone.

Ryan: And the company would have absolutely no idea until cash flow just dried up.

Emma: That is the exact scenario playing out in factories right now. Fixing that specific update on when used setting isn’t just some minor software patch. It’s a massive financial safety net for these companies.

Ryan: So, okay, we’ve solved the logic bloat. We’ve ensured that the nested costs and weights are mathematically locked in and perfectly accurate.

Emma: Everything matches.

Ryan: We have generated a flawless Digital quote. But having perfectly accurate data on a computer screen doesn’t magically assemble a water pump.

Emma: No, it doesn’t. You still have to build it.

Ryan: Right. How does this perfected data cross the chasm to the physical manufacturing floor without just causing a massive traffic jam?

Emma: Well, the handoff from a sales order to a production order is where the digital world hits physical reality. When you convert that perfect sales quote into a manufacturing job, the system has to assign that new job a state status.

Ryan: And the brief calls this feature configurable Production order status. It says that with v4.1, planning teams now have direct control over the specific status of the new order as it crosses over.

Emma: Yeah, they get to dictate how it

Ryan: enters the system so they can choose whether it enters the production queue as firm planned, released, or whatever custom status they require. But let me try to explain why I think this matters. You tell me if I’m on the right track here.

Emma: Go for it.

Ryan: If I’m the production planner on the floor, I don’t want a massive custom job dropping into my lap as a finalized released order if I haven’t even sourced the specialized steel for the frame yet.

Emma: Right.

Ryan: I need it to enter as a draft so I can actually control the timeline. Am I looking at that correctly?

Emma: You are definitely hitting on the right concept. But the mechanical implications inside Business Central go much deeper than just draft versus final.

Ryan: Oh, really? How so?

Emma: In a manufacturing environment, the status of an order serves as the literal trigger for the entire MRP and MPS engines. That’s material requirements, planning and master production schedule.

Ryan: Okay, so it’s actively driving the software’s brain.

Emma: Yes, it’s the engine. If a configured order drops into the system with a default released status, the MRP engine instantly assumes you are building it tomorrow. Yeah, so it starts automatically allocating raw materials, it locks down machine time, and it will aggressively prompt your purchasing department to overnight ship missing components, which creates complete chaos. Total chaos. It creates artificial urgency and completely derails your carefully planned factory schedule. So by giving planners the ability to define that creation status, say bringing it in as firm planned, instead, it freezes the timeline.

Ryan: It gives them a minute to breathe.

Emma: Exactly. The system acknowledges the order exists, it secures the materials, but it does not automatically upend the entire shop floor schedule to accommodate it. It just removes the friction from the handoff.

Ryan: Speaking of friction, there is an entire section in this brief dedicated to the day to day performance aspect of this update.

Emma: Ah, the table stakes fixes.

Ryan: Right. They refer to them as table stakes. But anyone who has ever used enterprise software knows that performance speed is what actually determines if an app gets adopted or just abandoned entirely.

Emma: Software lag is the absolute enemy of adoption. I mean, when a salesperson is on the phone with a client trying to configure a product with 200 different option choices, a third three second loading delay after every single click is going to drive them crazy.

Ryan: They’ll just quit using it.

Emma: Yeah, they’ll abandon the tool and just go back to using a spreadsheet.

Ryan: Exactly. And the brief notes that v4.1 introduces significantly faster option choice lookups and vastly improved load times for choice variables when administrators are actually in there editing the rules.

Emma: Which saves the IT team a ton of time.

Ryan: And they’ve also cleaned up the user interface. Right? Removing obsolete page fields that were just causing visual clutter.

Emma: Yeah.

Ryan: And for the IT professionals listening, this release secures full compatibility with Business Central version 28. It specifically resolves a nasty bug related to sales line insertion that was apparently causing a lot of headaches during upgrades.

Emma: That BC28 compatibility is a really crucial signal. It tells the businesses relying on this app that insightworks is actively maintaining the architecture.

Ryan: You know they aren’t going to just abandon it.

Emma: Exactly. You never want to anchor your entire manufacturing workflow to an application that the developer abandons during a major Microsoft ecosystem update. That’s a nightmare scenario.

Ryan: So what does this all mean? We have explored the deep mechanics of context aware rules. We’ve walked through the financial dangers of cost drift in nested sub configurations and we’ve analyzed the production floor handoff.

Emma: We’ve covered a lot of ground.

Ryan: We really have.

Emma: Yeah.

Ryan: Lets synthesize this based on our source material. Who are the primary beneficiaries of this update? Like who does this help the most?

Emma: The impact really hits three distinct groups. First, the operations managers.

Ryan: The ones on the front line.

Emma: Right. These are the people whose blood pressure spikes when an order is wrong. For them, this update means the end of manual transcription errors. They can stop tracking how many times a production run had to be scrapped just because the bay bomb didn’t match the the sales quote. The bleeding stops.

Ryan: That’s huge for morale alone.

Emma: Oh absolutely. Second, you have the VARs, the value added resellers. These are the consultants who implement Business Central for mid market clients.

Ryan: Okay, how does it help them?

Emma: Well, frequently they’ll look at a client and decide that a massive enterprise grade CPQ platform is just too expensive and complex for their needs. Product configurator has always been the lighter, more agile alternative. Right now with the rule builder functioning intelligently and the cost logic firmly locked down, the VARs can recommend this app without worrying about unexpected margin errors showing up down the road. It protects their reputation.

Ryan: And the third group would be the BC administrators. And it leads right, who finally get a system that plays nicely with the native material requirements planning modules and actually survives the Upgrade to Business Central 28.

Emma: Precisely. It is a tool that finally speaks both the language of the sales team and the rigorous mathematical language of the manufacturing floor.

Ryan: If you are listening to this and you recognize your own daily struggles in this configure to order nightmare, you know, if your company is still forcing brilliant engineers to manually translate PDFs into bills of material, you know what your next step should be.

Emma: Time to make a change.

Ryan: Definitely. Based on the InsightWorks Brief, you can head over to CPQForDynamics.com to dive deeper into the technical specs, or just reach out to an InsightWorks partner to see how this fits into your specific workflow. It is incredibly rare to see a software update that actually tackles the root cause of a human operational problem, rather than just, you know, putting a shiny new interface over the exact same broken process.

Emma: I completely agree with that. And analyzing the source material leaves me with a much broader, almost philosophical question to ponder.

Ryan: Oh, I like the sound of that.

Emma: Well, we talked earlier about that highly trained engineer who spends their entire day doing manual data entry just to fix broken sales quotes.

Ryan: Right? The expensive translation clerk.

Emma: Exactly. If a company successfully implements v4.1 and they entirely eliminate that translation gap, what happens to that human capital?

Ryan: Oh, that’s a great point.

Emma: Right? When those engineers are finally free from the administrative burden of holding a broken system together, do they transition into pure innovators?

Ryan: You would hope so.

Emma: And how does unlocking thousands of hours of trapped intellectual potential fundamentally shift the competitive output of a manufacturing business?

Ryan: That is a phenomenal question. When you stop forcing your talent to act like human tape holding a broken process together, they can finally start building the actual future of your company.

Emma: Exactly.

Ryan: Thank you all for joining us on this deep dive. We hope you gained some valuable insight into the hidden mechanics of the configure to order world. Keep questioning how the systems around you actually work and we will catch you on the next one.