VFP's Campfire AI engine turns structured requirements into Salesforce and Certinia configuration. We asked a Senior Consultant, a Principal Consultant and a Consultant what changed in testing, what surprised them, and what still needs a human.
Every Salesforce implementation has a stretch that clients never see and consultants rarely love: the build. Requirements get written, handed to builders, and then clicked into the system one field, one permission, one flow at a time. On a large engagement, that's hundreds of requirements and weeks of work.
VFP built the Campfire AI engine to change that. It reads structured requirements and configures them directly in Salesforce and Certinia. Before taking it into a live project build, we've been putting it through its paces, including re-running recent client build cycles in testing. We sat down with three consultants who have spent hours alongside it: Michael Hall, Senior Consultant; Brett Konopaske, Principal Consultant; and Stefanie Fischer, Consultant.
From doing the build to directing it
The old workflow was linear. "I would review the requirements," Michael says. "I would then put a plan together that allows me to go into their sandbox and do the build." Then he'd come back and update Campfire by hand.
Now the requirements go in, and the configuration comes out. Stef sums up the shift: "My role has shifted from doing configuration to directing and validating it."
Brett sees the change start even earlier. Discovery-session transcripts feed Campfire AI, which drafts requirements and solution details for the team to review, and those flow straight into the build engine. "It will augment our team to be able to move quickly," he says.
The numbers from testing
The time savings are the headline, and they hold across very different kinds of work:
• A full build cycle. Michael's team re-ran a recent client build cycle scoped at 100 to 180 hours of configuration. In testing, the engine completed it in under 5 hours.
• Bulk fields and permissions. Brett estimates 100 custom fields with permissions at 15 to 20 hours by hand. With the engine: 20 to 30 minutes.
• A complex workspace. Stef split a global workspace into regional views, each with its own cards, list views and components. She puts the manual effort at days to a couple of weeks. It took 20 minutes.
"Now we can shrink our build cycle time down from weeks into days," Michael says.
The aha moments
Each consultant had a moment when the engine did more than expected.
For Michael, it was a screen flow that walked users through a client's business process, with multiple-choice questions, branching logic and an approval process. That's normally 2-plus hours for a human builder. He answered four or five questions from the engine, playing the architect. About five minutes later, the full flow was built, with fields, validations and approvals, and Campfire was updated.
For Stef, it was a permissions problem. A user couldn't enter time, and permissions in Salesforce are notoriously tangled. She asked the engine to analyze the org. It found the fix, then flagged other personas with the same issue. "Instead of finding that issue later in testing, everything was brought forward in that one go."
For Brett, it was upstream: turning client conversations into a first draft of requirements. "That, to me, was pretty incredible."
Consistency is the quiet win
Speed gets attention, but all three point to consistency. The engine follows the same naming conventions and build patterns every time. Michael sees "less rework" and fewer "hey, we need to update the name on this" moments that come from multiple builders on one project.
Brett highlights dependency checking: the engine shows what it plans to build and its dependencies, so a human can verify nothing is missed before anything is built. Stef sees fixes land across the whole system in one pass, rather than one issue at a time.
The consultants trust it fully with the fundamentals: objects, fields, record types, permission sets and validation rules. Complex flows and Apex still get closer solution-architect oversight, though early results there are strong.
Better input, better projects
The engine works from structured requirements, and that has pushed the whole team to write better ones. "The output is only as good as the input," Stef says. VFP now uses AI skills that pull from call transcripts, VFP's standard requirements library and Salesforce and Certinia guidance, so every requirement follows the same format and naming.
The benefit goes beyond automation. "Everyone on our internal team and the client team has a shared picture of what is being built," Stef says. (We go deeper on this in our newsletter.)
What it means for clients
Asked whether the gain is faster time to value, more advisory time or more scope for the same budget, Brett's answer was "all of the above." Time that used to go into clicks can go into testing, training, and process design, the work clients often need most when they're new to Certinia.
Michael frames the potential: an implementation that might have taken eight months could move toward three, depending on the client's team. Brett points to more scope in the same phase, such as custom screens that previously wouldn't have fit the budget.
What the engine doesn't replace
None of the three see the engine as a replacement for consultants. "It doesn't replace any client or industry expertise," Michael says. Stef points to discovery, design conversations and testing, where business nuance and edge cases live. Brett adds judgment: knowing when a solution is getting too complex to maintain, and making sure "we're not just building something to build it."
Michael's description stuck with us. He thinks of the engine as a colleague "sitting next to me, shoulder to shoulder." Neither works as well alone.
Real or hype?
We asked what they'd tell a consultant at another firm. The answers were unanimous.
"It's real, and it works," says Michael. Brett admits his answer would have been different a year ago: "I would say it is absolutely real." Stef adds the practical advice: invest in requirements quality first, and keep a consultant reviewing the output.
What's next: testing
Without prompting, all three named the same next frontier: testing. Michael wants the engine to build test cases and the sandbox data to run them. Brett wants automated tests the team can review. Stef wants it to pick up client test action items, suggest fixes, and handle the simple ones.
The build used to be the bottleneck. With that shrinking, the next one is clear, and so is where the engine goes next.
