A record of every change to your org
A change record answers three questions about any edit: what changed, who asked for it, and why. In a normal org those answers live in memory and a partial audit log. In a Git-tracked org they live in your repository, dated and attributed.
Nobody can say why the org is the way it is
A field on Case has a default nobody remembers setting. A validation rule enforces a condition that made sense for a process you no longer run. A permission set grants export to a role that should not have it. Each was a deliberate change once, made for a reason, and the reason is gone.
Setup Audit Trail. It tells you a change happened and who was logged in. It does not tell you what the thing said before, what it says now, or why it was done, and it does not reach back far enough to cover the ones that matter. It is a list of events, not an account of decisions.
Ask the people who were here. The answer is a half-memory from whoever was on the team at the time, if they are still on the team. For anything more than a few months old, the org’s history is whatever your longest-tenured colleague happens to recall.
The record is a byproduct, not a chore
Change logs go stale because someone has to remember to write them. The moment the record is produced by the act of making the change, it is always current and never a task. Every change carries its own entry because the entry is how the change is made.
And the entry holds what the audit log cannot: not just that a rule changed, but the exact before and after, the plain-English request that prompted it, and the person who approved it. That is the difference between knowing a change occurred and being able to explain it a year later.
What the record contains
What changed, exactly
The precise metadata diff: the lines added, removed, or altered, not a summary that can drift from the truth.
Why it changed
The plain-English request that produced it, stored with the change, so the intent behind the edit survives alongside the edit.
Who approved it
The human decision that let it reach production, attributed, so accountability is part of the record rather than a separate memory.
When, and what it replaced
The date and the previous state, so the history reads as a sequence of decisions you can walk backward through, not a single current snapshot.
Three independent records, hosted by you
A change tracked by FlowSprite leaves its trace in three places that do not depend on each other: the GitHub pull request carrying the original prompt and the review, the Git commit holding the metadata exactly as it read before and after, and the deploy event recording where it landed and when. All three live in your own GitHub organization for as long as you keep the repo — cancelling FlowSprite does not take them with it.
Alongside them, FlowSprite logs each Salesforce record read your AI makes (the tool, the object, the rows returned and the outcome) and each batch of a bulk record write. See how audit data is stored.
The record is not extra work layered on top of the change. It is what the change already is when it travels through a repository instead of a browser tab.
Who this is for
Anyone who has tried to explain a configuration decision they were not there for.
Alone, the history is the colleague you do not have to ask: you read why the field is the way it is instead of guessing or leaving it alone out of fear. On a small team, it is a shared account, so the org’s reasons are not distributed across three people’s memories and lost when one of them leaves. With auditors or a security review involved, it shows both the current state and how it got there, which is the part a screenshot can never provide.
Read your own history back
Let your metadata land in your repository, make a change or two through FlowSprite, and read what changed, why, and who approved it.
Start free in 2 minutes