Today we are launching FlowSprite. It is a change management tool for Salesforce Admins: describe the change you want in plain English, and FlowSprite produces the actual metadata change, delivers it as a pull request in your own Git repository, deploys it to your sandbox, and holds production until a human approves it.
This post covers what it is, who it is for, and why we built it.
The pain: every small change is either risky or slow
A request lands in Slack on a Tuesday afternoon. Add a field to Opportunity; make it required on the closed-won path; update the page layout so sales actually sees it.
The admin knows exactly what needs to happen. The problem is not knowledge. The problem is the path to production, and there are usually only two:
- Click it in production. Fast, and it works most of the time. There is no record of what changed, no reviewer, no rollback, and no visibility into what downstream automation just broke. Every change is a small unlogged bet.
- File a ticket. The change goes into a developer or DevOps queue, gets scheduled against a release train, and lands three weeks later. By then sales has stopped waiting; they are tracking it in a spreadsheet instead. That spreadsheet never goes away, and nobody notices until someone tries to run a report on data that is no longer in Salesforce.
Neither option is a failure of the admin. It is a structural gap: the discipline that makes changes safe (version control, sandbox testing, peer review, an approval gate) was built by and for developers, and the tooling reflects that.
The practical effect is that safety became something an admin has to ask permission for. You can have speed on your own, or you can have a process, but the process belongs to somebody else's team and runs on their calendar. Most admins choose speed, not because they are careless, but because it is the only option they fully control.
The bridge: the practice was never the problem
Two things have been true for a while.
First, the safety practices genuinely work. Track every change in version control; test in a sandbox before production; have a second pair of eyes review; require an explicit human approval before anything touches live data. Teams that do this ship faster with fewer incidents. Nobody disputes this.
Second, admins should not have to become developers to get those benefits. The value an admin creates is understanding the business process and the org. Learning Git branching strategy just to ship a field change is not part of the job; it is a tax on it.
What changed recently is the translation layer. Turning "make this field required when the stage is closed-won" into correct, deployable Salesforce metadata is a task that models are now genuinely good at. That closes the gap between how admins think about changes and the format that safe deployment requires.
That is what FlowSprite is: the translation layer, plus the guardrails already known to work, packaged so an admin can use them on day one.
FlowSprite: what it actually does
You describe the change in plain English. FlowSprite does the rest:
- AI layer. Your request is translated into the specific Salesforce metadata change it implies, scoped to your org.
- Git as the source of truth. The change arrives as a pull request (PR) in your own Git repository. Every change is versioned, attributable, reviewable, and revertible. Your metadata history lives in your account, not ours.
- Sandbox first. Changes deploy into your sandbox before anywhere else. You see the result in a real org before it matters.
- Production behind a human gate. Nothing reaches production without an explicit human approval. The AI proposes; a person decides.
The important design choice is what we did not automate. FlowSprite does not push to production on its own. The approval step is not a setting you can turn off for convenience; it is safety provided by the product.
We have also included the official Claude skills Salesforce introduced with its Winter '27 release, the set covering permission sets, flows, debugging, and platform best practice. Those skills are knowledge: they make an agent better at Salesforce tasks. What they do not carry on their own is the review step, the sandbox, the approval gate, and the record. FlowSprite is what wraps that knowledge in the infrastructure to use it safely.
Who FlowSprite is for
Anyone who makes changes in a Salesforce org.
The situation around you differs, but the need does not: get the change live without guessing what it might break. FlowSprite gives every admin the same starting point, which is a versioned history of every change, a sandbox to see it in before it counts, and an approval step you control.
What that is worth grows with the team. On your own, it means you finally have a process behind you instead of a browser tab and good instincts. With colleagues, it means a shared record of who changed what and why, and reviews that happen in one place instead of over Slack. With an engineering team, it means your changes arrive as pull requests in the same repository they already use, so what you ship is legible to them from the start.
If your org already has a release process, FlowSprite works alongside it rather than around it. Everything lands in your Git repo in a standard form, which is exactly what a pipeline expects.
Why we are launching, and why the price is on the page
We built FlowSprite because the safety gap in the Salesforce admin workflow is not a training problem or a discipline problem. It is a tooling problem, and it was solvable.
Pricing is 99-199 EUR per month, published openly on the site. No quote gate, no discovery call before you learn the number, no annual commitment required to find out whether this works for you. Try it, decide for yourself, and talk to us only if you want to.
Get started — 30 days free if you start this week
Try it at flowsprite.com/launch. Sign up by September 18 and your free trial is 30 days instead of 14, no credit card. Connect a sandbox, describe one change you have been putting off, and see what comes back as a pull request.
If it does not do what you need, tell us. We are at the start of this, and the roadmap is being written by the people using it.