Interactive Salesforce Fundamentals Training Guide 11 modules covering Developer and Business Analyst topics
Salesforce Fundamentals Guide
11 modules · Developer & Business Analyst track
Module 1 What is this course?
Setting context for students on day one
What to tell students
This is a 5-day intensive training program that covers Salesforce from both a technical developer perspective and a business analyst perspective. The goal is not just to pass a certification — it's to work effectively on real enterprise Salesforce projects where developers and BAs collaborate every day.
Why Salesforce matters
Salesforce is the world's #1 CRM platform with over 150,000 enterprise customers. It runs Sales, Service, Marketing, Healthcare, Nonprofits and more from a single platform. Developers who know SF + Agile are among the most in-demand IT professionals.
What students will be able to do
Write Apex code & triggers · Query data with SOQL · Design data models · Create user stories and personas · Prioritize a backlog · Understand all major SF clouds · Use Agentforce AI tools · Deploy code through sandboxes
Instructor tip: Open Day 1 by asking students: "Have you used a CRM before? Have you been on a Scrum team?" This reveals baseline knowledge and helps you calibrate how much time to spend on fundamentals vs. advanced content.
Understanding who does what on a Salesforce project
Instructor framing: Tell students that on most SF projects, developers and BAs work side-by-side in the same sprint. A BA writes the story; the developer builds it. Both must understand each other's language. This course teaches both.
Salesforce Developer
1
Apex Classes & Triggers — Back-end server-side code that runs on Salesforce's multi-tenant platform, similar to Java but cloud-native.
2
SOQL / SOSL — Querying the Salesforce database. Like SQL but works on objects, not tables.
3
Lightning Web Components (LWC) — Front-end UI framework built on modern Web Components standard. Replaces legacy Visualforce pages.
4
REST/SOAP API Integration — Connect Salesforce to external systems like ERP, marketing tools, or custom apps.
5
Sandbox & Deployment — Moving code safely from development to production using version-controlled pipelines.
Business Analyst
1
Requirements Elicitation — Interview stakeholders to discover what the business needs the system to do.
2
User Stories — Convert requirements into structured stories: "As a [user], I want [feature] so that [benefit]."
3
WSJF Prioritization — Score and rank stories by business value, time criticality, and risk to decide what gets built first.
4
Journey Mapping & Personas — Visualize how real users interact with the system from first contact to goal completion.
5
UAT & Sign-off — Run User Acceptance Testing with business users before go-live to validate the system meets needs.
Key point to emphasize to students
The best SF professionals can do both. A developer who understands user stories and business value is far more effective than one who only reads technical specs. A BA who understands Apex governor limits and SOQL will write far better stories and acceptance criteria.
Module 3 Scaled Agile Framework & Design Thinking
How enterprise SF projects are organized and how we discover what to build
SAFe — The three levels explained
SAFe (Scaled Agile Framework) is how large organizations run Agile across many teams at once. Unlike a single Scrum team, enterprise SF projects have dozens of teams working on related things simultaneously. SAFe gives them structure.
PORT
Portfolio Level — The C-suite and Product Management decide the strategic direction. They define Epics (large bodies of work), approve budgets, and manage the Lean Portfolio. On a SF project, this might be: "We will implement Service Cloud for the entire support organization."
ART
Program Level (ART) — The Agile Release Train. Multiple scrum teams (5–12 typically) that plan together every 8–12 weeks in a Program Increment (PI) Planning event. They break Epics into Features and assign them to teams. This is where the 12-month roadmap lives.
TEAM
Team Level — Individual scrum teams run 2-week sprints. They break Features into User Stories, estimate with story points, run daily standups, and demo completed work. This is where Apex code gets written and tested.
Design Thinking — The 5 stages
Design Thinking is a human-centered approach to discovering what to build. It prevents the classic mistake of building the wrong thing perfectly. On SF projects, BAs use this before writing a single story.
Goal: Understand the real users deeply before solving anything.
Conduct user interviews, observe workers doing their jobs, and create empathy maps that capture what users say, think, do, and feel. On a Salesforce project: shadow a sales rep for a day. Watch how they currently log calls and update opportunities. You'll discover pain points no requirements document would ever capture.
Goal: Synthesize your research into a clear problem statement.
Write a Point-of-View (POV) statement: "[User] needs [need] because [insight]." Ask "How Might We?" questions. Example: "How might we help sales reps log calls in under 30 seconds so they spend more time selling?" This becomes the north star for the entire feature design.
Goal: Generate as many solutions as possible — quantity over quality first.
Brainstorming sessions, Crazy 8s (8 sketches in 8 minutes), dot voting. Don't judge ideas yet. A bad idea in a brainstorm often sparks a brilliant one. For SF: maybe a Voice-to-Text field on the Activity object, a quick-log Flow, or an Einstein Activity Capture integration.
Goal: Build a cheap, fast representation of your top ideas to test.
On SF projects this means: wireframes in Figma, a rough Flow Builder prototype, a mock page layout — anything users can react to without writing Apex code. Prototyping in SF sandbox is also valid for low-risk features.
Goal: Put the prototype in front of real users and learn fast.
Watch them use it silently. Don't explain. Don't defend. Just observe and note where they get stuck. Gather feedback, update your understanding, and iterate. This cycle may repeat 3–5 times before a story is written. Design Thinking prevents building a perfect solution to the wrong problem.
Persona development the concept
A persona is a realistic fictional character representing a group of users who share the same goals and challenges. Personas are NOT demographics. They are behavioral archetypes.
Good persona format: Name + role · Their goal in using SF · Their biggest pain point · Their technical comfort level · A quote that captures their frustration
Class exercise: Have students pair up and interview each other as if they are a "Sales Rep using Salesforce." One student plays the user, the other interviews and builds a persona card. Then they write one HMW question from it.
Module 4 User Journey Maps, Epics, Features & Stories
From big idea to buildable unit — the Agile decomposition model
User Journey Maps what they are and why they matter
A journey map visualizes the complete experience a user has with a system — every step, emotion, and touchpoint — from first interaction to goal completion. On SF projects, journey maps reveal where the system should exist in the user's workflow and what it should do at each stage.
The example in the slide shows the Lead to Opportunity journey in Sales Cloud: Awareness → Qualification → Demo → Proposal → Negotiation → Close. Notice the emotions row — a prospect who is "anxious" during Negotiation tells us we need transparency features (price calculators, contract previews) at that stage.
The Agile decomposition hierarchy — explained in depth
Think of this as nesting dolls. Each level breaks the one above it into smaller, more concrete pieces. Everything ultimately gets built at the Story level.
E
Epic — A large initiative that takes multiple sprints or even multiple PIs to complete. It has a hypothesis and a measurable outcome. Example: "Implement Service Cloud for the US Support team — reducing average case resolution time from 48 hours to 24 hours." Portfolio levelWritten by: Product Manager / BA
F
Feature — A service or capability that delivers value to a user within a single PI (8–12 weeks). Features describe the "what" not the "how." Example: "Automatically route cases to the right agent based on skill and region." Program levelWritten by: Product Owner / BA
S
User Story — A small, independently deliverable piece of value. Must fit in one sprint. Uses the standard format: "As a [type of user], I want [goal] so that [reason]." Must have clear Acceptance Criteria. Example: "As a support agent, I want cases to auto-assign based on my skill set so that I only receive cases I'm qualified to resolve." Team levelAcceptance Criteria: Given/When/Then format
T
Task — A technical sub-step to complete a story. Not customer-facing — these are for the developer's benefit. Example: "Write AccountCaseRouter Apex class," "Write test class with 95% coverage," "Deploy to Developer sandbox," "Create Flow to trigger routing logic." Developer creates theseNot shown in sprint backlog
Writing good acceptance criteria the Given/When/Then format
Acceptance criteria define exactly when a story is "done." They must be testable. Vague criteria like "the case should route correctly" lead to disagreements at sprint review. Use Given/When/Then:
Given a new case is created with type = "Billing" and no assigned agent When the case is saved Then the case is assigned to an agent with "Billing" skill in the same region as the account
Class exercise: Give students a feature ("Automated lead scoring") and have them write 3 user stories and 2 acceptance criteria each. Then they swap and critique each other's criteria for testability.
Common mistake: Students often write stories that are too large ("As a user, I want the entire billing module"). Remind them: if a story takes more than one sprint, it's actually a Feature. Break it down further.
Module 5 — WSJF Prioritization & Roadmap Development
Making data-driven decisions about what to build and when
What is WSJF and why do we use it?
WSJF stands for Weighted Shortest Job First. It's a SAFe prioritization technique that prevents the two most common backlog mistakes: building what's loudest (HiPPO — Highest Paid Person's Opinion) and building what's easiest. WSJF scores features by dividing how urgent they are by how big they are.
The formula is: WSJF = Cost of Delay ÷ Job Size
Cost of Delay — the three components
1
User/Business Value — How much value does this deliver to users or the business? A feature that increases close rates for 500 reps scores much higher than a UI theme change. Score: 1–13 (Fibonacci)
2
Time Criticality — Does the value decay if delivered late? A compliance deadline or regulatory requirement is extremely time-critical. A dashboard redesign is not. Score: 1–13
3
Risk Reduction / Opportunity Enablement — Does this item unlock other features or reduce technical risk? Migrating to the new data model enables 5 future features — that scores high. Score: 1–13
WSJF scoring table — walk students through this
Feature
User Value
Time Crit.
Risk Red.
CoD Total
Job Size
WSJF
Auto-Case Routing
8
8
5
21
3
7.0 ← Build first
Health Cloud EHR Sync
13
13
8
34
5
6.8
Apex Batch Jobs
5
3
8
16
5
3.2
LWC Dashboard
8
5
3
16
8
2.0
Einstein Lead Scoring
13
8
5
26
13
2.0
Notice that Einstein Lead Scoring has a CoD of 26 (very high value!) but it scores the same WSJF as the dashboard because it's so large (13 story points). The right move is to break Einstein Lead Scoring into smaller chunks to improve its WSJF score.
The 12-month roadmap structure
A roadmap is a time-based visual plan that shows what will be delivered in each Program Increment (PI). It is NOT a commitment — it's a plan based on current knowledge. PIs are typically 8–12 weeks. A 12-month roadmap typically has 4 PIs. Each PI contains 3–5 Features. The roadmap must be reviewed and adjusted after each PI based on what was learned.
Roadmap ≠ project plan. A project plan says exactly what will happen when. A roadmap shows intent and direction. It changes as the team learns more.
Agile ceremonies every student must know
PI Planning
2 days · Quarterly · All teams plan the next increment together
Sprint Planning
2 hours · Bi-weekly · Team commits to stories for the sprint
Daily Standup
15 min · Daily · What did I do? What will I do? Any blockers?
Sprint Review
1 hour · Bi-weekly · Demo completed work to stakeholders
Retrospective
1 hour · Bi-weekly · What went well? What to improve?
Module 6 — Salesforce Data Model & Sandbox Strategy
The foundation every SF developer and BA must understand deeply
The Salesforce data model — objects, fields, relationships
In Salesforce, there are no "tables" and "rows" — there are Objects and Records. An Object is like a database table definition. A Record is one row of data. Fields are columns. Understanding this mapping from relational DB concepts to Salesforce is critical.
Core standard objects every student must memorize
Acc
Account — Represents a company or organization. The "parent" of most other objects. Contacts, Opportunities, Cases all link back to Account.
Con
Contact — A person at an Account. Has a Lookup relationship to Account. Can have multiple Contacts per Account.
Opp
Opportunity — A potential sale. Has a Master-Detail relationship to Account. Contains Stage, Amount, Close Date.
Case
Case — A customer support request. Links to Account and Contact. Has Status, Priority, Owner fields. Core of Service Cloud.
Lead
Lead — An unqualified prospect not yet linked to an Account. When "converted," creates Account + Contact + Opportunity automatically.
Camp
Campaign — A marketing activity (email, event, ad). Tracks ROI via Campaign Members — Leads or Contacts who responded.
Relationship types — the most-tested topic on SF exams
Master-Detail The child record cannot exist without the parent. Deleting the parent deletes all children. Ownership of the child rolls up to the parent. Example: Opportunity Line Items → Opportunity.
Lookup A loose reference. The child can exist without the parent. Deleting the parent doesn't delete the child (field becomes blank). Example: Contact → Account.
Many-to-Many Implemented using a Junction Object — a third object with two Master-Detail relationships. Example: Campaign Member connects Lead/Contact to Campaign.
Hierarchical Only available on the User object. Allows a User to reference another User as their manager. Used for role hierarchy and territory management.
Sandbox strategy — how to teach it
The golden rule: NEVER develop directly in Production. Sandboxes are copies of your org used for development, testing, and staging. There are 4 types — students frequently confuse them.
Free with every SF org. Copies configuration only — no data. Refreshes in minutes. Used by each developer to write and test code in isolation. Every developer gets their own. Storage: 200MB data, 200MB files. Use for: Writing Apex, building Flows, creating page layouts.
Larger version of Developer sandbox. 1GB data storage. Used for more complex development, performance testing with larger datasets, or when integration testing requires more data. Still config-only copy. Use for: Complex Apex batch jobs, SOQL performance testing.
Copies configuration + a sample of real data (you define a sandbox template selecting which objects to copy). Up to 5GB storage. Refresh takes 1–2 hours. Use for: User Acceptance Testing — business users test against data that looks real. QA testing of integrations.
Exact copy of Production — all data, all configuration. Can take 24–72 hours to refresh. Very expensive. Use for: Performance and load testing, final regression testing before a major release, training environments that need real data volumes.
Module 7 — SOQL, Apex Code & Triggers
The technical core for Salesforce developers
SOQL — Salesforce Object Query Language
SOQL is how you query Salesforce data in Apex code and developer tools. It looks like SQL but differs in important ways: no SELECT *, no JOINs (use relationship queries instead), and it runs inside Salesforce's multi-tenant database with governor limits.
Teaching SOQL — 3 query patterns students must know
Pattern 1: Basic SELECT with filter and sort
SELECT Id, Name, Industry, AnnualRevenue
FROM Account
WHERE Industry = 'Technology'AND AnnualRevenue > 1000000ORDER BY AnnualRevenue DESCLIMIT100
-- Child-to-Parent: access parent fields using dot notationSELECT Id, Name, Account.Name, Account.Industry
FROM Contact
WHERE Account.Industry = 'Healthcare'-- Parent-to-Child: use subquery in SELECTSELECT Name, (SELECT LastName, Email FROM Contacts)
FROM Account
WHERE Type = 'Customer'
Pattern 3: Aggregate queries
SELECT StageName, COUNT(Id) TotalOpps, SUM(Amount) TotalValue
FROM Opportunity
WHERE CloseDate = THIS_YEARGROUP BY StageName
HAVING SUM(Amount) > 500000
Governor limits students must memorize: Max 100 SOQL queries per transaction · Max 50,000 records returned per query · Max 150 DML statements per transaction · Max 10,000 DML rows per transaction. Violating these throws a LimitException at runtime — not a compile error!
Apex — key concepts for developers
Apex is Salesforce's proprietary programming language. It's syntactically similar to Java, runs server-side on Salesforce infrastructure, and is strongly typed. All Apex runs in a multi-tenant environment with governor limits to prevent one customer hogging resources.
// Bulkified Apex class — correct patternpublic class OpportunityService {
public static void enrichOpportunities(List<Opportunity> opps) {
// Collect IDs first — then ONE query outside the loop
Set<Id> accountIds = new Set<Id>();
for (Opportunity o : opps) {
accountIds.add(o.AccountId);
}
Map<Id, Account> acctMap = new Map<Id, Account>(
[SELECT Id, Industry FROM Account WHERE Id IN :accountIds]
);
for (Opportunity o : opps) {
if (acctMap.get(o.AccountId).Industry == 'Technology') {
o.StageName = 'Proposal';
}
}
}
}
Apex Triggers — the right pattern
A trigger fires before or after a DML event (insert, update, delete, undelete). The cardinal rule: One trigger per object, all logic in a handler class. Never put business logic directly in the trigger file.
// The trigger file — THIN, just routingtrigger AccountTrigger on Account (before insert, before update, after insert) {
AccountTriggerHandler handler = new AccountTriggerHandler();
if (Trigger.isBefore && Trigger.isInsert) handler.onBeforeInsert(Trigger.new);
if (Trigger.isBefore && Trigger.isUpdate) handler.onBeforeUpdate(Trigger.new, Trigger.oldMap);
if (Trigger.isAfter && Trigger.isInsert) handler.onAfterInsert(Trigger.new);
}
Trigger context variables students must know: Trigger.new (list of new records) · Trigger.old (list of old records) · Trigger.newMap (map of new) · Trigger.oldMap (map of old) · Trigger.isBefore / isAfter · Trigger.isInsert / isUpdate / isDelete
Module 8 — Salesforce Clouds
Six industry-specific platforms built on the core Salesforce platform
Teaching the clouds — the core message
All SF clouds share the same underlying platform (data model, Apex, SOQL, automation tools, security model). The difference is the pre-built data model, processes, and UI that each cloud adds on top. A developer who knows core SF can work across all clouds — they just need to learn the domain-specific objects and concepts.
Sales Cloud
Purpose: Manage the entire sales process from Lead to closed deal.
Key objects: Lead, Opportunity, Opportunity Line Item, Quote, Contract, Order
Dev focus: Opportunity triggers for stage validation, territory management, CPQ (Configure-Price-Quote) integration, Einstein Activity Capture
Service Cloud
Purpose: Handle customer support cases across every channel.
Dev focus: EDA data model architecture, student 360 LWC, admissions workflow Flows, academic program Apex
Teaching tip: Have each student pick one cloud that matches their industry background. Give them 20 minutes to find the 3 most important objects in that cloud's data model using Trailhead. Then present to the class. Students learn all 6 clouds this way in under an hour.
Module 9 — Agentforce & Einstein AI
The future of Salesforce — autonomous AI agents embedded in CRM workflows
What is Agentforce? How to explain it to students
Agentforce is Salesforce's platform for building autonomous AI agents — software that can reason, decide, and take action across Salesforce without a human triggering each step. Traditional automation (Flows, Process Builder) runs when a specific event fires. An Agentforce agent monitors context, evaluates options, and acts proactively.
Analogy for students: "If a Flow is like a light switch — press it and something happens — an Agentforce agent is like a smart building that adjusts lighting, temperature, and security based on who's in the room, time of day, and upcoming calendar events."
The four agent types
Sales Agent
Monitors the pipeline. Identifies cold opportunities, drafts follow-up emails grounded in CRM history, updates opportunity stages based on email replies, alerts reps to at-risk deals. The rep focuses on relationships; the agent handles the admin.
Service Agent
Handles incoming customer cases autonomously for common issue types. Searches the Knowledge Base, applies entitlements, resolves or escalates intelligently to a human agent with full context. Reduces case handle time dramatically.
Data Agent
Continuously analyzes reports and dashboards. Detects anomalies (pipeline drop, sudden case spike), surfaces insights in Slack or Chatter, and triggers corrective workflows. Replaces the need for a dedicated reporting analyst monitoring dashboards.
Dev Agent
Generates Apex code from natural language descriptions, writes test classes, suggests fixes based on debug logs and error messages, reviews code against governor limits and best practices. A force multiplier for developers.
Einstein AI features — what each one does
A conversational AI assistant embedded in every page in Salesforce. Users can ask it questions in plain English: "Summarize this account's open cases," "Draft a follow-up email for Opportunity X," "What deals are at risk this quarter?" It's grounded in org data — it knows your actual CRM records, not just generic knowledge.
Uses machine learning trained on your historical CRM data to score every Lead and Opportunity on likelihood to convert or close. Replaces manual gut-feel prioritization. A lead score of 92 means: based on your past data, leads with these characteristics converted 92% of the time.
A no-code tool for building custom LLM prompts grounded in Salesforce data. Example: Build a prompt template that generates a personalized renewal email for a customer, injecting their account name, contract value, product list, and renewal date from the actual record. No API coding required.
Allows admins and developers to train custom ML prediction models using their own Salesforce data — no data science expertise required. Example: predict customer churn probability, detect fraudulent orders, or forecast support case volume. Uses AutoML under the hood.
Prerequisites students must know: Agentforce requires Data Cloud (for unified profiles), Trust Layer (for data masking and compliance), and Prompt Studio. It cannot be turned on without proper org configuration. In the course, simulate it using Trailhead's dedicated Agentforce playground.
Module 10 — SF Inspector, Data 360 & Developer Essentials
The tools that make SF developers 10x more productive
SF Inspector — the developer's best friend
SF Inspector is a free Chrome extension that adds a power-user panel to every Salesforce page. It gives developers real-time visibility into data, metadata, and API information without switching to the Developer Console. Teach students to install this on Day 1.
INS
Record Inspector — Click any record and see ALL field values including hidden fields, system fields (CreatedById, LastModifiedDate), and formula field outputs. Invaluable for debugging data issues.
QRY
Query Editor — Run SOQL and SOSL queries directly from the browser against the live org. Export results to CSV instantly. Much faster than Dev Console for quick data checks.
API
API Browser — Browse all objects, all fields, field types, and field-level security — much faster than Setup → Object Manager for development reference.
LIM
Org Limits — See how many API calls you've made, storage consumed, and governor limits currently in use. Critical for performance tuning and debugging limit errors.
PRF
Profile Switcher — View any page as if you were logged in as a different Profile or Permission Set. Test field visibility and access without needing multiple test user accounts.
DBG
Debug Mode — Inspect LWC component state and properties directly on the page without the full Developer Console overhead.
Salesforce Data 360 — teaching the concept
Data 360 is Salesforce's answer to the question: "How do we unify data from 50 different sources into one real-time customer profile?" It is built on Data Cloud (formerly CDP — Customer Data Platform).
1
Data Streams — The ingestion layer. Connect any data source: Salesforce CRM, Marketing Cloud, web analytics, mobile apps, ERP systems, or any REST API. Data flows in in real time.
2
Identity Resolution — The matching engine. When a customer appears as "Jane Smith" in CRM, "j.smith@email.com" in Marketing Cloud, and device ID "abc123" in mobile analytics — Identity Resolution recognizes they're the same person and creates one unified profile.
3
Segmentation — Build dynamic audience segments using SQL-based queries against unified profiles. Example: "All customers who bought Product X in the last 90 days AND opened an email in the last 7 days AND have a case still open." This segment updates in real time as data changes.
4
Calculated Insights — Write ANSI SQL to create new metrics on unified profiles: Customer Lifetime Value, engagement score, churn probability. These become fields on the unified profile available to all SF clouds.
5
Activation — Push segments to Sales Cloud (as campaign members), Marketing Cloud (as sendable data extensions), Google Ads (as custom audiences), or any activation target. The segment stays in sync automatically.
Developer tools every student must have set up by Day 3
VS Code + Salesforce Extension Pack
The standard IDE for SF development. Provides Apex syntax highlighting, code completion, org comparison, deploy/retrieve, and SOQL builder. Free. Replaces the old Force.com IDE.
Salesforce CLI (SFDX)
Command-line tool for every SF development operation. Auth to orgs, deploy/retrieve metadata, run Apex, create scratch orgs, run unit tests, interact with the Metadata API. The foundation of CI/CD pipelines.
Developer Console (built-in)
Salesforce's built-in IDE. Use for running Anonymous Apex, viewing Debug Logs, monitoring Apex execution paths, and quick code tests without setting up VS Code.
Workbench
Web-based REST API and Metadata API explorer. Use for bulk data operations, metadata retrieval for debugging, and testing REST API endpoints without writing code. Available at workbench.developerforce.com.
Module 11 — 5-Day Agenda & Certification Paths
How to run the course and guide students toward the right certifications
Day-by-day teaching guide
Morning: SF org setup, navigation, the Lightning UI, user management, profiles vs. permission sets. Afternoon: Scaled Agile overview — Portfolio, ART, Team levels. Explain PI Planning with a simulation. Design Thinking workshop — students conduct 15-minute user interviews with each other and build a persona card. Lab: Set up Trailhead playground org. Navigate to Setup → Object Manager → Explore Account and Opportunity objects. Find 5 fields you didn't know existed using SF Inspector.
Morning: Standard objects deep dive. Create a custom object (e.g., "Project") with Master-Detail to Account. Explore relationship types with hands-on examples. Validation rules and formula fields workshop. Afternoon: SOQL — start simple (SELECT, WHERE, ORDER BY, LIMIT), progress to relationship queries, then aggregates. Students run 15 increasingly complex SOQL queries in SF Inspector's query editor. Lab: Build a query that returns all Accounts with more than 3 open Opportunities, grouped by Industry, ordered by total Opportunity amount.
Morning: Apex fundamentals — variables, collections (List, Set, Map), loops, classes, methods. Governor limits explained with live demos (show what happens when you query inside a loop). Afternoon: Triggers — write a before-insert trigger on Account together as a class. Then implement the Handler pattern. Flow Builder — build an auto-assignment Flow for Cases. Lab: Write an Apex trigger that prevents an Opportunity from moving to "Closed Won" unless the Account has a non-null Phone number. Must include a test class with 95% coverage.
Morning: Sales Cloud config (lead assignment rules, opportunity stages, forecasting). Service Cloud (case auto-assignment, entitlements, Knowledge). 30-min overview each of Marketing Cloud, Health Cloud, Nonprofit, Education Cloud. Afternoon: Einstein AI — set up Einstein Lead Scoring in a demo org. Prompt Builder — build a custom prompt that generates an account summary. Agentforce — walkthrough of the agent builder in Trailhead. Lab: Students pick one cloud and write 3 user stories for a business scenario in that cloud. Apply WSJF scoring and present prioritized backlog to the class.
Morning: SFDX + VS Code setup. Deploy metadata between sandboxes. SF Inspector advanced features. Data 360 / Data Cloud — set up a data stream and build a segment in a trial org. Debug logs and performance analysis. Afternoon: Capstone exercise — 2-hour PI Planning simulation. Teams receive a business scenario ("Company X is implementing Service Cloud + Health Cloud"). They must: write 5 Epics → decompose to Features → write User Stories → WSJF prioritize → produce a 2-PI roadmap. Closing: Certification roadmap review. Assign Trailhead badges for each cert path. Q&A.
Certification roadmap — which cert for which student?
Guide students to their right certification based on their role and experience level.
ADM
Administrator (ADM-201) — Best first cert for BAs, admins, and anyone new to SF. Covers object model, security, automation, reports. No coding required. Expected study time: 40–60 hours.
PD1
Platform Developer I — Best first cert for developers. Covers Apex, SOQL, triggers, LWC basics, deployment. Requires solid understanding of Apex OOP. Expected study time: 60–80 hours post-ADM-201.
PD2
Platform Developer II — Advanced developer cert. Complex Apex, design patterns, API integration, advanced testing. Practical exam component (real Apex coding challenge). Expected study time: 100+ hours. Target 6 months after PD1.
SCC
Sales / Service Cloud Consultant — For BAs and solution architects who configure and deploy SF clouds. Tests real-world implementation knowledge. Requires ADM-201 first. Expect 60–80 hours study.
DC
Data Cloud Consultant — Emerging and in-demand cert for data architects and integration specialists. Covers Data Streams, Identity Resolution, Segmentation, Calculated Insights, and Activation. Very new — limited study material.
Final instructor advice: The best SF professionals combine technical depth (Apex, SOQL, architecture) with business understanding (user stories, journey maps, stakeholder communication). Push students to practice both. Salesforce Trailhead is free — assign specific trails as homework every evening of the course.