How Vantaca stopped flying blind on Zendesk changes

The Vantaca context

Vantaca builds the software platform community association management companies run on, from assessments and financials to work orders and homeowner communications. It is one of the fastest-growing companies in its space, and its support operation reflects that scale: multiple support teams across specialised functions and brands, handling tickets over email and web form.

That growth shows up in the Zendesk configuration. Vantaca structures its instance around functional areas, so the setup is layered, interdependent, and constantly evolving. More admins and more hands in the instance mean more surface area for something to quietly go wrong.

Jammie Camerena sits right in the middle of it. Eight years into working with Zendesk and around eighteen months as an admin, she builds and maintains the triggers, routing logic, macros, SLAs, and views, and trains the agents who use them. When something breaks, she feels it on both ends.

The challenge: knowledge that lived in one person's head

Before Configly, Jammie managed configuration risk with documentation. Every time she worked out that changing one thing would break another, she wrote it up: an SOP, a note, a warning tucked into the relevant knowledge-base card. It worked, after a fashion, but the institutional knowledge lived in her head first and in a Guru card second, and both needed maintaining by hand. Every change to the instance was another doc to remember to update, and onboarding a new admin meant walking them through the landmines one by one.

Then came the moment that crystallised the gap. During a configuration overhaul weekend, she accidentally deleted a trigger, and could not reconstruct what it had been assigned to: the conditions, the actions, who it notified, none of it.

I sat there staring at a gap in the instance with no paper trail, trying to piece it back together from memory and whatever I could infer from downstream behavior.

Jammie Camerena, Vantaca

How Vantaca uses Configly

Jammie has used Configly since beta, and it is now part of her daily workflow. The feature she reaches for most is version comparison: pulling up what a trigger or automation looked like before a change, versus after. As the instance has grown and other teams have brought their own admins on board, that diff view has become essential, not just for catching her own mistakes, but for having a clear record when someone else makes a change and she needs to understand what actually shifted.

It has also changed how she onboards new admins. Instead of talking each person through every “if you touch this, that breaks” scenario and writing it up in an article that may or may not stay current, she can show them the version history directly.

The version history feature is what sold me completely. When I deleted that trigger during the overhaul weekend, Configly's version history let me piece it back together. That alone was worth it.

Jammie Camerena, Vantaca

The outcome: an instance that documents itself

The trigger Jammie lost during the overhaul weekend was recoverable, because the history was there to rebuild it from. Day to day, changes across a multi-admin instance now leave a trail she can follow, and new admins learn the instance by reading its own record rather than a static document that may already be out of date.

The instance documents itself now in a way it never did before.

Jammie Camerena, Vantaca

Why Jammie advocates for Configly

Jammie describes herself as the kind of admin who will fight to the death to solve something herself before asking for help. Configly, she says, is one of the few tools that keeps up with that: version history, diffs, and dependency visibility give her the information to work through problems without flying blind.

For any Zendesk admin managing a growing instance, especially one with multiple admins, that kind of visibility isn't optional. You just don't always know you're missing it until something breaks and there's nowhere to look.

Jammie Camerena, Vantaca