The shortcut made sense on the surface. Instead of opening the configurator, someone searched for the item globally and added it directly to the transaction. Faster, simpler, and easier in the moment.

The problem was invisible until it wasn't.

In a live ERP system, parent items evolve continuously. Pricing updates. Materials change. Specs get revised. But serialized and configured items don't inherit those updates automatically. They only reflect current data when they're saved through the configurator.

So, an item pulled from search and copied onto an order could contain outdated pricing, incorrect finishes, wrong BOM data, or broken production logic, and nothing in the transaction would flag it.

We identified several orders where this had happened. The downstream risk was real: incorrect client documentation, manufacturing errors, pricing errors, and broken workflows.

My first instinct was to restrict the behavior entirely. But restriction wasn't the right call.

Some items are legitimately added to transactions manually. Inventory items that aren't configurable don't need the CPQ. And occasionally the configurator itself glitches, completing a configuration without saving it to the transaction, in those cases, manual intervention is the only path forward.

A blanket restriction would have created more friction than the problem it solved.

Instead, I communicated a standard. A clear, specific protocol: if the item number contains a configured suffix, it must go through the CPQ. No exceptions. If you're unsure, assume it needs reconfiguring and ask before proceeding.

The system didn't fail. The process did. And the fix wasn't a technical control. It was a defined standard with clear reasoning behind it. That's the part that makes it stick.

Good systems solve today's problem. Great systems scale for tomorrow and protect the business while they do.