Agentforce Vibes is up there with Flow as my favorite Salesforce tool, and for much the same reason as Flow. Vibes makes customization of the Salesforce platform much easier by leveraging natural language to build code, automating and streamlining complex business processes.
After seeing it in action, I had an idea: Could I use Agentforce Vibes to build a Flow? Each individual Flow is an XML file that can be retrieved from Salesforce through the CLI and edited manually, so I couldn’t see a reason why I couldn’t at least try it!
A Quick Disclaimer
Anytime you’re in a Salesforce presentation, you’ll hear them tell you to make your purchasing decisions on readily available products, and not on upcoming features. While Agentforce Vibes is available today, it is an ever-evolving tool – you will receive different outcomes depending on how you prompt it and how you’ve got it set up.
Take this as a disclaimer: this is not a tutorial, and I am not trying to say that if you do what I do, you’ll get the same results. In fact, more as a challenge – give it a try yourself! Give different commands to Vibes and see how you go building Flows and other functionality in your org.
Just like with Flow, with great power comes great responsibility. Apex, Lightning Web Components, and other supported languages and tools are extremely powerful, and you can cause damage by doing things incorrectly.
I personally believe that Vibes is great for developers or those who understand the languages and frameworks they’re working with, but those who don’t understand what they’re working with should proceed with extreme caution.
Also, for this test, I had already been playing around with Agentforce Vibes quite a bit, so I was out of credits and using the Core Model. You will notice different results when using Core vs. the GPT-5 credits.
With that out of the way, let’s vibe with Agentforce Vibes!
Wait… Agentforce Vibes Can Build Flows?
This is exactly what I wanted to test. At Dreamforce 2025, I saw some examples of Flows being edited (telling it to make small changes to existing Flows), but I didn’t see an example of a brand new Flow being created. This sounds like a job for the Flow man!
While Flow is my main focus in the Salesforce ecosystem, I have enjoyed dabbling with vibe coding over the last few months, and was pleasantly surprised when Salesforce’s Agentforce Vibes announcement came out. Having used other tools prior, I was already aware of the kind of things I needed to keep in mind when talking to Vibe Codey.
Getting Started
So, after spinning up a fresh new scratch org and creating a custom field called “User Group” (a picklist with two options: “Education Group” and “Health Group”), I started a new Task and gave Agentforce Vibes the following direction:
Write me a new Record-Triggered Flow. It will be used to auto-assign a new Owner Group (Owner_Group__c) field value. This needs to be done in the org with username “test-mrgighyid1um@example.com”. The object is Account, and this should fire when an Account is Created or Edited. The triggering criteria will be if Industry is equal to Education or Healthcare. Logic: If Industry value is “Education,” set the value of Owner_Group__c to “Education Group”; if “Healthcare,” assign to “Health Group” The Owner_Group__c is a picklist field on the Account.
Almost immediately, before my very eyes, Vibe Codey acknowledged my request and began building out the Flow XML file.
Once it had finished building the initial Flow, it told me what it was doing and why, then asked me to save it. The reason it asked me before saving is that I had not ticked the “Edit” option in the “Auto-approve” section (at the bottom of the screenshot below).
For a faster workflow, you can tick the Edit box to allow Vibes to automatically update project files, but I’ve had it turned off for the majority of my testing – and I’ve actually rejected one or two changes because I realized it had mistaken my request (I gave it bad instructions, my fault).
After I clicked Save, it went through the code once more and identified that it had only completed half of my initial request. I told it to set the Education Group if the Industry was Education, but also the Health Group if the Industry was Healthcare. It identified this problem and then offered to solve it (once again, requiring my approval before saving).
Once it made this final change, it told me that the task (what it believes is the command I have given it in my prompt) was complete! It had built a new Record-Triggered Flow with the trigger criteria and entry criteria that I had specified.
It had identified that it needs to set the Owner Group field to Education Group if the Industry is Education, and to Health Group if the Industry is Healthcare. It not only built the XML file that represents the Flow in Salesforce, but also updated the README to explain the purpose and functionality of what it had just built. Amazing stuff!
The only thing it was yet to do was deploy it to my scratch org.
Deploying the Flow
Next, I asked Vibes to push its wonderful new Flow into the scratch org that I had built earlier (which had the Owner Group field in it already). This is where I started to encounter errors. Unfortunately, it seems that the XML that was built was not correct, and Agentforce Vibes started to have a few hiccups and errors.
It suggested that I should try deploying it, given the errors it was facing, which wasn’t ideal. I suggested it go back and try to fix the formatting, which didn’t help and, in fact, began to make things worse later on.
After a few attempts, I wondered if I could help it on its way. I decided to build pretty much the Flow that I was asking for manually in Salesforce (imagine having to manually do things in the era of vibe coding – wild!) and told Vibes about it. I asked it to retrieve the code from the Flow that I had built, which followed the correct format as it was built inside of Salesforce, and to restructure the Flow that it had built to match.
This approach seemingly worked! It made a few adjustments and reattempted the deployment a few times, making adjustments as it went. Unfortunately, this is where things took a real turn for the worse. Vibes convinced itself that it was an environment-specific issue and that this particular Salesforce scratch org was different from every other org, which was simply not true.
From here, no matter how many times I attempted to get it to see things differently, it did not. Vibes was convinced that what it had built was correct, but my Salesforce org was wrong. Unfortunately, this is where I had to call it quits. My experiment had failed. Or… so I thought!
A New Hope
After talking with my colleague Andreea Doroftei about this article, she mentioned that she did, in fact, have success with building a Flow with Agentforce Vibes. However, instead of creating a Record-Triggered Flow, she had asked it to create a very simple Autolaunched Flow.
I figured this was worth a shot. Then, I asked Agentforce Vibes to create a new Autolaunched Flow with the following prompt. Notably, my GPT-5 credits had refreshed by this point, so I was in the best possible position to do what I needed to do! I gave Agentforce Vibes this direction:
Build a new Autolaunched Flow for me and call it “Demo Vibes AL Flow”. Create a single Text Variable that is available for Input and call it “recordId”. Create a single Text Variable that is available for Output and call it “varAccountName”. Then, use a Get Records element to get the Account where Id = recordId. Assign the Name of the record that was received to “varAccountName”.
The first issue I came across was my own. As I watched it begin to write the Flow, I wondered why it was using “Demo Vibes AL Flow” instead of the “AF”, which I had specifically asked it to use to identify that it was for my Agentforce demo.
Looking back at my prompt, I realized that I was the one who had made this mistake. Going forward in this article, when you see “AL Flow,” just know that I meant “AF Flow”. Oops!
Agentforce Vibes began writing the Flow, and my heart started racing. Upon completion, it asked me for permission to save the Flow, which I granted it with anticipation.
Then came the green text: Task Completed! My Apple Watch gave me a heart rate warning. This was such an exciting and tense moment that I had started to perspire. Could it be? Would it finally work?
There was only one way to find out, so I then instructed Vibes to deploy the Flow to my scratch org. My heart rate increased all the more. I approved its request…
There’s nothing like a metadata deployment to wake you up in the morning, or whatever time of day this was.
The Deployment Strikes Back
My worst fears were realized after the first deployment attempt. Without saying a word, Agentforce Vibes requested the ability to edit the Flow, which I, of course, granted.
Vibes began to rewrite portions of the Flow to ensure the syntax was correct before reattempting a deployment. Back and forth we went, attempting deployment and rewriting to resolve errors. My hopes vanished, and all seemed lost. Agentforce Vibes was as confident as ever, but we didn’t seem to be getting anywhere.
Error after error, format change after format change, Agentforce Vibes soldiered on. The main error that I kept seeing was as follows:
Error parsing file: Element {http://soap.sforce.com/2006/04/metadata}elements invalid at this location in type Flow
Then, suddenly, Agentforce proposed two options moving forward. It had been identified that the format of the Flow XML was the issue and that it needed to get it right before attempting to push it again. It suggested that it could either use Salesforce CLI tooling to generate a new XML file that followed the correct structure (which I’m surprised it didn’t do from the start, something that I’ll need to suggest in my prompt next time), or it could attempt to pull another working Flow to assess and use to restructure its own.
I’d already been down the route of leveraging a pre-existing Flow in my last attempt, so I decided to go with the first option – using the CLI tooling to generate a valid Flow. I wonder if it doesn’t like using the CLI, though, as I noticed on the next approval, it displayed a warning saying, “The model has determined this command requires explicit approval.”
It was at this point that I realized it must be hallucinating: “sf project generate” will build a new project in VS Code, and “sf project generate manifest” creates a manifest file… but “sf project generate flow” is an interesting command, unique to the others, because the others actually exist. As far as I was aware, and a quick check confirmed, there was no “generate flow” command. I decided to allow it anyway, just to see what it did.
Sure enough, it gave me an error confirming that the command did not exist and offered me another option.
Oh boy. Looking at these options, I don’t think we’re headed in the right direction, once again. I went with the first one, hoping for the best, and Vibes got to work, stripping the Flow XML down completely to basics.
I had nearly lost all confidence at this point, but I decided to approve Vibes’ changes and let it reattempt the deployment.
After a few more errors, I decided to call it quits. I couldn’t get this new Flow off the ground, no matter how I approached it.
But that didn’t mean I was giving up entirely. I’ve seen Agentforce Vibes make changes to Flows, and it was clearly on the right track to some degree, so I decided to make one last-ditch effort to achieve some kind of success building Flows with Agentforce Vibes.
Return of the Flow Builder
I decided to expand on the original demo Flow that I built. Currently, if Industry is Education, then it sets Owner Group to Education Group. If it’s Healthcare, it sets it to Health Group. I’m going to ask Agentforce to add one more – if Industry is Banking, set the Group field to Banking Group.
To kick off, I added the Banking Group value to the Owner Group picklist and retrieved the most recent version of the Flow into the project. Then, I gave Agentforce Vibes its final starting instruction in a new Task:
There’s a Flow called Demo_Account_RT_Flow. Currently, it assesses the Industry field on the Account and checks for two values: Education or Healthcare. It then sets the Owner_Group__c field based on which of these is set. I want you to add a new Decision path. Check for if the Industry field is equal to “Banking'” and if it is then set the Owner_Group__c field value to “Banking Group“. Make sure to change the Entry Criteria to include this Industry value too.
It’s now or never. Agentforce Vibes took my instructions and began making changes to the Flow XML. I read the proposed changes before clicking “Save”, and everything seemed to make sense.
After saving the Flow XML file, I was told that I had just run out of GPT-5 credits, was being returned to Core Model, and that the task was complete. Yes, that’s right – I ran out of credits right before trying to deploy the final request – I couldn’t have scripted this better if I were writing a blockbuster.
The time had come. I asked Vibes to deploy this Flow as a new version, and held my breath.
Deploy that Flow as a new version to the org with username test-mrgighyid1um@example.com.
I could hear my heartbeat in my ear, and my watch warned me again about my high heart rate.
And then, after a seemingly endless wait…
The Flow was successfully deployed! What a relief.
Unfortunately, it seems like it completely ignored the instructions I gave regarding the username, as it seems to have deployed it into my default dev hub org. Not a huge deal, given that neither of these environments is a Production org, but still not great.
I logged into my default org and opened the Flow… and it looks like it did what I was expecting!
The errors on each of the Assign elements was due to the Record_Group__c field not being in this org, but it had made the changes as I had expected and managed to deploy the Flow successfully.
At last! It wasn’t the result I was hoping for when I set out on this journey, but a win is a win. Looks like the Flow Man is evolving, and in the spirit of Salesforce, that comes with a name change… Flow and Agent Man (Flow Man 360 didn’t feel right)!
What I Learned
In my time working with Salesforce, I’ve had extensive experience working with Salesforce Flow Builder. One thing that I learned from this experience is just how much goes on behind the scenes. It’s impressive how much Flow Builder handles for us on the day-to-day without a second thought.
The other thing I learned is that just because a tool is designed by Salesforce does not mean that it knows everything about Salesforce intimately. Unfortunately, I saw multiple times how the Agentforce Vibes tool struggled to build the XML file from scratch. I’m sure this will change with further training.
For the time being, it might be better to stick to editing preexisting Flows. Or, honestly, it’s probably easier to just build the Flow yourself in the wonderful Flow Builder that has evolved and grown more powerful to support the increasingly advanced requirements that businesses throw at it.
I’ve also learned that it’s very important to start simple and evolve in steps with Agentforce Vibes. Think agile: start small, iterate, and make sure your instructions are super clear. Yes, it’s a powerful tool with a lot of pretrained knowledge, but it will still only ever do what it’s told – just like any other computer program (more or less).
Summary
Agentforce Vibes is really growing on me. I’m excited to see what it evolves into in the very near future. I’m also excited to see how developers leverage the tool to speed up their workflows, and how non-programmers use it to explore the programmatic options available to them (but more on that later – I have a great article coming soon).
What has your experience been with Agentforce Vibes so far? Have you managed to build a Flow from scratch? Are you enjoying your experience, or are you struggling to see the value yet? Can you tell I binge-watched the Star Wars Original Trilogy on the plane back from Dreamforce?
Comments: