RI
Ramesh Iyer
Applicant — no login
“I have a flight in three weeks. I just want to know where my file actually is.”
Build first, then teach
Learn Salesforce by watching a real system get built
I build the app first. Then I take it apart and show exactly how it was made — the objects, the sharing rules, the triggers, the tests, and the decisions that turned out to be wrong. It's how I teach Salesforce, and how I keep my own skills sharp.
1
Build the thing
A working passport office in Salesforce — intake, verification, approvals, printing, despatch. Real metadata, deployed to a real org, with real tests.
2
Take it apart
Every lesson picks one decision from that build and explains what it is, why it exists, and what breaks without it — using the code that shipped.
3
Keep it honest
The build log keeps the dead ends and the bugs in. Teaching something is the fastest way to find out you only half understood it.
What gets built
A Passport Seva Kendra: the office that takes an application at a counter, verifies the documents, sends the police to check the address, authorises the passport, prints the booklet and couriers it out. Grouped below by the layer of the org each piece lives in.
Data model
8 objects · ~135 fields
-
One object for the whole lifecycle. Draft to Delivered on
Passport_Application__c, driven by a Status picklist — not one object per stage. - Record types that subset picklists. Five of them, and a sixth that got deleted because its subset was identical to another.
- Master-detail vs lookup, argued both ways. Checklist items cascade; police verifications deliberately do not.
- Roll-up summaries replacing checkboxes a human had to remember to tick.
- Snapshot a declaration, derive a fact. The application freezes what was declared; the booklet derives everything from it.
- A self-lookup chaining each re-issued booklet to the one it replaced.
Automation
triggers · flows · approvals
- The order of execution, and the four consequences that shape every design choice in the build.
- All seven trigger contexts, each introduced by the one thing only it can do.
- A stage machine that mints the checklist, the verification, the booklet and the dispatch on the right transitions.
- Idempotency guards on every create — because a duplicate passport is not a bug report.
- An approval process, because a validation rule can block but cannot record who decided.
- Before-save vs after-save flows, and why putting the wrong logic in each costs you a DML.
Security & sharing
personas · OWD · sharing rules
- Two independent gates. What you can do, versus which records you can do it to.
- Personas as permission sets composed into groups — never as cloned profiles.
- Criteria-based sharing, so escalation is a standing query rather than something to remember.
- The two things sharing rules cannot read — formulas and lookups — and the stored field that works around both.
- Field-level security on PII, configured separately from object access.
- Queues, so ownership survives someone being on leave.
Apex & services
trigger → handler → service
- One trigger per object, containing no logic at all.
- The handler pattern, and the four reasons it beats logic in the trigger body.
- Bulkification — no SOQL or DML in a loop, ever, and a test that fails if you add one.
- Custom metadata in Apex, so changing a fee is a deploy of a record, not a code change.
-
Queueable, Batch and Scheduled — one real use each, and why
@futureis deliberately unused. -
with sharingandUSER_MODE, so code respects the security model rather than bypassing it.
UI & apps
4 apps · LWC · Lightning pages
- An app is a navigation boundary, not a data boundary — one record travels through all four.
- Dynamic Forms, so guardian fields appear only when the applicant is a minor.
- Dynamic Actions, so one record page serves five personas with different buttons.
- Path, giving the lifecycle a stage bar with guidance at each step.
- Lightning Web Components — wire vs imperative Apex, events, and Lightning Data Service.
- List views as work queues, which is how an officer actually works a stream of records.
Testing & proof
5 layers · unattended E2E
- Tests that would fail if you deleted the code they cover — the mutation-test instinct.
- Bulk tests at 200 records, catching the failure single-record tests cannot see.
-
System.runAstests that prove the security model by what it refuses. - A test data factory, because a test that depends on org data passes locally and fails in a fresh org.
- Flow tests and Jest, so declarative logic and components are covered too.
- A narrated end-to-end run that drives the real org and publishes what it saw.
8Objects in the finished org
4Apps, one per job
9Personas as permission sets
24Demo scenarios, failures included
5Layers of testing
The org itself
What the finished build actually looks like to the people who use it.
Who uses it
Nine personas, one of whom never logs in — and he's the one who keeps every other decision honest.
PD
Priya Deshmukh
Front Office Officer
“I need to save a half-finished form while the applicant hunts for a document.”
AN
Anjali Nair
Document Verification Officer
“If I flag a problem, it has to say which document and why — not just "there's an issue".”
Built with
Everything in the org is version-controlled SFDX source, deployed from the command line.
Salesforce Platform
SFDX source format
Salesforce CLI
Apex
Lightning Web Components
Flow Builder
Custom Metadata Types
Approval Processes
Standard Case
Jest
Jekyll
Git
The build log
A chronological account of how this actually got built — including the decisions that were wrong, and the bugs that only surfaced because a test was fixed properly instead of loosened.
Read the build logThe design
Personas, the user journey, the trigger catalogue, the access matrix and the scenario design — the work that happened before the org was touched.
See the design