Annexes
Notes
Short notes on governance, rescue, operating models and AI in Salesforce, drawn from programmes I ran and courses I teach.
- Notes
- 15
- Updated
01 of 06 3 notes
Governance
Who decides what changes, and how technical debt gets a named owner.
- Salesforce governance: decision rights and release gates
Governance fails on unclear ownership before it fails on code: set decision rights at three levels, tier changes by blast radius, and gate every release.
- Salesforce Center of Excellence: capability before process
A CoE that only approves gets routed around. Split platform, delivery and demand work, keep the review scope narrow, and fund it with assets teams reuse.
- Salesforce technical debt: what to fix, schedule or tolerate
Zero debt is the wrong target. Classify Salesforce debt by blast radius and trajectory, give each item an owner, and re-tier the list every quarter.
02 of 06 4 notes
Rescue and org health
Stalled programmes, org reviews and migrations: what to check before prescribing.
- Why Salesforce implementations fail, and where it starts
Most failed Salesforce implementations are decided in discovery: broken processes automated, shared objects with no owner, integrations left for later.
- Salesforce project rescue: the first 90 days
A Salesforce rescue runs as three gates with owners and exit deliverables: contain, stabilise, then prove the team can deploy again.
- Salesforce data migration: what to prove before cutover
A migration is decided before the first load: an owner per object, reconciliation counts the business signs, full rehearsals and a rollback deadline.
- Salesforce org review: a checklist a sponsor can use
A useful org review reads the decisions behind the org in five areas and ranks each finding by blast radius and effort, so someone can act on it.
03 of 06 2 notes
Operating model
Decision rights written into the RFP and the org strategy, not discovered after go-live.
- Salesforce RFP: test the operating model before the plan
A Salesforce RFP should test decision rights, design authority and ownership after handover before it compares delivery plans or day rates.
- Single org or multi-org: an operating-model decision
The Salesforce org question is settled by who owns the shared data definitions, who can release when, and which org is the system of record for each object.
04 of 06 3 notes
AI in Salesforce
Agents and prompt templates: what the sponsor must demand, test and govern.
- Agentforce operating model: who owns changes after go-live
A production Agentforce agent keeps its boundaries only if a change contract names who turns subagents on, approves actions, edits instructions and stops it.
- Agentforce PoC to production: turn the demo into a decision
An Agentforce PoC should end in a go, fix-and-retest or stop decision, and production should wait for data, access, a stop owner, a test set and a support path.
- Prompt Builder: what to demand, test and govern
A Prompt Builder template is production configuration: it needs an owner, a limit on what it reads, an approved test set and a named list of who may change it.
05 of 06 1 note
Korea
Personal data leaving Korea: the checks to prepare before a contract.
- Salesforce and Korea's PIPA: seven checks before you sign
Checking the region does not close a PIPA cross-border review. Seven points to settle with counsel and the privacy officer before a Salesforce contract.
06 of 06 2 notes
Field notes
Dated observations, kept for what they still teach.
- Dreamforce 2026: what is available, what is announced
Sort each Dreamforce 2026 announcement by what Salesforce says is available now, in pilot or only dated, before a programme plan depends on it.
- What a year of running three autonomous agents taught me
For a year, three AI agents ran my back office. The failures were silences, and the governance rules that caught them outlived the setup.
Contact
Is this on your table?
Tell me where your programme or your team stands, and what you need to decide.
Request a call