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.3codeOpportunityAn 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.10codeSOQL basicsBasic syntax:5.11codeOne major difference from SQLDon't instinctively write:5.12codeQuery by External IDThis should look completely natural now:5.13codeWHERE conditionsYou'll recognize:5.14code`IN`Very useful for Mule integration.5.15codeNULLExample:5.16codeDatesTypical Salesforce date/date-time fields include:5.17codeIncremental 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.20codeChild → ParentWe're querying Contact:5.21codeFiltering using the parentSuppose interviewer says:5.22Q&AcodeInterview scenarioFind Contacts belonging to active enterprise Accounts.5.23codeParent → ChildrenNow go the other direction.5.24codeChild relationship names with custom objectsImagine:5.25codeParent relationship on a custom lookupSuppose:5.26codeYour SQL instincts can hurt youSQL brain:5.27codeSemi-joinsSuppose we want Accounts that have Contacts meeting a condition.5.28code`LIKE`Example:5.29codeORDER BYFor deterministic pagination/integration logic, sorting can matter.5.30codeLIMITGreat during:5.31codeCOUNTExample:5.32codeOther aggregate conceptsRecognize:5.33codeA great QA/developer use case: reconciliationSay Mule imports:5.34codeAvoid querying unnecessary fieldsBad:5.35Avoid query-per-recordClassic N+1 problem.5.36codeBuilding a lookup map in DataWeaveSuppose Salesforce returns:5.37codeSOQL versus SOSLKnow the distinction.5.38Object security mattersJust because:5.39Sandbox versus production schema driftImagine QA Salesforce:5.40codeSalesforce validation rulesA perfectly valid Mule request can still fail downstream.5.41Salesforce automation can surprise youA Mule upsert may cause:5.42codeScenario 1 — find the AccountRequirement:5.43codeScenario 2 — retrieve ContactsRequirement:5.44codeScenario 3 — Account and Contacts togetherResult conceptually:5.45codeScenario 4 — Open OpportunitiesRetrieve open Opportunities over $100,000 for active Accounts.5.46codeScenario 5 — CasesRetrieve open high-priority Cases for customer C001.5.47codeScenario 6 — incremental Mule jobEvery 15 minutes:5.48Q&AcodeThe interview question I promisedInterviewer:5.49Q&AQuestions they may ask“It's SQL-like, but designed specifically around Salesforce objects and relationships. Rather than arbitrary SQL joins, you usually…5.50codeWhat you actually need to memorizeThis:•cheat sheetModule 5 condensed cheat sheetThe next module should be Module 6: Mule routing and orchestration — Choice, For Each, Parallel For Each, Scatter-Gather, Flow Reference…