Earlier this year, Atrium introduced Andi to the world, our first AI consultant. Andi is a purpose-built custom agent, focused specifically on accelerating Salesforce configuration. I’ve talked about Andi’s capabilities in previous blogs, and demoed Andi live in webinars (here is the latest), but I wanted to go deeper, and show a real-life scenario of Andi working in tandem with Google Gemini to form a truly powerful partnership.
In this blog, I’ll walk through a recent use case where I wanted to demonstrate to a partner the power of Andi using a story from their backlog. The story focused on making significant changes to a complex Salesforce Flow. However, I didn’t have direct access to their environment. I turned to my two favorite AI tools — Andi and Gemini — to rapidly set up the scenario and complete the development. The customer had estimated that the story would take about 14 hours of development time; I was able to complete everything in under an hour.
Step 1: Setting up my environment
I didn’t have direct access to the partner’s environment, but I did have the ability to get information from the Atrium team on the ground working with them. My contextual inputs were the XML source code for the original, unmodified Flow, plus the user story detailing the changes required to that Flow.
For starters, I needed to align my generic development environment with the customizations that the partner had made. Rather than scanning or searching through every line of the code for reference, I had Gemini do the heavy lifting for me.
Identify custom fields
I started with this prompt in Gemini:
Can you list the custom fields referenced in the attached Salesforce XML file? For each, please include the object they are on.
That resulted in this response from Gemini:
Here are the custom fields referenced in the Salesforce Flow XML file, all of which are on the Opportunity object:
-
App_Status__c
-
Decision_Status__c
-
Encompass_Milestone2__c
-
Funding_Status__c
-
Loss_Reason__c
-
Sub_Type_Lost_Reasons__c
-
Withdrawn__c
Sweet! Seven fields to create. Once again, I could go through and define each by hand… but I’d rather let Gemini do it for me. So here’s what I gave it for my follow-on prompt:
“Here’s a user story that references these fields. Can you interpret based on that what data type each field is? For picklist fields, please include the list of values (as many as you can gather from the story below).”
Gemini nailed it, extracting all of the picklist values from both the XML and the user story and correctly identifying the type for all fields:
In seconds, I had everything I needed to get those fields created.
Creating the fields in my dev environment with Andi
I then cleaned that up and fed the results into Andi:
Less than a minute later, I had all of the fields perfectly created in my development environment.
Step 2: Translating the Flow into a user story
Behind the scenes, Andi runs off several fine-tuned models that support its various features. Those models are trained on typical user inputs (user stories, natural language descriptions, etc.). One thing they’re not trained on yet (but will be in the coming months) is a pass-through XML file. Since Andi can’t create a flow from an XML file (yet), I translated my source XML into a user story with Gemini.
Prompt: Can you translate the attached flow XML into a user story I can use to recreate the flow? (attach XML)
The result was a robust story that clearly laid out all of the decision criteria for the Flow:
User Story: Automate Opportunity Stage Updates As a System Administrator, I want to create a record-triggered flow on the Opportunity object to automatically update the StageName field, So that the opportunity's stage always reflects its true status in the loan process, ensuring data accuracy and improving user efficiency.
Description & Implementation Details This automation should be an after-save, record-triggered flow that runs whenever an Opportunity record is created or updated. The flow should only trigger if one of the following fields is changed:
-
Decision_Status__c
-
Funding_Status__c
-
App_Status__c
-
Withdrawn__c
-
Encompass_Milestone2__c
The core logic of the flow first checks the Opportunity's Record Type and then branches to evaluate the status fields relevant to that record type before updating the stage. Acceptance Criteria The flow must perform the following actions based on the Opportunity's Record Type: Record Type: Consumer Loans
-
WHEN Funding_Status__c is "Funded" AND Withdrawn__c is "False",
-
THEN the StageName should be updated to "Closed Funded".
-
-
WHEN App_Status__c is "Expired",
-
THEN the StageName should be updated to "Expired".
-
-
WHEN Decision_Status__c is "Withdrawn" OR App_Status__c is "Withdraw",
-
THEN the StageName should be updated to "Withdrawn" and the Loss_Reason__c field should be set to "Member Declined Offer".
-
-
WHEN Decision_Status__c is "Auto Declined" OR "Declined" OR Withdrawn__c is "True",
-
THEN the StageName should be updated to "Closed Lost" and the Loss_Reason__c field should be set to "Declined Loan".
-
-
WHEN (Decision_Status__c is "Approved", "Auto Approved", "Conditional Approval", "Counter Offered", or "Conditional Counter Offer") AND Funding_Status__c is NOT "Funded",
-
THEN the StageName should be updated to "Processing".
-
-
WHEN Decision_Status__c is "Pending" OR "Refer",
-
THEN the StageName should be updated to "Underwriting".
-
… (and so on for several more pages)
Great. I have a story that captures the baseline Flow, but I now need to update that story to incorporate the changes from my Jira ticket, so I gave it this prompt next:
Prompt: Can you update that story based on the following requirements to change the flow? (paste in the story details)
Gemini actually didn’t return what I wanted on the first try; instead, it created a more synthesized user story based only on the changes. So I corrected it:
Prompt: I’m sorry, pretend that I’m creating the Flow from scratch. Use the first detailed story as a starting point, and modify *that story* to incorporate these changes. (paste in the story details)
After that, it got it right, and resulted in a well-structured composite story that described the full future state of the to-be Flow.
Step 3: Creating the Flow with Andi
Time to move back to Andi!
Andi doesn’t need much to be successful, and so all I had to do was give it this simple prompt: “Create a flow as follows:” (and then pasted in the Gemini-created story)
Less than a minute later, it had created the entire thing.
It was not 100% perfect; there were a few errors.
- I needed to create the custom record types referenced in the Flow (I did that by hand in SFDC).
- I needed to add Field-level Security to my newly created fields (I also did by hand in SFDC; however, we’ll be building this into Andi in September).
- One complex condition type — (1 AND 2) AND (3 OR 4) — did not process correctly… but everything else did.
I was floored. In 30 minutes, I’d added several custom fields and created a complex Flow with 27 different decision points, that was more than 90% correct.
It only gets better from here
While I spent about 30 minutes proving out the scenario, the vast majority of that time was spent setting up the customization of the environment, something that would not be needed if I was simply developing the story.
While there was a bit of cleanup work to do on the Flow, to complete the few conditions that Andi missed took me an additional 30 minutes or so. Tack on another 30-60 minutes of unit testing (if I was actually developing this), and I would have been able to complete a 14-hour story in under two hours. That’s incredible.
And here’s the thing: it’s only going to get better from here. The one bit of complex logic that Andi missed is something we’ll take back and train Andi’s fine-tuned model on — it won’t miss that in the future. It also has RAG and reinforcement learning built in, so for smaller misunderstandings or contextual knowledge, Andi is self-learning.
Combining the power of Gemini and Andi together created a rapid, successful result that would have taken hours (if it were even possible) in the past. In minutes, I was able to customize my environment, deconstruct a complex Flow into its component requirements, and rebuild the Flow with updates. Staggering stuff!
