Salesforce Developer key terms

A shared infrastructure model where many customer organizations run on the same application servers and database while their data stays logically separated. This design keeps costs low but forces Salesforce to impose per-transaction limits on every tenant.

Runtime caps Salesforce enforces per transaction to stop one tenant from consuming shared resources. Examples include the number of SOQL queries, DML statements, and CPU time allowed; code that exceeds them fails with a limit exception.

A unique 15- or 18-character identifier assigned to each Salesforce org. It appears in login URLs and API responses and is used to confirm which environment code or data is pointing at.

A settings container that controls what a user can do: object permissions, field access, app visibility, and system permissions. Every user has exactly one profile, and it also sets default record layout assignments.

An add-on collection of settings and object or field permissions given to individual users on top of their profile. It grants extra access without changing the profile, and one user can hold many permission sets.

A tree of roles that mirrors the reporting structure and widens record access upward. A manager above a subordinate in the hierarchy can see the same records that the subordinate can, when sharing settings allow it.

The baseline sharing setting for each object that decides whether records are private, public read-only, or public read/write. It is the starting point that role hierarchy, sharing rules, and manual sharing can only widen.

A database table you create to store data specific to your business, such as invoices or equipment. It gets its own API name, fields, page layouts, and tabs, and behaves much like a standard object.

A field that links one record to a parent record without making the child dependent on it. The child can exist without a parent, deleting the parent does not delete the child, and roll-up summaries are unavailable.

A tightly coupled parent-child link where the child cannot exist without the parent. The parent controls sharing and ownership of the child, deleting the parent deletes children, and roll-up summary fields can be created on the parent.

A custom object with two master-detail relationships, used to model a many-to-many relationship between two other objects. A contact-role object linking contacts to opportunities is a typical example.

A read-only field whose value Salesforce calculates at display time from an expression that references other fields, functions, and merge values. Nothing is stored, so it stays current whenever the source values change.

A field on a parent record that calculates count, sum, min, or max from its related child records. It requires a master-detail relationship and updates automatically when child records are saved or deleted.

A condition that blocks a record from being saved when it evaluates to true, showing an error message to the user. Rules run in the browser and again in the API, so they apply to every save path.

A configuration that lets one object offer different business processes, picklist values, and page layouts to different groups of users. It is assigned per profile or chosen by users in the interface.

A text field marked as an external identifier that holds a unique key from another system. It is used for upsert operations and for matching records during data import.

Salesforce Object Query Language, a SQL-like syntax for reading records, for example SELECT Id, Name FROM Account WHERE Industry = 'Tech'. It queries one object at a time and returns records your sharing rules let you see.

Salesforce Object Search Language, which searches text across multiple objects at once and returns results grouped by object. It is useful when you do not know which object holds the value you need.

A point-and-click diagram tool for viewing and building objects, fields, and relationships on one canvas. It shows the data model visually and lets you add custom objects and lookups without leaving the page.

Code that runs before or after insert, update, delete, or undelete events on a specific object. Triggers enforce logic that configuration cannot handle, and best practice is one trigger per object.

A block of Apex code containing methods and variables that can be called from triggers, Lightning components, Visualforce pages, or web services. Classes are compiled on save and stored in the org.

A way to run code in the background, outside the user's request, using future methods, batch, queueable, or scheduled jobs. It gets higher limits and decouples long-running work from the interface.

An interface for processing large record sets in chunks, where each chunk runs as its own transaction with fresh governor limits. A class implements Database.Batchable with start, execute, and finish methods.

A job type that runs asynchronously and accepts complex data such as custom objects or sObjects. Jobs can be chained by enqueuing another job from inside, and an ID is returned for monitoring.

A class implementing the Schedulable interface that Salesforce runs at a set time or on a recurring schedule. You schedule it through the user interface or System.schedule, and it executes in the background.

The declarative automation tool for building screen, record-triggered, schedule-triggered, and autolaunched flows. It can create and update records, call Apex, and show screens, and it replaces older workflow tools.

A user interface framework built on standard web components, using HTML templates, JavaScript modules, and a reactive wire service to fetch Salesforce data. It is the current standard for custom Lightning pages.

The earlier Lightning component model with a bundle of markup, JavaScript controller, and helper files. Aura components can host Lightning web components and still appear on many existing pages.

A server-rendered page framework that uses tag-based markup and an optional Apex controller. It is older than Lightning but still used for email templates, PDFs, and special layouts.

A drag-and-drop tool for assembling Lightning pages and apps from standard and custom components. You can build record pages, home pages, and app pages and assign them to specific users or apps.

A class annotated with @isTest that verifies your code's behavior and does not count against most data limits. Your Apex must be covered by tests before it can be deployed to production.

The percentage of Apex lines executed by test methods. Production deployments require at least 75 percent coverage across the org with no failures, though coverage alone does not prove the tests are meaningful.

A method that marks the start of the tested portion of a test method, resetting governor limits and separating setup work from the code under test. It is paired with Test.stopTest().

A statement that fails the running test when its condition is not met, such as checking that a query returns exactly one record. Assertions turn a test from a code runner into a real behavioral check.

A block of Apex you run on demand from the Developer Console or command line without saving it to a class. It is used for quick debugging, data fixes, and manually exercising logic.

A container of metadata components you send from one org to another, typically sandbox to production. You add components, upload, then deploy and validate them in the target org.

A command-line tool for authenticating to orgs, retrieving and deploying metadata, running tests, and scripting repetitive developer tasks. Source-format projects and scratch orgs are managed through it.

A record of what happens during a transaction, including database calls, flow interviews, Apex execution, and errors. You set trace levels for a user and inspect logs in the Developer Console or a log viewer.

A copy of a production org used for development, testing, and training. Sandboxes come in types such as Developer, Developer Pro, Partial, and Full, each with different data and refresh intervals.