SympleOps
Salesforce Knowledge Management
The quietest form of Salesforce risk is undocumented intent. The automation works, and nobody remembers which conversation produced it. This page covers what institutional knowledge in a Salesforce org actually consists of, and why the usual responses to losing it do not work.
Every org has a set of things that are true for reasons nobody currently employed can explain. The second condition in a validation rule. The field that must not be renamed. The Flow that runs before another one, deliberately.
None of these are problems while the person who knows is still there. They become problems the week after they leave, and they usually surface in the middle of an unrelated change.
What counts as institutional knowledge
It is worth being precise, because "documentation" is the wrong frame and produces the wrong artefacts.
What was built
Recoverable from the metadata. Tedious but possible.
Why it was built
Not recoverable from anything. This is the part that actually gets lost.
What was rejected
The options considered and ruled out, so they are not re-proposed every two years.
Who asked, and what changed
The organisational constraint behind the technical decision, which is usually the real reason.
Why wikis and handover documents fail
Not for lack of effort. Three structural reasons:
- They are written at the wrong time. By the time someone documents a system, they have already forgotten the details that mattered. The reasoning was available during the work and nowhere afterwards.
- They are disconnected from the change. A wiki page describing a Flow cannot tell you which change introduced it, or which of the three wiki pages is current.
- They have no owner. Documentation goes stale the moment the last person who edited it moves teams, and nothing detects that it is now wrong.
The cost of losing it
The visible cost is slower onboarding. The expensive cost is behavioural: teams stop changing the parts they do not understand. You get "we would rather not touch that" in planning, and a slow, permanent narrowing of what the org is willing to improve.
It also converts every future change in that area into a research project, which is the previously discussed technical debt arriving from a different direction.
Capturing it as a by-product
The only approach that survives contact with a delivery schedule is capturing the reasoning while the work is happening, as part of the change rather than as a task after it.
SympleOps keeps requirements, reasoning, approvals and artifacts connected to the change — every change records what was built, by whom, and why. Company Knowledge is built on the premise that you should be able to know what was built and why, and trace an answer back to its source, without asking the person who built it.
Knowledge that compounds
The second-order benefit is easy to underestimate. Once reasoning is captured, it stops being a record and starts being context: the patterns, decisions, dependencies and rules the team has already proven become inputs to the next request rather than lessons rediscovered.
That is the difference between a knowledge base and institutional memory. One is a place documents go to age; the other changes how fast the next change can be made safely.
Where to go next
For the structural consequence, see Salesforce Technical Debt; for the moment it becomes visible, Salesforce Bug Investigation; for who normally carries it, AI for Salesforce Admins.
See what your org remembers about itself
SympleOps keeps the reasoning attached to each change, so the answer to "why is it like this" does not depend on who is still on the team.