Overview
- Claude’s Fable Model was released; I tested it against some Salesforce tasks that other off-the-shelf models have struggled with in the past.
- Ultimately, its performance was better than I had anticipated it would be without additional Salesforce-specific training.
- I pondered what the future of “clicks, not code” on the Salesforce platform could be as models get more powerful and produce better results.
- Claude pulled Fable at the request of the US Government, citing national security concerns.
Anthropic said that its Mythos model was too powerful for the public. Last week, it dropped the Fable model. They claim that Fable is a ‘safer’ version of Mythos that is accessible to the general public.
These are some pretty intense claims, so I thought I’d put them to the test in a few areas of my life. For example, I built features and tools for my Mac that I’d been waiting for Apple to release for years in minutes. I also successfully one-shot prompted a video game combining some of the mechanics from Stardew Valley with other mechanics of Old School RuneScape. I was impressed and decided to give it a real challenge: Salesforce.
First, A Temporary Setback
If you’re reading this, you may be wondering why I’m talking about Anthropic’s Fable model after it’s been pulled from the shelves. The reason is that I was blessed to have my time with Fable before this occurred, and I strongly believe my experience is worth sharing now more than it was before.
For those who didn’t get a chance to work with Fable yet but were curious how it would fare in the Salesforce world, I hope details of my experience show you what this model was capable of and what future models may bring. When Fable returns (it looks as though it will, even if only to a limited audience), then please do some testing of your own and compare your experiences with mine.
The Inspiration
I was chatting with Peter Chittum, who sent me a LinkedIn post from Mohith Shrivastava (Principal Developer Advocate at Salesforce). Mohith had a Salesforce org with over 100 Apex classes, multiple Flows, a complex data model, and validations throughout. Not a simple structure! He asked Fable a simple question: Users are reporting that <feature_name> is failing in the org. Can you troubleshoot it?
He then watched in amazement as it was able to identify the correct class, discover the problem that was occurring, identify the source of the error, and provide a solution that would work.
This inspired me… if you’ve read my previous article where I attempted to build a simple Flow with AI, you’d know that I wasn’t super impressed. Mohith’s post inspired me to give Fable the chance to prove itself!
Challenge 1: Building a Flow from Scratch
I decided to give Claude Fable the same challenge I first gave Agentforce Vibes when it first came out:
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”.
And, within minutes, it claimed to be done! It asked me where it wanted me to have it deployed, and I said I would handle the deployment myself, which is why you see “Tool use rejected” in the log.
I opened a second parallel terminal window and attempted to deploy the Flow myself. This is where any other vibe-coded Flow tests that I’d performed in the past on an untrained, off-the-shelf model got stuck. The moment of truth…
After seeing that the Flow was “Created”, I immediately checked to see the Flow with my own eyes, and sure enough, there it was in all its glory! It did exactly what I had asked it to do. Claude’s Fable had achieved something that Agentforce Vibes – a model apparently trained heavily on Salesforce data – was not able to do.
With that successfully done, I decided to take things a step further…
Challenge 2: Smart-Clone a Flow
Seeing that Claude Fable had taken the previous Flow build in its stride, I decided to take it a step further. I wanted to see how little context I could give Fable in return for a successful outcome. I’d previously built a simple Flow that retrieves Contacts related to an Account, checks to see whether or not they’d actually been retrieved, and then sets some output variables. It also has descriptions that reference the Contacts object specifically, as well as a fault path.
This is a common pattern that is used in many Flows, so I wanted to see how well Claude Fable could clone it for new objects. Inspired by Mohith’s lack of giving context in his query, I decided to omit the Flow name while requesting that it be cloned to pull the Opportunities instead of Contacts from the Account.
I have an autolaunched Flow that retrieves Contact records related to an Account. I want you to create a new Flow that does the same thing, but gets Opportunities instead.
After “Flibbertigibbeting” for less than a minute, Claude Fable figured out which Flow I was referring to and had built a new one that apparently did what I was asking for. Notably, despite clearing the history from the last session, Fable left the deployment to me intuitively.
After deploying it manually myself and overseeing a successful creation, I had to once again open it in the UI and see for myself. After seeing both titles next to each other in the Flow List View, I knew we were off to a good start.
I couldn’t believe my eyes. The Flow was built exactly as I had hoped, including the Fault path and changing of “Contact” references to “Opportunities” in the Descriptions. All this with an off-the-shelf LLM with no extra custom Salesforce training data!
With that, I decided to give Claude Fable one last challenge. This time, we weren’t going to be building Flows, but rather converting Flows to Apex.
Challenge 3: One-Shot Build an Apex Class
Writing Apex seems to be a lot easier for the LLMs I’ve tried, as there’s less fluffy syntax hiding under the covers. Out of pure curiosity, I decided to see how easily, with very little in the way of context, I could get Claude Fable to combine these two Flows into Invocable Apex actions:
I have two Flows that get Contacts and Opportunities from an Account and return them in a list. I want you to convert these into a single invocable Apex class if possible. Write test classes that pass 100% as well.
If you read the above correctly, you’d notice that I have tried to trick Claude Fable – you cannot have two methods marked as @InvocableMethod in a single class. I was curious if Fable would be able to adapt to this. I also decided not to lean into the “make no mistakes” aspect of vibe coding, where I don’t clearly explain what I want in the test class and just see what it does. Once again, I didn’t tell Fable which Flows I was referring to – I wanted it to figure that out for itself.
Almost immediately, it identified the two Flows from earlier and had written the Apex artefacts. It asked which org to run the tests in, and I specified to validate only, but not deploy. All tests passed successfully, and I was left looking at the success screen.
If you’ll notice, I actually set up my Flow incorrectly, and Claude Fable identified and fixed it in the Apex Class. I’m going to play it smooth and pretend I did that on purpose as a test (in reality, I bumbled it). That being said, I did leave a small test in there for Fable to find – the fact that you cannot have two invocable methods in a single Apex Class.
Luckily, it adapted the requirement and wrote it in a more scalable way – One class, one method, but the Object Name and Fields to Query as input parameters.
I deployed this into my test org and ran the tests, no issues! Very impressive. As a bit of a bonus, I asked Claude Fable to develop a script I could run anonymously. It quickly wrote me a few lines that I ran in Web Console, and successfully ran and found the Contacts that I had against the test Account that I created.
My Realization
This series of tests got me thinking, and I had two major realizations. Firstly, off-the-shelf LLM tools can now build Flows effectively. There doesn’t seem to be a need for additional custom training to get the basic syntax right, and it seems to understand instructions with much better context. Secondly, given the first realization and how easily Fable was able to convert my two Flows into a much more scalable Apex… what is the future of Salesforce Flow in the AI world?
This is something that has been playing on my mind for a few months now. Salesforce Flow will always be my favorite tool, and the one that cemented my obsession with Salesforce at the beginning of my career. I loved that it empowered non-coders like myself to create value at scale for my organization. However, in 2026, AI is doing the same thing but isn’t limited in terms of output.
Let me explain that a bit better. Flow Builder puts a clean UI together that lets non-coders build complex business processes into platform automations and saves them as an XML file. Large Language Models also put a clean UI (albeit slightly less friendly and visual when compared directly to Flow Builder) together that lets non-coders build complex business processes into platform automations… but it then saves it into a far more standard format of the builder’s choosing.
When you save a Flow, only those who understand Flow Builder can make further changes. When you save the output of an AI coding tool into something like Apex, HTML, CSS, JavaScript, Python, or Swift, it can be edited by someone who fluently reads and writes those languages, or by someone who has an AI coding tool at their disposal.
The reason I fell in love with Salesforce Flow in the first place is that it made configuration and customization more accessible. In 2026, I’m beginning to wonder if the opposite is happening. This is something I’d love to investigate further in the near future.
Summary
I’m very impressed with Claude’s Fable model. According to various benchmarks, it’s currently the most capable model in many areas. The ability to one-shot vibe code multiple Flows, as well as convert those Flows to scalable Apex code, makes it a tool that you don’t want to ignore. It also brings up the uncomfortable feeling that maybe Salesforce Flow’s golden era is behind it, with models like Claude Fable able to output more standard artefacts.
What are your thoughts on Claude’s Fable model? What are your experiences in working with it so far, in Salesforce and beyond? Are you starting to question where Salesforce Flow will sit in the grand scheme of things in a few years’ time?
