TechNova Solutions | Salesforce Developer Guide | Internal Use Only

SALESFORCE
Sales Cloud & Service Cloud
Developer Learning & Implementation Guide

From Foundations to Expert — 10 Progressive Phases

Apex • Flows • LWC • Integrations • Agentforce • DevOps

Internal Onboarding Document | Version 1.0 | 2025

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Table of Contents
TOC \h \o "1-3"

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Introduction & How to Use This Document

Welcome to the Salesforce Sales Cloud & Service Cloud Developer Onboarding Guide. This
document is your complete roadmap from day one as a junior Salesforce developer through to
expert-level implementation skills. Each phase builds on the previous one, progressively
introducing new complexity and real-world scenarios.

📌 Who Is This For?

Junior to mid-level Salesforce developers joining a team implementing Sales Cloud and Service
Cloud from scratch. It is also suitable for Salesforce Admins looking to grow into development
roles.

Document Structure
This guide is organized into 10 phases ordered from Low to Expert difficulty. Each phase follows
the same structure:
• Phase Name & Difficulty Level
• Learning Objectives
• Business Scenario / Use Case
• Step-by-Step Implementation Tasks
• Acceptance Criteria / Definition of Done
• Common Mistakes to Avoid
• Best Practices

Difficulty Scale
Level Description
🟢 Low No prior Salesforce experience required.
Declarative setup.
🟡 Low–Medium Basic Salesforce admin knowledge.
Configuration-focused.
🟠 Medium Some automation experience. Logic and
formulas involved.
🔴 Medium–High Programming fundamentals required. Apex
introduced.
🔴 High Solid Apex foundation. Complex patterns and
async processing.
🟣 High–Expert Advanced integration and UI development
skills.

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

⚫ Expert Deep platform expertise. AI, DevOps, and

architecture skills.

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 1: Foundations 🎯 Low

Overview
This phase introduces the Salesforce platform, the core data model for Sales Cloud and Service
Cloud, and the basic building blocks every developer must understand before writing a single
line of code or automation.

💼 Business Scenario
Your company — TechNova Solutions — is implementing Salesforce for the first time. Your team
sells B2B software (Sales Cloud) and manages customer support tickets (Service Cloud). You
are tasked with setting up the foundational org structure.

🎯 Learning Objectives
• Understand the Salesforce platform architecture and multi-tenant model
• Navigate Setup and understand the difference between declarative and programmatic
tools
• Configure standard Sales Cloud objects: Lead, Contact, Account, Opportunity
• Configure standard Service Cloud objects: Case, Knowledge, Entitlement
• Create and customize Page Layouts, Compact Layouts, and Record Types
• Build List Views and configure App Manager

Step-by-Step Implementation Tasks

1.1 – Org Setup

1. Sign up for a Salesforce Developer Edition org at [Link]
2. Enable Sales Cloud and Service Cloud features in Setup > App Manager
3. Configure Company Information: name, address, currency, time zone, fiscal year
4. Set up the Salesforce mobile app and test basic navigation

1.2 – Sales Cloud Object Configuration

5. Review Lead standard fields; add 3 custom fields: Lead Source Detail (Text), Annual
Budget (Currency), Decision Timeline (Picklist: 0-3 months, 3-6 months, 6-12 months)
6. Create a Lead Record Type for 'Inbound Web Lead' and 'Outbound Prospected Lead'
7. Customize the Lead Page Layout to group related fields into sections
8. Enable Lead Conversion and map custom Lead fields to Contact/Account/Opportunity
fields
9. On Opportunity: Add a custom Stage History related list and configure the Sales Path

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

10. Configure Compact Layouts on Account and Contact to show Name, Phone, Email, and
Owner

1.3 – Service Cloud Object Configuration

11. Add custom fields to Case: Product Affected (Lookup to Product), SLA Tier (Picklist:
Bronze/Silver/Gold/Platinum), Root Cause (Long Text)
12. Create Case Record Types: Technical Support, Billing Inquiry, Feature Request
13. Set up a Case Page Layout per Record Type
14. Enable Knowledge and create two Article Types: FAQ and How-To Guide
15. Configure the Service Console app with the Case as primary object

1.4 – App Customization

16. Build a custom Lightning App called 'TechNova Sales App' with relevant tabs
17. Create relevant List Views for Leads (My Open Leads, This Week's New Leads)
18. Create Kanban view for Opportunities by Stage

✅ Acceptance Criteria / Definition of Done

• All standard objects are configured with business-relevant custom fields
• Record Types exist and are assigned to appropriate profiles
• Page layouts are clean, logical, and free of unused standard fields
• Compact Layouts show the 4 most important fields per object
• Sales and Service Console apps are functional and navigable

⚠️Common Mistakes to Avoid

• Adding too many custom fields without a clear business need
• Not planning page layout sections — leads to cluttered, unusable UIs
• Forgetting to assign Record Types to Profiles (users won't see them)
• Using Master record type instead of creating properly named record types

💡 Best Practices
• Follow the Salesforce naming convention: use spaces in labels, underscores in API
names
• Keep page layouts role-specific — different roles see different layouts
• Use compact layouts to drive mobile usability
• Document every custom field added and its business justification
• Use a sandbox (even Developer Edition) rather than making changes to production

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 2: Administration & Security 🎯 Low–Medium

Overview
Security is the backbone of every Salesforce implementation. This phase covers the entire
security model — from org-wide settings down to individual field access. Getting this right is
critical before any automation or development work begins.

💼 Business Scenario
TechNova has 4 departments: Sales Reps, Sales Managers, Support Agents, and Support
Managers. Each group has different data visibility and access requirements. Reps should only
see their own Leads but Managers should see all. Support Agents can view but not delete
Cases. You must implement a robust security model.

🎯 Learning Objectives
• Understand and configure the Salesforce security model layers
• Create Profiles and Permission Sets for each business role
• Implement Roles and Role Hierarchy for record visibility
• Configure OWD, Sharing Rules, and understand when to use each
• Apply Field-Level Security (FLS) and Object-Level Security correctly
• Audit user activity with Login History and Setup Audit Trail

📊 Salesforce Security Model — Layer by Layer

Security Layer What It Controls
Organization Security Login hours, IP restrictions, password policies,
MFA
Object-Level Security (Profiles/PermSets) CRUD access to entire objects
Field-Level Security (FLS) Read/Edit access to individual fields on an
object
Record-Level Security (OWD + Sharing) Which records a user can see/edit
Role Hierarchy Roll-up visibility — managers see subordinates'
records
Sharing Rules Extend access beyond OWD to specific groups

Step-by-Step Implementation Tasks

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

2.1 – Profiles
19. Clone the 'Standard User' profile to create: Sales Rep, Sales Manager, Support Agent,
Support Manager
20. For Sales Rep profile: grant Read/Create/Edit on Lead, Contact, Account, Opportunity.
No Delete. No Modify All.
21. For Support Agent: Read/Create/Edit on Case. No Delete.
22. Disable access to objects not relevant to each role (e.g., Sales Reps don't need
Entitlement management)

2.2 – Permission Sets & Permission Set Groups

23. Create a Permission Set 'KPI Dashboard Access' that grants Read access to custom
report types and dashboards
24. Create a Permission Set 'Apex Execution Access' for developers to run anonymous
Apex
25. Create a Permission Set Group 'Senior Sales Rep' combining Sales Rep profile
permissions + KPI Dashboard Access
26. Assign Permission Set Groups to relevant users

2.3 – Roles & Role Hierarchy

27. Create the following role hierarchy: CEO > VP Sales > Sales Manager > Sales Rep;
CEO > VP Support > Support Manager > Support Agent
28. Assign all users to appropriate roles
29. Verify that Sales Managers can see Sales Rep records via hierarchy

2.4 – OWD and Sharing Rules

30. Set Lead OWD to Private (reps only see their own leads)
31. Set Account/Contact OWD to Public Read Only
32. Set Opportunity OWD to Private
33. Set Case OWD to Public Read Only
34. Create a Criteria-Based Sharing Rule: share Opportunities with Stage =
'Negotiation/Review' with the Sales Manager role
35. Create a Manual Sharing button on Case for escalation scenarios

2.5 – Field-Level Security

36. On the Lead object: set 'Annual Budget' field to visible for Sales Manager and above,
hidden for Sales Reps
37. On the Contact object: set 'Home Phone' and 'Other Phone' to visible only for Support
profiles
38. Verify FLS is enforced in both Classic and Lightning Experience

2.6 – Login & Session Security

39. Set Password Policy: minimum 10 characters, must contain number and special
character, expires in 90 days
40. Restrict Login Hours for Sales Reps to 7AM–8PM Monday–Friday

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

41. Enable Login IP Ranges for the office network

42. Review Setup Audit Trail to confirm all changes are logged

✅ Acceptance Criteria / Definition of Done

• Sales Reps cannot see other reps' Leads, Contacts, or Opportunities
• Sales Managers can see all records owned by their subordinates
• Field-level security is enforced and tested in the UI
• Support Agents cannot delete Cases
• Login restrictions are active and tested

⚠️Common Mistakes to Avoid

• Over-permissioning profiles — give least privilege and expand with Permission Sets
• Confusing Profile OWD settings with Sharing Rules — OWD is the ceiling, Sharing
Rules only open access up
• Setting OWD to Public Read/Write and then trying to restrict with sharing — it doesn't
work that way
• Forgetting that FLS is separate from Page Layout field visibility
• Not testing as a specific user using the 'Log in as User' feature

💡 Best Practices
• Use the Principle of Least Privilege: grant minimum access needed, use Permission
Sets to expand
• Never modify the System Administrator profile
• Document your OWD decisions before implementing — changes are difficult to reverse
in production
• Use Permission Set Groups in Salesforce orgs with 20+ permission sets
• Regularly audit Profiles and Permission Sets as part of org governance

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 3: Declarative Automation 🎯 Medium

Overview
Automation is where Salesforce becomes truly powerful. This phase covers the full suite of
declarative tools — Validation Rules, Flows of all types, and Approval Processes. By the end,
you should be able to automate most common business processes without writing a single line
of code.

💼 Business Scenario
TechNova needs: (1) Validation ensuring Opportunities over $50,000 require a Discount
Justification. (2) An automated onboarding email flow when a Lead is converted. (3) A weekly
report of open Cases sent to managers. (4) An Approval Process for Discounts over 20%
requiring VP sign-off.

🎯 Learning Objectives
• Write formula-based Validation Rules for data quality enforcement
• Build Record-Triggered Flows (Before Save and After Save)
• Build Screen Flows for guided user interactions
• Configure Scheduled Flows for time-based automation
• Create and manage Approval Processes with multi-step approvals
• Understand Flow bulkification and when it matters

Step-by-Step Implementation Tasks

3.1 – Validation Rules

Validation Rule 1: Discount Justification Required
• Object: Opportunity
• Formula: AND(Amount > 50000, ISBLANK(Discount_Justification__c))
• Error Message: 'A Discount Justification is required for opportunities over $50,000.'
• Error Location: Field (Discount_Justification__c)

Validation Rule 2: Close Date Cannot Be in the Past

• Formula: AND(ISPICKVAL(StageName, 'Prospecting'), CloseDate < TODAY())
• Error Message: 'Close Date cannot be in the past for active Opportunities.'

Validation Rule 3: Require Phone on Contact if Email is Blank

• Formula: AND(ISBLANK(Email), ISBLANK(Phone))

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

• Error Message: 'A Contact must have at least an Email or Phone number.'

3.2 – Record-Triggered Flows

Flow 1: Lead Assignment Notification (After Save, When Created)
43. Trigger: Lead — After Save — When Record Is Created
44. Condition: LeadSource = 'Web'
45. Action: Send Email Alert to Lead Owner notifying them of new web lead
46. Add a Fault Path that logs the error to a custom object

Flow 2: Opportunity Stage Timestamp (Before Save)

47. Trigger: Opportunity — Before Save — When Record Is Updated
48. Condition: StageName Is Changed
49. Action: Set a custom field Stage_Changed_Date__c to TODAY()
50. This is a Before Save flow so no separate DML is needed — direct field update

Flow 3: Case Auto-Escalation (After Save, Scheduled Path)

51. Trigger: Case — After Save — When Created or Updated
52. Add a Scheduled Path: 2 Days After Creation if Status = 'New'
53. Action: Update Case Status to 'Escalated', send email to Support Manager

3.3 – Screen Flows

54. Create a Screen Flow called 'New Customer Onboarding'
55. Screen 1: Collect Account Name, Industry, Annual Revenue
56. Screen 2: Collect Contact Name, Email, Phone, Title
57. Screen 3: Collect initial Opportunity name, amount, expected close date
58. Logic: Use Decision elements to branch based on Annual Revenue (Enterprise vs SMB)
59. After submission: Create Account, Contact, and Opportunity using Create Records
elements
60. Add the Screen Flow to the Account page as a Quick Action

3.4 – Scheduled Flows

61. Create a Scheduled Flow to run every Monday at 8AM
62. Query Cases where Status = 'Open' and CreatedDate older than 7 days
63. For each Case, send an email summary to the Case Owner and their Manager
64. Add bulkification: use a Loop with an Assignment to build a collection, then a single
Send Email action

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

3.5 – Approval Processes

65. Create an Approval Process on Opportunity for Discount approvals
66. Entry Criteria: Discount__c > 20
67. Initial Submission Action: Lock the record, send email to submitter
68. Approval Step 1: Assigned to Sales Manager (Auto-assign based on Owner's Manager
field)
69. Approval Step 2 (if Discount > 35%): Escalate to VP Sales (specific user)
70. Approved Actions: Set Approval_Status__c = 'Approved', unlock record
71. Rejected Actions: Set Approval_Status__c = 'Rejected', send rejection email with
comments
72. Add Approval History related list to Opportunity page layout

✅ Acceptance Criteria / Definition of Done

• All validation rules fire correctly and display meaningful error messages
• Lead notification flow triggers only for Web source leads
• Opportunity stage change updates the timestamp field without DML errors
• Case escalation fires after 2 days for unresolved new cases
• Screen flow successfully creates Account, Contact, and Opportunity in one session
• Approval process routes discounts correctly to the right approvers

⚠️Common Mistakes to Avoid

• Using After Save flows when Before Save is more efficient (avoid extra DML)
• Building flows without Fault Paths — errors will be swallowed silently
• Not testing flows in bulk (use Data Loader to insert 200+ records to test governor limits)
• Using flow to do what a validation rule can do — prefer the simpler tool
• Creating recursive flows (After Save flows that modify the same record causing an
infinite loop)

💡 Best Practices
• Name flows clearly: [Object]_[Trigger]_[Purpose] e.g.
Opportunity_AfterSave_StageTimestamp
• Always add Fault Paths to After Save flows — log errors to a custom Error Log object
• Use Before Save flows for field updates (no extra DML transaction)
• Test flows as specific users to validate FLS and sharing enforcement
• Avoid performing DML inside loops — collect records and process in bulk
• Version control flows by documenting the change description in the flow properties

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 4: Apex Development – Synchronous 🎯 Medium–High

Overview
This phase is where you transition from a Salesforce Admin to a Salesforce Developer. Apex is
Salesforce's proprietary Java-like programming language. You will learn to write triggers,
classes, SOQL queries, and test classes following industry best practices.

💼 Business Scenario
TechNova needs custom logic that cannot be achieved declaratively: (1) When a Lead is
converted, automatically create a follow-up Task. (2) When an Opportunity is marked Closed
Won, update a counter field on the Account. (3) Prevent duplicate Contacts from being created
based on email address.

🎯 Learning Objectives
• Understand Apex syntax, data types, collections (List, Set, Map)
• Write Apex Triggers with proper before/after logic
• Implement the Trigger Handler pattern for maintainable code
• Write SOQL and SOSL queries with proper governor limit awareness
• Handle exceptions with try-catch and custom exception classes
• Write test classes with 85%+ coverage and meaningful assertions

Step-by-Step Implementation Tasks

4.1 – Your First Trigger and Handler

Step 1: Create the Trigger Handler base class

📝 Code Pattern: TriggerHandler Base Class

public virtual class TriggerHandler { public virtual void beforeInsert() {} public virtual void
afterInsert() {} public virtual void beforeUpdate() {} public virtual void afterUpdate() {} public
virtual void beforeDelete() {} public virtual void afterDelete() {} public virtual void
afterUndelete() {} }

Step 2: Create the OpportunityTrigger (thin trigger — no logic)

📝 Code Pattern: Thin Trigger

trigger OpportunityTrigger on Opportunity (before insert, before update, after insert, after update)
{ OpportunityTriggerHandler handler = new OpportunityTriggerHandler(); if ([Link]
&& [Link]) [Link](); if ([Link] && [Link])
[Link](); if ([Link] && [Link]) [Link](); if

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

([Link] && [Link]) [Link](); }

Step 3: Create OpportunityTriggerHandler extending TriggerHandler

73. Implement afterUpdate() to detect when StageName changes to 'Closed Won'
74. Collect Account IDs from changed Opportunities into a Set<Id>
75. Query those Accounts and their existing Closed Won count
76. Update a custom field Total_Closed_Won__c on Account with the count
77. Perform a single bulkified DML update on the Account list

4.2 – SOQL and Governor Limits

Governor Limit Awareness: Salesforce enforces per-transaction limits to protect the multi-tenant
architecture.
Governor Limit Limit Value
SOQL Queries per transaction 100
SOQL rows returned 50,000
DML statements per transaction 150
DML rows 10,000
Heap size (synchronous) 6 MB
CPU time (synchronous) 10,000 ms
Future method calls per transaction 50

Exercise: Rewrite the following SOQL-in-loop (bad code) to use a Map pattern (good code):

❌ BAD — SOQL in a Loop

for (Opportunity opp : [Link]) { Account acc = [SELECT Id, Name FROM Account WHERE
Id = :[Link]]; // N+1 queries! }

✅ GOOD — Bulkified Map Pattern

Map<Id, Account> accountMap = new Map<Id, Account>( [SELECT Id, Name FROM Account
WHERE Id IN :accountIds] ); for (Opportunity opp : [Link]) { Account acc =
[Link]([Link]); }

4.3 – Custom Exception Classes

78. Create a custom exception class: public class TechNovaException extends Exception {}

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

79. Throw it in your handler when a required field is blank: throw new
TechNovaException('Account Name is required')
80. Catch it in a higher layer and add to [Link][0].addError()

4.4 – Duplicate Contact Prevention

81. In ContactTriggerHandler, implement beforeInsert()
82. Collect all emails from [Link] into a Set<String>
83. Query existing Contacts with matching emails
84. For any new Contact whose email already exists, call addError('A contact with this email
already exists.')

4.5 – Test Classes

85. Create ContactTriggerTest class
86. Use @TestSetup to create shared test data (Account, 2 Contacts)
87. Test the happy path: insert Contact with unique email — expect success
88. Test the failure path: insert Contact with duplicate email — expect addError message
89. Use [Link], [Link], [Link] for every assertion
90. Run with [Link]() / [Link]() to reset governor limits
91. Run all tests and verify 85%+ coverage

✅ Acceptance Criteria / Definition of Done

• All triggers follow the Trigger Handler pattern — zero logic in .trigger files
• No SOQL or DML inside loops anywhere in codebase
• Test coverage is at least 85% across all Apex classes
• All test methods have meaningful assertions (not just [Link](true))
• Custom exceptions used for business logic errors

⚠️Common Mistakes to Avoid

• Writing logic directly in .trigger files — always use handler classes
• SOQL inside for loops — always query before the loop and use Maps
• Using [Link]() to skip logic in code — fix the code instead
• Writing test classes that only assert coverage (no real assertions)
• Hardcoding IDs — use queries in test setup to get IDs dynamically

💡 Best Practices
• One trigger per object — put all logic in handler classes
• Use [Link] and [Link] for efficient change detection
• Always bulkify — write code that handles 200 records as easily as 1

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

• Use Custom Metadata for configurable thresholds instead of hardcoded values

• Keep test data creation in @TestSetup for shared test fixtures

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 5: Apex Development – Asynchronous 🎯 High

Overview
Synchronous Apex runs within tight governor limits in a single transaction. Asynchronous Apex
lets you defer and distribute work across multiple transactions with higher limits, enabling you to
process large datasets, perform long-running callouts, and schedule jobs.

💼 Business Scenario
TechNova needs: (1) Send a marketing email after Lead conversion without delaying the save
(Future Method). (2) Process 100,000 old Case records for archiving (Batch Apex). (3) Sync
Contact data to an external CRM every night at midnight (Schedulable + Batch). (4) Process
incoming webhook payloads asynchronously (Queueable). (5) React to external system events in
real time (Platform Events).

Async Type When to Use

@future Simple callouts or field updates that can't run
synchronously. Fire and forget.
Queueable When you need to chain jobs, pass complex
objects, or need a Job ID.
Batch Apex Processing large datasets (millions of records)
in chunks of up to 2,000.
Schedulable Run any Apex on a time-based schedule (cron
expression).
Platform Events Real-time event-driven messaging between
systems or within Salesforce.
Change Data Capture Listen to record changes from external systems
without polling.

Step-by-Step Implementation Tasks

5.1 – Future Method

92. Create LeadConversionHelper class with a @future(callout=true) method
93. Method signature: public static void sendConversionNotification(Set<Id> leadIds)
94. Inside: query Leads, construct HTTP request to marketing webhook, send callout
95. Call this method from [Link]() when LeadSource = 'Web'
96. Important: pass primitive types (Set<Id>) not sObject to @future methods

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

5.2 – Queueable Apex

97. Create ContactSyncQueueable implementing Queueable and [Link]
98. Constructor accepts List<Contact> to process
99. In execute(): process the contacts, then chain: [Link](new
ContactSyncQueueable(nextBatch))
100. Handle chaining depth limit: max 5 levels of chaining in production (unlimited in
async context in some editions)
101. Add JobId logging to a custom Async_Job_Log__c object for monitoring

5.3 – Batch Apex

102. Create CaseArchiveBatch implementing [Link]<SObject>,
[Link]
103. start(): return [Link]('SELECT Id, Status FROM Case
WHERE CreatedDate < LAST_N_YEARS:2 AND Status = \'Closed\'')
104. execute(): for each batch, set IsArchived__c = true, update records
105. finish(): send a summary email to Admin with total records processed (use
Stateful to track count)
106. Schedule it: [Link](new CaseArchiveBatch(), 200)
107. Test with [Link](), execute the batch, [Link](), assert

5.4 – Schedulable Apex

108. Create NightlySyncScheduler implementing Schedulable
109. In execute(): instantiate and run ContactSyncBatch
110. Schedule it via Setup > Apex Jobs or: [Link]('Nightly Sync', '0 0 0 *
* ?', new NightlySyncScheduler())
111. Cron reference: Seconds Minutes Hours Day-of-Month Month Day-of-Week

5.5 – Platform Events

112. Create a Platform Event: Integration_Error__e with fields: Error_Message__c,
Source_System__c, Record_Id__c
113. Publish from Apex: [Link](new
Integration_Error__e(Error_Message__c = 'Sync failed', Source_System__c =
'HubSpot'))
114. Create a Flow that subscribes to Integration_Error__e and creates a Case for
each error
115. Alternatively: create a CometD subscriber using a Trigger on the Platform Event

5.6 – Change Data Capture

116. Enable Change Data Capture for the Contact object in Setup

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

117. Create an Apex Trigger on ContactChangeEvent

118. In the trigger, detect changed fields using:
[Link]().replayId
119. When Email changes, call a Queueable to sync the update to HubSpot

✅ Acceptance Criteria / Definition of Done

• @future method sends callout without blocking the triggering transaction
• Queueable chains process contact batches sequentially with proper logging
• Batch Apex processes 100k+ records without hitting governor limits
• Scheduler fires at midnight and kicks off nightly sync
• Platform Events published from failed integrations and consumed by a monitoring flow
• CDC trigger detects Contact email changes and syncs downstream

⚠️Common Mistakes to Avoid

• Calling @future from a @future — not allowed (use Queueable instead)
• Passing sObject types to @future methods — only primitives allowed
• Not implementing [Link] when you need to track state across batch chunks
• Setting batch size too large (>200) when doing callouts inside execute()
• Forgetting [Link]()/stopTest() around async code in tests — async won't execute
without it

💡 Best Practices
• Use Queueable over @future for anything more complex than a simple callout
• Always log async job IDs and results to a custom monitoring object
• For batch jobs with callouts, set scope (batch size) to 1 — callout limit is per execute()
transaction
• Use Platform Events for decoupled, resilient event-driven architecture
• Always add retry logic with exponential backoff for external callouts

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 6: Interfaces & Design Patterns 🎯 High

Overview
This phase elevates your Apex code from functional to architectural. You will learn to use Apex
interfaces to create extensible, maintainable systems that can grow without requiring rewrites.
This is the foundation of professional-grade Salesforce development.

💼 Business Scenario
TechNova is growing and the codebase is getting complex. The team needs a scalable
architecture where different teams can add new integrations and business logic without breaking
existing code. You are tasked with refactoring the existing trigger handlers into a clean, layered
architecture.

🎯 Learning Objectives
• Use built-in Apex interfaces: Callable, Comparable, [Link], Schedulable,
Queueable
• Create custom interfaces for extensible patterns
• Understand abstract classes vs interfaces
• Implement Service Layer, Selector Layer, and Domain Layer patterns
• Apply Dependency Injection for testable code

Step-by-Step Implementation Tasks

6.1 – Custom Interfaces

120. Create an interface IIntegrationService with method: void
syncRecords(List<SObject> records)
121. Create HubSpotIntegrationService and KlaviyoIntegrationService both
implementing IIntegrationService
122. Create an IntegrationFactory class that returns the right implementation based on
a Custom Metadata config
123. In the trigger handler, call
[Link]('HubSpot').syncRecords(contacts) — no direct
dependency on HubSpot class

6.2 – Callable Interface

124. Implement the Callable interface on your IntegrationFactory: public Object
call(String action, Map<String, Object> args)

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

125. This allows your class to be invoked dynamically from Flow using Invoke Apex
action
126. Example: action = 'syncContacts', args = {'contacts': List<Contact>}

6.3 – Service Layer Pattern

127. Create ContactService class with static methods: validateContacts(),
enrichContacts(), syncContactsToExternal()
128. Trigger Handler calls ContactService — no business logic in the handler
129. ContactService is pure Apex business logic, no knowledge of Trigger context
130. This makes ContactService testable independently of triggers

6.4 – Selector Layer Pattern

131. Create ContactSelector class with methods: getByEmail(Set<String> emails),
getByAccountId(Set<Id> accountIds)
132. All SOQL queries live in Selector classes — no inline SOQL in handlers or
service classes
133. Apply WITH SECURITY_ENFORCED to all SOQL in selectors for FLS
enforcement

6.5 – Domain Layer Pattern

134. Create ContactDomain class that wraps List<Contact> and contains domain-
specific logic
135. Methods: filterByLeadSource(), getNewEmails(), validateNoBlankPhones()
136. This encapsulates 'what these records mean to the business' separate from 'what
to do with them'

6.6 – Abstract Classes

137. Create abstract class BaseIntegrationService with common methods: logError(),
buildHeader(), retry()
138. HubSpotIntegrationService extends BaseIntegrationService and implements
IIntegrationService
139. This gives you code reuse (abstract class) and contract enforcement (interface)

✅ Acceptance Criteria / Definition of Done

• IntegrationFactory pattern works — adding a new integration requires only a new class +
metadata
• No SOQL queries exist outside of Selector classes
• No business logic exists in Trigger Handler classes
• Service layer methods are independently testable without Trigger context

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

• Callable interface allows Flow to invoke Apex dynamically

💡 Best Practices
• Separate concerns: Trigger Handler → Service → Selector → Domain
• Program to interfaces, not implementations
• Use Custom Metadata to configure which integration classes to use at runtime
• Keep Selector classes responsible for SOQL only — no DML
• Use virtual and abstract methods thoughtfully — prefer composition over deep
inheritance

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 7: Integrations – Klaviyo & HubSpot 🎯 High–Expert

Overview
TechNova integrates with Klaviyo (email marketing) and HubSpot (CRM). You will build both
batch and real-time sync processes, implement error handling, retries, and test all callouts using
mock frameworks. This phase covers the full integration lifecycle.

💼 Business Scenario
When a Salesforce Contact is created or updated, their data must be synced to both Klaviyo (for
marketing campaigns) and HubSpot (for the sales team's legacy workflows). HubSpot is also
updated manually by sales reps, so changes from HubSpot must sync back to Salesforce —
creating a bidirectional integration with conflict resolution.

🎯 Learning Objectives
• Configure Named Credentials and External Credentials for secure API authentication
• Build HTTP callouts with proper error handling and retry logic
• Serialize and deserialize complex JSON payloads
• Build batch sync for bulk data migrations
• Build real-time sync via CDC or Platform Events
• Mock HTTP callouts in test classes using HttpCalloutMock

7.1 – Named Credentials Setup

140. In Setup > Named Credentials, create 'Klaviyo_API' with endpoint:
[Link]
141. Under Authentication Protocol: No Authentication (use custom header for API
key)
142. Create 'HubSpot_API' with endpoint: [Link]
143. Store API keys in Custom Metadata: Integration_Config__mdt with fields
API_Key__c, Endpoint__c, Is_Active__c
144. NEVER hardcode API keys in Apex code

7.2 – Klaviyo Integration — Real-Time Sync

145. Create KlaviyoService class implementing IIntegrationService
146. Method: syncContact(Contact c) — builds JSON payload, sends POST to
/api/profiles/
Klaviyo payload structure:

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

📝 Klaviyo Profile Payload

{ "data": { "type": "profile", "attributes": { "email": "jane@[Link]",
"first_name": "Jane", "last_name": "Doe", "properties": { "salesforce_id": "003xxxx",
"account_name": "Acme Corp" } } }}

147. Handle 200 (created), 409 (duplicate — do a PATCH instead), 400 (validation
error — log and don't retry)
148. Trigger: ContactChangeEvent CDC trigger calls KlaviyoService when Email,
FirstName, or LastName changes

7.3 – Klaviyo Batch Sync

149. Create KlaviyoBatchSync implementing [Link],
[Link]
150. start(): query all active Contacts modified in last 24 hours
151. execute(): for each batch of 1 contact (due to callout limits), call
[Link]()
152. finish(): publish a Platform Event summarizing results
153. Schedule this to run every night at 2AM

7.4 – HubSpot Bidirectional Sync

154. SALESFORCE → HUBSPOT: When Contact is created/updated, call HubSpot
Contacts API: POST /crm/v3/objects/contacts
155. Store the HubSpot Contact ID in a custom field HubSpot_Id__c on Contact
156. HUBSPOT → SALESFORCE: Expose a Salesforce Site (public REST endpoint)
or use a Flow-triggered webhook receiver
157. Create an Apex REST class: @RestResource(urlMapping='/hubspot/contact/*')
public class HubSpotWebhookController
158. Conflict Resolution Strategy: Last-Write-Wins with a timestamp — compare
LastModifiedDate from both systems; skip if Salesforce record is newer
159. Add a sync lock field: Sync_In_Progress__c (Boolean) to prevent infinite sync
loops

7.5 – Error Handling & Retry

160. Create Integration_Error_Log__c object with fields: System__c, Error_Code__c,
Payload__c, Retry_Count__c, Next_Retry__c
161. On any callout failure, create an error log record
162. Create a Scheduled Job that runs every 30 minutes to retry failed records (up to
3 attempts)
163. After 3 failures, escalate by creating a Case and assigning to Integration Support
team

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

7.6 – Mock Callouts in Tests

164. Create KlaviyoMockCallout implementing HttpCalloutMock
165. Return 200 response with sample JSON payload
166. In test class: [Link]([Link], new KlaviyoMockCallout())
167. Test both success and failure scenarios

✅ Acceptance Criteria / Definition of Done

• All API keys stored in Custom Metadata, none hardcoded in Apex
• Contact creation/update triggers real-time sync to both Klaviyo and HubSpot
• Batch job syncs all modified contacts nightly
• HubSpot webhook correctly updates Salesforce contacts
• Conflict resolution prevents loop overwrites between the two systems
• Error logs capture all failures with retry capability
• All callouts are mocked in test classes — no real API calls in tests

💡 Best Practices
• Always use Named Credentials — never hardcode endpoints or credentials
• Build idempotent sync operations — syncing the same record twice should not cause
duplicates
• Log every API call with request/response payloads for debugging
• Use Custom Metadata for integration configuration — enables sandbox vs production
config
• Implement circuit breakers: disable integration after 10 consecutive failures

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 8: Lightning Web Components (LWC) 🎯 High–Expert

Overview
Lightning Web Components (LWC) is the modern Salesforce UI framework based on web
standards. In this phase you will build interactive, reusable components for the TechNova app
that go beyond what standard Salesforce UI can provide.

💼 Business Scenario
TechNova needs: (1) A custom Opportunity Pipeline tracker showing real-time stage progress.
(2) A Contact 360 widget that shows Salesforce data alongside their Klaviyo engagement stats.
(3) A reusable Modal component used across multiple objects. (4) A global search component
using Lightning Message Service.

🎯 Learning Objectives
• Understand LWC component structure: HTML, JS, CSS, meta XML
• Use @api, @track, @wire decorators correctly
• Make imperative Apex calls and handle loading/error states
• Implement parent-child and sibling communication patterns
• Use Lightning Message Service (LMS) for cross-component communication
• Write Jest tests for LWC components

Step-by-Step Implementation Tasks

8.1 – Component Fundamentals

168. Create your first LWC: opportunityStageTracker
169. [Link]: Use <template for:each> to render stages from a
stages property
170. [Link]: import { LightningElement, api, wire } from 'lwc'
171. Wire to getRecord: @wire(getRecord, {recordId: '$recordId', fields:
OPPORTUNITY_FIELDS})
172. [Link]: targets lightning__RecordPage with
isExposed true
173. Deploy and add to Opportunity Record Page via App Builder

8.2 – @api, @track, @wire Decorators

Decorator Purpose

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

@api Makes a property or method public —

accessible from parent components or App
Builder
@track (legacy) Marks a property as reactive. In modern LWC,
all properties are reactive by default.
@wire Connects component to Salesforce data or
Apex methods reactively

174. Create a reusable cardContainer LWC accepting @api title, @api iconName
properties
175. Parent component passes data via attributes: <c-card-container title='My Title'>
176. Child communicates back via custom events: [Link](new
CustomEvent('cardclick', {detail: recordId}))
177. Parent listens: <c-card-container oncardclick={handleCardClick}>

8.3 – Imperative Apex Calls

178. Create Apex method: @AuraEnabled(cacheable=true) public static
List<Contact> getAccountContacts(Id accountId)
179. In LWC JS: import getAccountContacts from
'@salesforce/apex/[Link]'
180. Call imperatively inside connectedCallback or on button click:

📝 Imperative Apex Pattern

getAccountContacts({ accountId: [Link] }) .then(result => { [Link] = result;
[Link] = false; }) .catch(error => { [Link] = error; [Link] = false; });

181. Always handle both .then() and .catch()

182. Use <template if:true={isLoading}> to show spinner while loading

8.4 – Lightning Message Service (LMS)

183. Create a Message Channel: [Link]-
[Link]
184. In publisher component: import { publish, MessageContext } from
'lightning/messageService'
185. Publish: publish([Link], INTEGRATION_STATUS_CHANNEL,
{ status: 'syncing', recordId: [Link] })
186. In subscriber component: import { subscribe, MessageContext } from
'lightning/messageService'
187. Subscribe in connectedCallback, unsubscribe in disconnectedCallback
188. This enables the Contact 360 widget to react when sync status changes from
another component

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

8.5 – Reusable Modal Component

189. Create modalDialog LWC with @api isOpen, @api title properties
190. Use CSS :host to style the overlay
191. Dispatch 'close' event when backdrop or X button is clicked
192. Include a named slot for body content: <slot name='body'></slot>
193. Use this across Lead Conversion, Case Escalation, and Discount Approval
screens

8.6 – LWC Jest Testing

194. Set up: npm install @salesforce/sfdx-lwc-jest
195. Create __tests__ folder in component directory
196. Test 1: Component renders with default properties
197. Test 2: Button click dispatches correct custom event
198. Test 3: Mock wire adapter returns data and component renders list items
199. Run tests: npx lwc-jest --watch

✅ Acceptance Criteria / Definition of Done

• opportunityStageTracker renders correctly on Opportunity records and highlights current
stage
• Contact 360 widget shows both Salesforce fields and Klaviyo data side by side
• Modal component is reusable across at least 3 different pages
• LMS channel correctly broadcasts sync status across components on the same page
• All components have Jest tests with meaningful assertions

💡 Best Practices
• Keep components small and focused — one component, one responsibility
• Use base Lightning components (lightning-input, lightning-datatable) before building
custom ones
• Always handle loading, error, and empty states in every component
• Use @wire for read-only data, imperative calls for user-triggered actions
• Never access the DOM directly — use refs or template queries sparingly
• Use CSS Custom Properties for theming instead of hardcoded colors

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 9: Agentforce Implementation 🎯 Expert

Overview
Agentforce is Salesforce's AI agent platform built natively on the Einstein 1 Platform. It enables
the creation of autonomous AI agents that can perform multi-step tasks using natural language,
grounded in your Salesforce data. This phase covers the full implementation of Agentforce for
Sales and Service Cloud scenarios.

💼 Business Scenario
TechNova wants to deploy: (1) A Sales Agent that helps reps qualify leads and draft follow-up
emails. (2) A Service Agent that handles first-line Case triage, suggests Knowledge Articles, and
escalates to humans when needed. (3) A custom Action that enriches Contact records using an
external data source.

🎯 Learning Objectives
• Understand Agentforce architecture: Agents, Topics, Actions, and Guardrails
• Configure Einstein Copilot for Sales and Service Cloud
• Build custom Agent Actions using Apex and Flow
• Implement grounding to connect agents to your Salesforce data
• Configure Topics to define agent behavior scope
• Apply governance and security controls to AI features

Step-by-Step Implementation Tasks

9.1 – Agentforce Setup

200. Enable Einstein features in Setup > Einstein > Einstein Setup
201. Enable Copilot in Setup > Einstein > Copilot and Planner
202. Assign the Einstein Copilot User permission to test users
203. Enable Data Cloud if available — required for grounding with large datasets

9.2 – Understanding Agentforce Architecture

Component Role
Agent The top-level AI assistant — has a name,
persona, and set of Topics
Topic A domain of knowledge and tasks the agent
handles (e.g. 'Lead Qualification')

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Action A specific capability the agent can perform (e.g.

'Draft Follow-Up Email')
Instruction Natural language instructions that guide how
the agent responds
Guardrails Restrictions on what the agent can and cannot
do
Grounding Connecting the agent to your CRM data for
contextual responses

9.3 – Sales Agent Configuration

204. Go to Setup > Agent Studio > New Agent
205. Name: 'TechNova Sales Assistant', Role: Sales Representative Support
206. Create Topic: 'Lead Qualification' — Instructions: 'Help sales reps evaluate leads
using BANT criteria (Budget, Authority, Need, Timeline). Always check existing Account
data before recommending lead status updates.'
207. Add standard Actions to the topic: Query Records, Update Records, Draft Email
208. Create Topic: 'Opportunity Coaching' — Instructions: guide reps on next best
steps based on Stage and competitor information

9.4 – Custom Apex Action

209. Create an Apex class ContactEnrichmentAction with @InvocableMethod
annotation
210. Method: public static List<EnrichmentResult>
enrichContact(List<EnrichmentRequest> requests)
211. Inside: make callout to external data enrichment API (e.g. Clearbit or ZoomInfo)
212. Return enriched fields: Title, Company Size, LinkedIn URL, Phone
213. In Agent Studio, add this as an Action under the Lead Qualification topic
214. Write a clear description of the action — the agent uses this to decide when to
call it

9.5 – Service Agent Configuration

215. Create a second Agent: 'TechNova Service Agent'
216. Topic: 'Case Triage' — Instructions: 'When a customer reports an issue, search
the Knowledge Base for relevant articles. If the issue matches a known bug, link the
Knowledge Article to the Case and set Status to Waiting on Engineering. If unknown, set
Priority based on SLA Tier.'
217. Add Actions: Search Knowledge Articles, Create Case, Update Case, Send
Email
218. Topic: 'Escalation Handling' — Instructions: 'If customer expresses frustration or
asks for a manager, escalate the case to the Support Manager queue immediately.'

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

219. Create a Flow Action that runs an Escalation Flow — add as Agent Action
220. Configure Guardrails: 'Do not promise specific resolution timelines. Do not
access financial data. Always confirm case number before taking action.'

9.6 – Grounding Configuration

221. Enable Retrieval Augmented Generation (RAG) for Knowledge Articles
222. Configure which objects the agent can query: Lead, Contact, Account, Case,
Knowledge
223. Limit grounding scope using SOQL filters in the Agent object access config
224. Test: ask the agent 'What are the top 3 open cases for Acme Corp?' — it should
run SOQL and return real data

9.7 – Prompt Engineering in Salesforce

225. Create a Prompt Template in Setup > Einstein > Prompt Builder
226. Type: Record Summary — Object: Case
227. Template: 'You are a Salesforce Service agent. Summarize the following Case
for a new agent taking over: Case Subject: {!$[Link]}, Description: {!
$[Link]}, Customer: {!$[Link]}. Keep the summary under
100 words.'
228. Add this as a component on the Case record page
229. Test and iterate on the prompt for accuracy and safety

9.8 – Testing and Governance

230. Test agents in the Agent Studio preview pane before deploying to users
231. Review all agent conversation logs in Einstein Copilot Audit Trail
232. Set up Data Masking rules for sensitive fields like SSN, Credit Card
233. Review and configure the Acceptable Use Policy for your org
234. Assign agents to specific user profiles — not all users should have all agents

✅ Acceptance Criteria / Definition of Done

• Sales Agent successfully qualifies leads using BANT framework
• Service Agent correctly triages Cases and links Knowledge Articles
• Custom Apex Action successfully enriches Contact records via external API
• Prompt Templates generate meaningful Case summaries on the record page
• Audit logs capture all agent interactions
• Guardrails prevent the agent from accessing unauthorized data

⚠️Common Mistakes to Avoid

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

• Writing vague Topic instructions — be specific about scope, tone, and data boundaries
• Adding too many Actions to one Topic — keep topics focused
• Not testing edge cases: what happens when no records are found? When the callout
fails?
• Ignoring governance — AI agents must follow the same security model as users
• Granting agents access to more data than they need — apply least privilege

💡 Best Practices
• Write clear, specific Topic instructions — treat them like system prompts in prompt
engineering
• Name Actions clearly and write descriptive action descriptions — the agent uses these
to decide when to call them
• Test agents as different user personas — a Sales Rep agent should behave differently
than a Support Agent
• Log all agent actions to a custom object for debugging and compliance
• Iterate on prompts using Prompt Builder — measure quality, don't guess

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 10: Deployment & DevOps 🎯 Expert

Overview
Every feature built in earlier phases is only valuable when it can be reliably deployed to
production. This phase covers the full DevOps lifecycle: version control, sandbox strategies,
CI/CD pipelines, and deployment best practices.

💼 Business Scenario
TechNova has 3 developers working in parallel on features. They need a process to develop in
isolated environments, test in a shared QA environment, and deploy to production on a
scheduled release cycle without conflicts or regressions.

Step-by-Step Implementation Tasks

10.1 – Sandbox Strategy

Sandbox Type Use Case
Developer (DE) Individual developer feature work. Each dev
gets their own.
Developer Pro Larger data for complex testing. Shared
between 2-3 devs.
Partial Copy QA environment with a subset of production
data.
Full Copy UAT/staging — exact copy of production. Used
for pre-release testing.

235. Create a Developer sandbox for each team member

236. Create a Partial Copy sandbox for shared QA
237. Establish a 'no direct changes in production' policy — all changes flow through
sandboxes

10.2 – Salesforce DX Setup

238. Install VS Code and Salesforce Extension Pack
239. Install Salesforce CLI: npm install --global @salesforce/cli
240. Authenticate to your sandbox: sf org login web -a my-sandbox
241. Create an SFDX project: sf project generate -n TechNovaSFDX
242. Set up .gitignore to exclude .sfdx folder and credentials

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

243. Retrieve metadata: sf project retrieve start -m ApexClass,Flow,CustomObject

10.3 – Git Branching Strategy

Branch Purpose
main Production-ready code. Protected branch.
release/YYYY-MM-DD Release candidate. Merged from develop
before deploy.
develop Integration branch. All feature branches merge
here.
feature/phase-4-triggers Individual feature work. One branch per
story/task.
hotfix/case-escalation-bug Emergency production fixes. Branches from
main.

244. All developers branch from develop for new features

245. Feature branches are reviewed via Pull Request before merging to develop
246. Develop is merged to release branch for QA testing
247. After QA sign-off, release branch merges to main and is deployed to production

10.4 – CI/CD Pipeline Basics

248. Set up GitHub Actions (or equivalent) with a .github/workflows/[Link]
249. On Pull Request: run Apex tests in a scratch org, fail the PR if tests don't pass
250. On merge to develop: auto-deploy to QA sandbox
251. On merge to main: auto-deploy to production after all tests pass
Key CI/CD pipeline steps:
• Authenticate to target org using JWT auth flow (service account)
• Deploy metadata using sf project deploy start --test-level RunAllTestsInOrg
• Run test suite and parse results
• Slack notification on success/failure

10.5 – Destructive Changes

252. To remove metadata: create a [Link] file listing items to delete
253. Deploy with: sf project deploy start --manifest [Link] --post-
destructive-changes
254. Always backup before destructive deployments

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

10.6 – Pre-Deployment Checklist

Check Tool
All Apex tests pass at 75%+ coverage sf apex run test
No hard-coded IDs in metadata Code review + grep
All flows are active and version-labeled Flow Manager review
Named Credentials point to production Manual config review
endpoints
Data migrations are scripted and reversible Data Loader + backup
Rollback plan documented Runbook document
Stakeholder sign-off obtained UAT sign-off email

✅ Acceptance Criteria / Definition of Done

• All team members have working SFDX/VS Code setup connected to their sandboxes
• Git branching strategy is documented and followed by all team members
• CI pipeline runs on every PR and blocks merge if tests fail
• Production deployment checklist is completed before every release
• Rollback procedure is documented and tested

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Appendix – Resources & Reference

A. Official Salesforce Resources

Resource URL
Trailhead Learning [Link]
Apex Developer Guide [Link]/docs/[Link]-
[Link]
LWC Developer Guide [Link]/docs/lwc/lwc/guide
Flow Reference [Link]/s/articleView?
id=sf.flow_ref.htm
Agentforce Documentation [Link]/s/articleView?
id=sf.einstein_copilot.htm
Salesforce DX Guide [Link]/docs/[Link]-
us.sfdx_dev.meta
Integration Patterns [Link]/docs/[Link]-
us.integration_patterns.meta

B. Recommended Trailhead Modules

• Apex Basics & Database — Start here for Apex
• Apex Triggers — Trigger fundamentals
• Asynchronous Apex — All async patterns covered
• LWC Basics — Component framework introduction
• Security Basics — Platform security model
• Build a Battle Station App — Fun end-to-end project
• Agentforce for Admins — Copilot configuration basics

C. Recommended Tools
Tool Purpose
VS Code + Salesforce Extension Pack Primary development IDE
Salesforce Inspector Reloaded Chrome extension for viewing field API names,
SOQL, and metadata
Workbench Online SOQL queries and metadata operations

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

GitHub Copilot AI pair programming for Apex and LWC

Postman API testing for Klaviyo and HubSpot
integrations
Data Loader Bulk data imports/exports for testing
SFDX Scanner Static code analysis for Apex — catches PMD
issues

D. Key Governor Limits Quick Reference

Limit Value
SOQL Queries (sync) 100
SOQL Rows returned 50,000
DML Statements (sync) 150
DML Rows 10,000
Callouts per transaction 100
Future calls per transaction 50
Queueable jobs enqueued 50
Batch Apex jobs queued 5
CPU Time (sync) 10,000ms
Heap Size (sync) 6MB

E. Phase Completion Summary

Phase Core Skill Unlocked
Phase 1 – Foundations Salesforce data model and declarative
customization
Phase 2 – Security Full platform security model implementation
Phase 3 – Automation Flows, Validations, and Approval Processes
Phase 4 – Sync Apex Apex triggers, SOQL, test classes
Phase 5 – Async Apex Batch, Queueable, Future, Platform Events
Phase 6 – Design Patterns Service/Selector/Domain layered architecture
Phase 7 – Integrations REST API integrations with Klaviyo and
HubSpot

Salesforce Developer Onboarding Guide | v1.0

TechNova Solutions | Salesforce Developer Guide | Internal Use Only

Phase 8 – LWC Custom Lightning components with Jest testing

Phase 9 – Agentforce AI agents with custom actions and grounding
Phase 10 – DevOps CI/CD pipelines and production deployment

— End of Document —

Salesforce Developer Onboarding Guide | v1.0