Module 5 — Salesforce Data Model + SOQL
Module 5 — Salesforce Data Model + SOQL
You do not need to become a Salesforce developer in two days. You need enough Salesforce fluency that when somebody says:
“Query Contacts whose Accounts are active, then update a custom field on those Contacts”
you immediately understand the object relationships and can write or reason about the SOQL.
SOQL is Salesforce’s query language. It looks like SQL, but it is object/relationship-oriented rather than a general relational query language. Salesforce explicitly recommends SOQL when you know which objects/fields contain the data and when you need to query related Salesforce objects.
5.1First: Salesforce is basically an object databaseThink:5.2The four objects you should knowUsually represents a:5.3OpportunityAn Opportunity normally represents a potential sale/deal.5.4CaseA Case usually represents a customer service/support issue.5.5Standard versus custom objectsSalesforce standard object:5.6Don't confuse labels with API namesThe Salesforce UI might display:5.7Salesforce IDsSalesforce assigns an Id to every record.5.8Lookup relationshipsImagine:5.9Lookup vs Master-DetailDon't go too deep unless asked.5.10SOQL basicsBasic syntax:5.11One major difference from SQLDon't instinctively write:5.12Query by External IDThis should look completely natural now:5.13WHERE conditionsYou'll recognize:5.14`IN`Very useful for Mule integration.5.15NULLExample:5.16DatesTypical Salesforce date/date-time fields include:5.17Incremental synchronizationNaive approach:5.18Be careful with watermarksSuppose your job runs:5.19SOQL relationship queriesThis is the most important difference from traditional SQL for this module.5.20Child → ParentWe're querying Contact:5.21Filtering using the parentSuppose interviewer says:5.22Interview scenarioFind Contacts belonging to active enterprise Accounts.5.23Parent → ChildrenNow go the other direction.5.24Child relationship names with custom objectsImagine:5.25Parent relationship on a custom lookupSuppose:5.26Your SQL instincts can hurt youSQL brain:5.27Semi-joinsSuppose we want Accounts that have Contacts meeting a condition.5.28`LIKE`Example:5.29ORDER BYFor deterministic pagination/integration logic, sorting can matter.5.30LIMITGreat during:5.31COUNTExample:5.32Other aggregate conceptsRecognize:5.33A great QA/developer use case: reconciliationSay Mule imports:5.34Avoid querying unnecessary fieldsBad:5.35Avoid query-per-recordClassic N+1 problem.5.36Building a lookup map in DataWeaveSuppose Salesforce returns:5.37SOQL versus SOSLKnow the distinction.5.38Object security mattersJust because:5.39Sandbox versus production schema driftImagine QA Salesforce:5.40Salesforce validation rulesA perfectly valid Mule request can still fail downstream.5.41Salesforce automation can surprise youA Mule upsert may cause:5.42Scenario 1 — find the AccountRequirement:5.43Scenario 2 — retrieve ContactsRequirement:5.44Scenario 3 — Account and Contacts togetherResult conceptually:5.45Scenario 4 — Open OpportunitiesRetrieve open Opportunities over $100,000 for active Accounts.5.46Scenario 5 — CasesRetrieve open high-priority Cases for customer C001.5.47Scenario 6 — incremental Mule jobEvery 15 minutes:5.48The interview question I promisedInterviewer:5.49Questions they may ask“It's SQL-like, but designed specifically around Salesforce objects and relationships. Rather than arbitrary SQL joins, you usually…5.50What you actually need to memorizeThis:•Module 5 condensed cheat sheetThe next module should be Module 6: Mule routing and orchestration — Choice, For Each, Parallel For Each, Scatter-Gather, Flow Reference…