Part of my heating system wasn’t working properly. The programmer, the bit on the wall that tells the boiler when to fire and which zones to heat. Simple enough component and I’m fairly handy. I ordered the replacement, swapped it in, and nothing happened. Inside the wiring panel, someone had wired it to no diagram I could find. Old cable colours mixed with new, connections that didn’t match the terminals, and every cable disappeared into the wall behind plaster.
I spent two days on it, trawling forums and watching videos. I learned how S-plan systems work, how the motorised valves talk to the zone valves, how the cylinder stat fits in. I labelled every cable, mapped every connection, wired it to the diagram, and it didn’t work. I got the multimeter out, traced every core regardless of colour, rewired the whole panel, and it still didn’t work.
After two days I had no hot water and the house was getting cold, so I called a heating engineer who knew my brand of control panel. He looked at my research and said I’d done a good job. But within two hours he’d found the actual problem: the cables at the boiler end had been terminated wrong, so the signals from the panel never matched what the boiler expected. The original installer had bodged it to kind of work. The part I replaced was probably fine. The system had probably never worked correctly.
I could trace cables and read diagrams but I couldn’t see inside the walls. I had no record of what anyone had installed, changed, or why. The system hid its own problems until I tried to change something.
This is what happens when you inherit a Zendesk instance.
You walk into hundreds of triggers and automations, custom fields with cryptic names, and groups that don’t make sense. It works well enough that nobody questions it.
Then you try to change something. You add a routing trigger and tickets go to the wrong team. You disable an automation that looked redundant and a workflow nobody told you about breaks. You rename a group and three views go dark.
We worked a contract with a company you’ll have an account with and the first thing I did was export the full configuration. A couple of thousand blocking errors came back. Broken references, orphaned objects, conditions pointing at fields that had been deleted months ago. The instance ran fine in production. Customers got replies, agents worked their queues, nobody complained. But when I tried to deploy that config to a sandbox it wouldn’t build, because the whole thing had been held together by layers of workarounds that only functioned in the specific environment where they’d been bodged into place. Same as my boiler.
You can’t see inside the walls. You don’t know what connects to what. The previous person made it work and took the logic with them when they left.
The heating engineer didn’t know more about heating than I did. He had better visibility. He’d seen this exact bodge before and he had the tools to trace the fault end to end.
When I onboard clients onto inherited Zendesk instances, we pull the full configuration into a single view first. Not because the admin can’t read triggers, but because reading the triggers one at a time is tracing cables through a wall with a multimeter. You’ll get there eventually and you’ll still miss the bodge at the far end that’s been making the whole thing “kind of work” since day one.
My house should have come with a wiring log. Your Zendesk should come with a way to see what connects to what.