Configly can read your Zendesk configuration and, with Apply Changes, write to your live instance. That’s a lot of trust to ask for, so the way Configly gets built is designed around one thing: nothing reaches your help desk until it has been questioned, specified, tested and checked in a safe environment first.<\/p>\n\n
Here’s what that looks like, from idea to release.<\/p>\n\n
Ideas come from client admin centres, support tickets and my own time in Zendesk. Before one goes anywhere, I put it in front of Claude and ask it to find the weak spots. What problem does this solve, who has it, and does Zendesk already handle it natively?<\/p>\n\n
That challenge runs both ways. Claude is a good sanity check. It’s quick to spot a gap in my reasoning or an assumption I haven’t tested. What it doesn’t have is years of living inside Zendesk instances, and that’s where a lot of the arguments start.<\/p>\n\n
Zendesk has plenty of behaviour that isn’t obvious from the documentation. Triggers run in order and keep cycling until none of them fire, so a change to one can alter what happens in another several steps later. Features and limits vary by plan. Something that looks simple in the admin centre can be a very different shape underneath. When Claude’s suggestion doesn’t account for that, I push back, and I’ve done that a lot.<\/p>\n\n
Those arguments have made Configly better. A feature that survives the back and forth comes out sharper than the version I walked in with, and more than a few enhancements started as a disagreement about how Zendesk actually behaves.<\/p>\n\n
AI is the sanity check. The expert in the loop is human.<\/p>\n\n
Ideas that hold up move forward. The rest go in an archive, which is much longer than the roadmap.<\/p>\n\n
The next question is what the feature could do to your instance if it went wrong. A change that touches triggers, macros or routing can have knock-on effects well beyond the thing it was meant to fix. If the answer is uncomfortable, the design changes at this stage, while that’s still cheap.<\/p>\n\n
Features that make the cut are broken down in Jira into epics, stories and tasks. Each task gets acceptance criteria covering what tests must pass and what you should see when it works.<\/p>\n\n
Before building starts, the existing codebase is checked to see exactly what the change touches, and each ticket gets a written plan with the approach, the edge cases and what’s deliberately out of scope. Code comes after all of that, and Claude writes it against the plan.<\/p>\n\n
Asking an AI to “do this ticket” and hoping for the best isn’t how Configly is built. Every part of the codebase carries its own set of rules that Claude has to load before it starts work. They cover how that part of the system is built and tested, the architectural lines it can never cross, and lessons from past mistakes so they don’t happen twice. The database separation covered further down is one of those rules, and it’s written down as absolute.<\/p>\n\n
On top of that sits a workflow specification that’s read fresh at the start of every piece of work, so changes to how work should be done apply immediately rather than relying on anyone remembering them.<\/p>\n\n
A few of the rules are there purely to keep the process honest. If a ticket is ambiguous, Claude stops and asks rather than guessing. It can’t create its own work or widen the scope of what it was asked to do. It can’t mark anything as finished, only hand it back for review. Those rules sit above everything else, including the ticket itself.<\/p>\n\n
The ticket says what to build. The rules make sure it’s built the same careful way every time.<\/p>\n\n
Automated tests catch broken code. They can’t tell whether a screen is honest about what an action will do. A button that says “preview” but changes something, or a confirmation that hides a side effect, would pass every test and still put your data at risk.<\/p>\n\n
So every change also gets a visual review before it can progress. Work that isn’t right goes back with specific notes and comes round again. This loop takes up most of the time on any feature.<\/p>\n\n
Configly works with your configuration: triggers, automations, macros, views, ticket fields and the rest of the setup that shapes how your help desk runs. The data it holds lives in its own database, and support and admin tooling runs on a separate database with no route to it, so a problem in one can’t reach the other.<\/p>\n\n
Where the interface blocks something risky, the server refuses it as well. The button is there for convenience; the backend check is the real protection.<\/p>\n\n
Nothing in Configly changes your instance without telling you exactly what will happen first. What-If simulation shows the impact of a change before you commit to it, and Apply Changes shows you the precise differences it’s about to push. If a screen can’t be clear about what an action will do, it doesn’t ship.<\/p>\n\n
Every change runs on a separate environment first and only reaches production once it has passed review. Production is monitored for errors and backed up daily, weekly and monthly. Releases are versioned, and customer-facing changes are listed in the public changelog.<\/p>\n\n