About JamForce
JamForce is an independent Salesforce learning site for admins, developers and architects. It brings together structured learning paths, focused technical guides, and articles on the platform, its products and the roles around it.
I’m James Winter, a Salesforce Platform Architect based in New Zealand, and I write the articles on this site.
It started as a hobby and it still is one. Writing something up properly is the quickest way I know to find the gaps in my own understanding, so a good number of these guides began as me checking something I thought I already knew, then going back to the documentation or an org when the answer turned out to be less obvious than I assumed. Publishing them is the part I enjoy, and I hope they are of some use to you as well.
Who I Am
Section titled “Who I Am”
None of this was really the plan. I came to New Zealand for a trip and stayed, and I found Salesforce much the same way: I tripped over the platform while testing a wider architecture, had to learn a little about it to test it and an opportunity came up so I leaned in. Around a decade later, it is what I do.
Platform Architect is one of those titles that means different things at different companies. In my case it means I spend most of my time on the decisions that are expensive to reverse: data model shape, sharing and visibility design, integration patterns, and where the line sits between declarative automation and code.
My work has been across public sector, utilities, telecommunications, and financial services. Those industries have more in common than they look. They run large, long-lived orgs with real regulatory constraints, significant data volumes, and integration surfaces reaching well outside Salesforce. They rarely get the luxury of a clean rebuild, so most of the interesting work happens inside orgs already carrying years of decisions made by other people, often for reasons nobody wrote down.
Day to day that looks like reviewing an org that has outgrown its original design, untangling automation firing in an order nobody documented, diagnosing queries that were fine at ten thousand records and are not fine at ten million, and helping teams put sandbox and release practices in place so the same problem stops coming back.
The other half of the job is people. I have spent a lot of time mentoring admins and developers, reviewing other people’s Apex, and explaining to non-technical stakeholders why the thing they want is either a config change or a six-month programme, with very little in between. It also means strategy conversations with executives: where Salesforce fits alongside everything else they run, what the platform should and should not be asked to carry, and which problems are worth solving now rather than living with for another two years.
That background is the reason this site reads the way it does. When a guide here spends time on why a pattern matters before showing you the syntax, it is because I have watched the version without the reasoning get implemented, and then get unpicked.
Credentials and How to Verify Them
Section titled “Credentials and How to Verify Them”I hold 18 Salesforce certifications, earned between October 2018 and December 2023. Every one below is a Salesforce credential, so the shared “Salesforce Certified” prefix is dropped from the tables to keep them readable.
Two of them work differently from the rest. Application Architect and System Architect are composite credentials: they are not exams you sit, they are awarded once you hold the full set of underlying certifications beneath them. Application Architect sits on top of the data, sharing and visibility, app building, and development credentials. System Architect sits on top of integration, identity and access management, and development lifecycle. They are also the two prerequisites for the Certified Technical Architect review board, which is why the architect list below is shaped the way it is rather than being a scatter of unrelated exams.
Architect
Platform design across data, sharing, integration, identity, and release lifecycle.
| Certification | Earned |
|---|---|
| System Architect | |
| Platform Identity and Access Management Architect | |
| Platform Development Lifecycle and Deployment Architect | |
| Platform Integration Architect | |
| Application Architect | |
| Platform Data Architect | |
| Platform Sharing and Visibility Architect |
Developer
The programmatic side: Apex, SOQL, and the industry development stacks.
| Certification | Earned |
|---|---|
| Industries CPQ Developer | |
| Omnistudio Developer | |
| Platform Developer |
Administration and configuration
Declarative platform work, from core administration through app building.
| Certification | Earned |
|---|---|
| Platform Foundations | |
| Platform Administrator II | |
| Platform App Builder | |
| Platform Administrator |
Consultant
Solution design against the sales, service, field service, and Omnistudio clouds.
| Certification | Earned |
|---|---|
| Omnistudio Consultant | |
| Agentforce Field Service and Operations Consultant | |
| Agentforce Sales Consultant | |
| Agentforce Service Consultant |
Salesforce has renamed a number of these credentials over time, so several appear above under names that did not exist on the day they were earned. I have used the current names, because those are what the Trailblazer profile shows and what you can check against.
Certifications are easy to claim and easy to check, so here is how to check mine. My Salesforce Trailblazer profile is the authoritative record. It shows what I currently hold and whether it is still maintained, which matters because Salesforce requires ongoing release maintenance. LinkedIn covers the career history sitting behind them.
One honest caveat. If something on this site contradicts your experience of the platform, the certifications are not the reason to believe me. The reasoning in the article is. Certifications tell you I have covered the ground, they do not make a wrong article right, and I would rather you tell me I got something wrong than take it on authority.
Why JamForce Exists
Section titled “Why JamForce Exists”There is no shortage of Salesforce content. Most of it falls into two groups. There is the official documentation, which defines supported behaviour and explains what a feature does, but usually not when you should reach for it. Then there are articles written primarily to rank, which tend to cover the same five points about a topic in the same order, and stop exactly where the topic gets interesting.
What I kept finding missing was the layer in between: the reasoning. Why this pattern and not that one. What breaks at scale but rarely appears in a developer org. Which approach is technically correct according to the documentation and still a poor idea in a production org with fifteen years of history behind it.
So the rule across every guide here is that the why comes before the how. If a page tells you to bulkify a trigger, it first shows you what happens when you do not. If it recommends a query pattern, it explains what the query optimiser is doing and when that stops being true.
I also write it as someone still doing the work rather than someone who did it once and moved into producing content full time. That has a practical consequence worth stating: guides here get revised when the platform changes under them, and every page carries a published and updated date so you can see how current it is.
What You Will Find Here
Section titled “What You Will Find Here”JamForce publishes two kinds of content. The Salesforce guides provide structured learning paths and focused technical collections. The Salesforce articles examine one release change, migration, capability, or production problem at a time.
Use the guides when you want to build understanding in sequence. Use the articles when you already have a specific decision or problem in front of you.
How I Research and Check Content
Section titled “How I Research and Check Content”I pick topics that solve a practical learning or implementation problem, usually ones I have hit myself or watched a team hit. Claims about platform behaviour get checked against official Salesforce sources or verified in an org, and code examples are written to run rather than to illustrate.
I am careful to keep two things separate: first-hand observations are presented as experience, and researched guidance is not dressed up as a personal war story. Where I have not done something myself, the writing says so.
AI tooling helps with research organisation, drafting, editing, and consistency checks across the site. It does not replace source checking or editorial judgement, and it is not treated as a source of truth. I review, edit, and take responsibility for everything published here.
The Editorial Policy sets all of this out in full, including how release-sensitive claims are handled and how corrections work.
Advertising
Section titled “Advertising”JamForce may display advertising, including Google AdSense, to help cover the cost of running the site. Advertisers do not choose topics, review drafts, or influence conclusions. There are currently no paid sponsored articles and no affiliate links, and if that changes the commercial relationship will be labelled clearly. The Editorial Policy covers this in more detail.
Get in Touch
Section titled “Get in Touch”If something here is wrong, unclear, or out of date, I would genuinely like to know. Corrections are the fastest way to make the site better, and the corrections policy explains what to include.
Topic requests are welcome too. A good portion of what gets written next comes from readers asking about something the site does not cover yet. The Contact page has the form.