Salesforce from zero, for a Foundry-fluent engineer — concepts, navigation, and the Rosetta Stone

§0 — How to read this

You know Palantir Foundry. You’ve never driven Salesforce. This doc closes that gap by teaching Salesforce’s concepts through their Foundry analogues, with the exact click-paths to find each thing, so the hands-on lab stops being “click here, then here” and becomes “oh, this is Foundry’s X, but transactional.” Use it as the reference you keep open in the other monitor while you do the lab.

The single biggest mental adjustment up front: Foundry cleanly separates data integration (pipelines, Spark, code repos) from the ontology/app layer (object types, Actions, Workshop). Salesforce collapses those into one thing. An “object” in Salesforce is simultaneously the storage table, the API resource, the security boundary, and the app UI. There’s no first-class heavy-transform pipeline layer — Salesforce is an OLTP application database with a low-code app builder bolted on, not an analytical platform. It has hard per-transaction limits (governor limits) precisely because it’s multi-tenant OLTP, not your own Spark cluster. Hold that and most of the surprises below make sense.

§1 — The Rosetta Stone (bookmark this table)

Salesforce	What it is	Closest Foundry concept	Key difference
Org	Your tenant/instance (data + config + code)	An enrollment / stack	Multi-tenant; you never see the servers. Flavors: production, sandbox, Developer Edition (free, permanent), scratch org (throwaway, source-driven)
Object (sObject)	A table and an ontology object type and an API resource	Ontology object type	It’s also the security boundary and the UI unit. Storage + model + app in one
Field	A column / property on an object	Object-type property	Includes computed formula fields and roll-up summaries (aggregates over child rows)
Record	One row / one object instance	An object (instance)	—
Relationship (Lookup / Master-Detail)	A foreign-key link between objects	Ontology link type	Master-Detail = ownership + cascade delete + enables roll-ups; Lookup = loose FK
Record Type	A named variant of one object (different picklists/layout)	~ a subtype / variant	Same table, different “flavor” of record + UI
Flow	The primary no-code automation/orchestration engine	Actions + Automate, visually authored	Runs inside the transaction; governed by limits. Your main workhorse
Apex	Proprietary Java-like language for logic	Functions (TS/Python)	Drop to it only when Flow can’t. Hard governor limits per transaction
Validation Rule	A row-level write constraint	Action validation / property constraint	Fires on save; blocks the DML
Lightning App Builder / Page Layout	Drag-drop record & app pages	Workshop (app builder)	Declarative UI assembly
Lightning Web Component (LWC)	Web-component front-end framework	Custom Workshop widget / custom app	Real code (JS + HTML) when the declarative UI isn’t enough
Profile / Permission Set / Role / OWD / Sharing Rule	The security & visibility model	Roles, markings, restricted views	See §6 — this is denser than Foundry’s model and trips everyone
SOQL	Salesforce Object Query Language	~ Ontology queries / OSDK	Not SQL — no arbitrary joins; only relationship traversal. See §8
Data Cloud / Data 360	CDP + zero-copy federation layer	The closest thing to Foundry’s data-integration layer	Unifies external + CRM data; zero-copy to Snowflake/Databricks
App	A named bundle of tabs/objects (Sales Cloud, Service Cloud…)	A Workshop application / module	”Clouds” are just feature+object bundles on one core platform
Metadata API / Tooling API / SFDX	Config-as-code + source-driven dev	Code repos + CI on the ontology	You can treat config as versioned source — see §8
Agentforce	Autonomous AI agent layer (Topics + Actions + Atlas planner)	AIP agents / AIP Logic	Agents call Flows/Apex/APIs/MCP tools as actions. See §9

§2 — Navigating the UI (the 5 things you actually need)

Salesforce’s UI is called Lightning Experience (the modern one; “Classic” is the legacy UI — ignore it). Five navigation primitives get you everywhere:

The App Launcher — the waffle icon (⋮⋮⋮) top-left. Switches between “apps” (Sales, Service, your custom app) and finds any object’s tab. Think of it as the Foundry app switcher.
Setup — the gear icon (⚙︎) top-right → Setup. This is the admin/builder backstage — everything you configure (objects, flows, users, security, APIs) lives here. It opens in its own tab. 90% of the lab happens in Setup.
Quick Find — the search box in the left rail of Setup. Type “Object Manager,” “Flows,” “Permission Sets,” “Agent” — it’s the fastest way to reach any Setup page. Learn to live in it.
Object Manager — Setup → Quick Find → “Object Manager.” The schema editor: every object, its fields, relationships, record types, page layouts, validation rules. This is your ontology-editor equivalent.
The record page — what an end user sees: one record (an Account, a Case) with its fields, related lists (child records), and an activity/chatter feed. The App Builder designs these.

Two-tab habit: keep Setup open in one browser tab (building) and the app open in another (using what you built). You’ll bounce constantly.

§3 — The data model: objects, fields, relationships

Objects

Standard objects ship with the platform: Account (a company), Contact (a person at a company), Lead, Opportunity (a deal), Case (a support/service ticket), Asset (a serialized product a customer owns), Order, Product2, Entitlement, Contract.
Custom objects are yours; their API name ends in __c (e.g. RMA_Line__c). Custom fields also end in __c. That suffix is how you tell “platform” from “we added this” at a glance.
Navigate: Setup → Object Manager → click an object → Fields & Relationships, Page Layouts, Record Types, Validation Rules in the left menu.

Foundry bridge: an sObject ≈ an ontology object type, but remember it’s also the table and the API resource. When you “create a custom object,” you’re doing the equivalent of defining an object type and provisioning its backing dataset in one gesture — no separate pipeline to land the data.

Fields (property types worth knowing)

Basic: Text, Number, Date/Datetime, Checkbox, Picklist (enum), Email, Phone, URL.
Lookup / Master-Detail: the relationship field types (see below).
Formula field: computed at read time from other fields (like a derived property). No storage.
Roll-up summary field: an aggregate (COUNT/SUM/MIN/MAX) over child records — only available on the parent side of a Master-Detail relationship. This constraint matters constantly.

Relationships (the part Foundry people most want to understand)

Lookup — a loose foreign key. Child can exist without parent. Deleting the parent doesn’t delete the child. Most relationships are lookups.
Master-Detail — a strong ownership link. The child cannot exist without the parent, inherits its sharing/security, is deleted when the parent is (cascade), and enables roll-up summaries on the parent. Use when the child is truly a part of the parent (order → order line).
Junction object — to model many-to-many, you create a custom object with two Master-Detail fields, one to each side. (e.g. to link Assets ↔ Contracts many-to-many.) This is the standard M:N pattern; there’s no native M:N field.
Hierarchical — a special self-lookup, only on the User object (manager chains).

Foundry bridge: relationships ≈ link types. Master-Detail is the one with no clean Foundry analogue — it bundles cascade-delete + security inheritance + aggregation-enablement into the link itself.

Record Types

One object, multiple “flavors.” A Case with record types Standard / Advance / Buffer shares the table but can show different picklist values, different page layouts, and route through different automation. Foundry bridge: like a discriminated subtype that also swaps the UI. Navigate: Object Manager → the object → Record Types.

§4 — The automation layer (this is where you’ll live)

Salesforce automation is now “Flow-first.” The older tools — Workflow Rules and Process Builder — are retired/being retired; don’t learn them. Everything is Flow, with Apex as the escape hatch.

Flow / Flow Builder

A Flow is a visually-authored program that runs inside a database transaction. Navigate: Setup → Quick Find → “Flows” → New Flow. It’s a canvas of connected elements. The flow types you’ll meet:

Record-Triggered Flow — fires when a record is created/updated/deleted. The workhorse. Runs before-save (fast, same-transaction field updates) or after-save (can do more, e.g. create related records, send email). Foundry bridge: ≈ an Action + Automate rule that reacts to a change.
Screen Flow — a multi-step wizard UI for a user (screens with inputs). Foundry bridge: a guided Workshop workflow. Embeddable on pages.
Scheduled Flow — runs on a schedule over a batch of records. Foundry bridge: a scheduled build.
Autolaunched Flow — no UI, called by other things (Apex, other flows, a REST call, an Agentforce action).
Platform Event-Triggered Flow — reacts to an event on the event bus (see Streaming, §8).

Flow elements (the glossary): Get Records (query/read), Create / Update / Delete Records (DML), Assignment (set variables), Decision (branch/if-else), Loop (iterate a collection), Subflow (call another flow), Screen (UI step), Action (call an email/Apex/etc.). If you can read a flowchart, you can read a Flow.

Approval Processes

A distinct, older-but-current construct for multi-step human sign-off: a record enters an approval, routes to approver 1 → 2 → 3, each can approve/reject, with field updates at each step. Navigate: Setup → Quick Find → “Approval Processes.” Foundry bridge: a human-in-the-loop Action chain. (In the lab you build a case-management → quality → finance gauntlet this way — or with an approval-step Flow.)

Validation Rules

A boolean expression evaluated on save; if it’s true, the save is blocked with your error message. Row-level write constraints. Navigate: Object Manager → the object → Validation Rules.

Apex (the code escape hatch)

Proprietary, Java-like, server-side. You write it when Flow can’t express the logic (complex loops, callouts to external systems, bulk processing). Forms:

Trigger — Apex that runs on a DML event (like a code-level record-triggered flow).
Class — reusable logic; can be exposed as Apex REST endpoints.
Batch / Queueable / Scheduled Apex — async processing of large volumes.

The thing that will bite you: governor limits. Because it’s multi-tenant OLTP, each transaction is capped — 100 SOQL queries, 150 DML statements, 50,000 rows retrieved, 10 seconds CPU, 100 callouts. You must write “bulkified” code (operate on collections, never one-row-at-a-time in a loop). Foundry bridge: the opposite of Spark’s “throw more executors at it” — here you engineer down to fit a small per-transaction budget. Navigate: Setup → Quick Find → “Apex Classes” / Developer Console (gear → Developer Console) to run anonymous Apex.

§5 — The UI layer

Page Layout — the classic field-arrangement for a record (which fields, related lists, in what order). Per object, per record type.
Lightning App Builder — the modern drag-drop page designer: assemble a record page from components (standard ones + your LWCs). Navigate: on any record → gear → Edit Page. Foundry bridge: Workshop.
Lightning Web Component (LWC) — a real web component (JavaScript + HTML template) you write and drop onto pages when the standard components don’t cut it. Foundry bridge: a custom Workshop widget.
Experience Cloud — the product for building external-facing sites/portals (a customer login where they file and track their own cases). Foundry bridge: an externally-shared Workshop app. Navigate: Setup → Quick Find → “Digital Experiences” / “All Sites.”

§6 — The security & visibility model (denser than Foundry — read slowly)

Salesforce access is additive from a deny-by-default base, computed from several layers:

Profile — every user has exactly one. Sets the baseline: which objects/fields they can CRUD, which apps/tabs, and system permissions. (Salesforce is moving baseline permissions toward permission sets, but the profile still anchors login/defaults.)
Permission Set — additive grants layered on top of the profile (this user also gets X). You give extra access by assigning perm sets, never by cloning profiles. Permission Set Groups bundle several; Muting Permission Sets subtract within a group.
Role / Role Hierarchy — drives record visibility roll-up: managers up the hierarchy can see their reports’ records. Orthogonal to profiles (which govern what actions, not whose records).
Org-Wide Defaults (OWD) — the baseline record-sharing per object: Private, Public Read Only, or Public Read/Write. Start restrictive, then open up.
Sharing Rules / Manual Sharing / Sharing Sets — the mechanisms that open up access above the OWD floor (share these records with that role/group).

Foundry bridge: Profiles+Perm Sets ≈ “what operations/columns can this role perform” (like role-based capability + column policies); Roles+OWD+Sharing ≈ row-level markings / restricted views — which records a user can see. The mental model: Profile/Perm Set = verbs; OWD + Role + Sharing = which rows. Navigate: Setup → Quick Find → “Profiles,” “Permission Sets,” “Sharing Settings,” “Roles.”

This layer is why “who at each customer may see what” is a hard requirement in any external-portal build — it’s real per-account row-level scoping, not a filter.

§7 — The “Clouds” are just feature bundles

A source of early confusion: Sales Cloud, Service Cloud, etc. sound like separate products but are bundles of objects + features on one shared core platform. The ones you’ll touch:

Service Cloud — the Case object + the agent Console UI + entitlements/SLAs. The support-ticket world. This is the heart of an RMA/returns flow.
Experience Cloud — external portals (§5).
Salesforce Order Management (OMS) — the Order and Return Order objects + fulfillment/ returns logic. Where advance-replacement (ship-before-return) is modeled natively.
Data Cloud / Data 360 — the CDP + zero-copy federation layer. Ingests external data into Data Model Objects (DMOs), unifies identities, and can query Snowflake/Databricks without moving data. Foundry bridge: this is the nearest neighbour to Foundry’s data-integration story — and the grounding source Agentforce reads from. If any part of Salesforce will feel familiar to you, it’s this one.

Foundry bridge: think of the core platform as the ontology + app runtime, and each “Cloud” as a pre-built module (a set of object types + Workshop apps + automations) for a domain.

§8 — Dev & integration surface (your §4 lab, demystified)

SOQL is not SQL

You query one object at a time; there are no arbitrary joins. You traverse relationships instead:
- Child → parent (dot notation): SELECT Id, Account.Name, Account.Owner.Email FROM Contact
- Parent → children (subquery): SELECT Name, (SELECT LastName FROM Contacts) FROM Account
No SELECT * — you name every field. Aggregations exist (COUNT(), GROUP BY) but are limited.
SOSL is the separate full-text search language across objects.
Foundry bridge: closer to traversing ontology links / the OSDK than to writing SQL against a warehouse. If you catch yourself wanting a join, you want a relationship query.

The APIs (all covered in the lab)

REST API — /services/data/vXX.0/… — CRUD + SOQL over HTTP. The default.
Bulk API 2.0 — async large export/import (millions of rows). For backfills.
Composite API — bundle many related calls into one round-trip.
Streaming — push changes out: Platform Events (custom pub/sub messages), Change Data Capture (CDC) (row-change events), consumed via the Pub/Sub API. Foundry bridge: CDC ≈ streaming a dataset’s changes; this is how you’d keep an external store in near-real-time sync.
Apex REST — custom endpoints you write.
Metadata API / Tooling API — read/write the config itself (objects, flows, layouts) as code.

Source-driven dev (SFDX) — the part that’ll feel like home

Salesforce config can be treated as versioned source, which is the bridge from “clicking in Setup” to “engineering”:

sf CLI — the command line (you installed it). sf org login web, sf data query, sf project retrieve/deploy (pull/push metadata), sf apex run.
Scratch orgs — ephemeral, source-defined orgs you spin up from a config file, build against, and throw away. Foundry bridge: like a per-branch preview environment. (Requires enabling a Dev Hub; a Dev Edition org can be one.)
Packages — unlocked packages (your own modular, versioned config) vs managed packages (the ISV distribution format on AppExchange, Salesforce’s app marketplace). Foundry bridge: unlocked ≈ your internal modular repo; managed ≈ a published, encapsulated product.

Middleware / iPaaS

For system-to-system sync (the canonical SAP↔Salesforce pattern), the integration lives in MuleSoft (Salesforce-owned) or a third-party iPaaS (Boomi, Workato, etc.), outside both systems, calling their APIs on a poll cycle. Foundry bridge: like external ETL orchestration between two source systems — neither owns the pipe.

§9 — The AI layer, in one screen (recap)

Three layers, keep them distinct:

Einstein — predictive/generative features inside the apps (case classification, reply drafts, summaries). Assistive; a human acts on the suggestion.
Prompt Builder + Data Cloud — reusable prompt templates grounded in live records (and unified Data Cloud data). This is how Salesforce hands an LLM trustworthy context. Foundry bridge: ≈ AIP Logic / grounded prompt blocks.
Agentforce — the autonomous agent: Topics (jobs it may do) + Actions (tools it can call: a Flow, an Apex method, a prompt template, an API, or an MCP tool), planned by the Atlas Reasoning Engine. Foundry bridge: ≈ an AIP agent whose “tools” are Salesforce automations. The MCP action type is the door for your own external tools/agents — the keystone of the lab’s §4.4.

Navigate: Setup → Quick Find → “Einstein Setup,” “Agentforce Studio” / “Agent Builder,” “Prompt Builder.” (Names drift — confirm in your org’s Setup menu.)

§10 — Gotchas for a Foundry engineer (the sharp edges)

No pipeline layer. There’s no Spark, no heavy transform stage. You integrate via API/Data Cloud/middleware and do light shaping in Flow/Apex. Stop looking for the pipeline — it isn’t there.
Governor limits are a hard wall, not a perf knob. Per-transaction caps (SOQL/DML/CPU) will throw errors, not just slow down. Bulkify everything.
SOQL ≠ SQL. No joins; traverse relationships. (§8)
The object is the security boundary and the UI. Modeling a new object also provisions its API, its permissions surface, and its pages — one gesture, four consequences.
Additive, deny-by-default security across ~5 layers. (§6) Budget real time here; “why can’t this user see this record” is the #1 time-sink, and the answer is usually OWD + sharing, not the profile.
Metadata, not migrations. You rarely write DDL; you declare config (clicks or Metadata-API source) and the platform reconciles it. SFDX (§8) is how you make that feel like engineering.
Declarative-first is cultural, not just technical. The platform (and every admin you’ll meet) reaches for Flow before code. Apex is the exception, not the default — inverted from how you’d approach Foundry Functions.

§11 — Your first 30 minutes in a fresh Dev org (guided nav)

Do this once, before the lab, purely to orient:

Sign up for a Developer Edition org → log in → you land in Lightning Experience.
Click the waffle (App Launcher) → open Service → click the Cases tab → New → create one dummy Case. You’ve now made a record in a standard object.
Click the gear (⚙︎) → Setup. New tab opens.
In Quick Find, type Object Manager → click Case → Fields & Relationships → skim the fields → New → add a custom field Test_Flag__c. You’ve extended a standard object.
Quick Find → Object Manager → Create → Custom Object → make RMA_Line__c. You’ve made an object (= provisioned a table + ontology type + API + pages).
Quick Find → Flows → New Flow → Record-Triggered Flow on Case → add a Decision and an Update Records element → save. You’ve written your first automation.
Quick Find → Permission Sets → skim one → note it’s additive. Quick Find → Sharing Settings → see the OWD per object. That’s the security model in the flesh.
Quick Find → Agentforce Studio / Einstein Setup → confirm it’s enabled (the §3 gate of the lab).

By step 8 you’ve touched an object, a field, a custom object, a flow, the permission model, and the AI entry point — the whole spine of the platform. Now the lab will read as “build the real version of each of these.”

Companion to the hands-on Salesforce lab. Generic SFDC pedagogy, NDA-free — safe to keep public. Product/feature names (especially Agentforce) drift between releases; verify menu paths in your own org’s Setup. Foundry analogies are teaching bridges, not exact equivalences.

Project TBD Memory Vault

Explorer