Salesforce terms starting with M

Machine learning is the discipline of building software that learns patterns from data instead of being explicitly programmed with rules. In Salesforce, machine learning shows up across the Einstein platform: classifying cases by topic, scoring opportunities by win probability, recommending the next best action, detecting duplicate records, forecasting pipeline, and dozens of smaller features that surface predictions inside the standard UI. Most of these run on managed ML models that Salesforce trains and operates; some run on customer-trained models built with Prediction Builder or Einstein Discovery. Machine learning is the umbrella; large language models, predictive models, classification models, embedding models, and recommendation models are categories underneath it. The Salesforce conversation often blurs ML and LLM together because the recent product investment has gone heavily into generative AI, but the predictive and classification ML features that have been in Sales and Service Cloud for years still drive significant business value and follow the older ML lifecycle of training on labeled data, evaluating on holdouts, and retraining on a schedule.

A Macro in Salesforce is a sequence of pre-configured actions that an agent can run on a record with one click. The most common use is in the Service Console, where macros let agents handle repetitive case patterns (set Status to In Progress, attach a Knowledge article, send a templated email, change the case Owner to the SME queue) as a single operation instead of five separate clicks. Macros are configured by admins, organized by folders, and assigned to user groups through permission sets. Macros come in two flavors. Bulk Macros run silently against a list of records (close every selected case with status Resolved). Regular Macros run interactively against the active record in the console, prompting the agent for any inputs the macro template needs. Both flavors are built in the Macro Builder UI inside the Service Console. Modern macros use the Lightning Macro framework, replacing the legacy Aura-based macros that shipped originally. Macros are the lightweight automation layer between manual click-by-click work and the heavier Flow-based automation that runs in the background.

A Mail Merge in Salesforce is a feature that produces personalized Microsoft Word documents, such as letters, contracts, and proposals, by inserting record data into a prepared template. The template holds merge fields like {!Account.Name}, and Salesforce swaps each one for the matching field value from the record you choose. The result is a finished Word document tied to that record's data. Mail Merge is a legacy, Classic-era feature, so it carries an important split. The original Standard Mail Merge, which ran through the Connect for Office Word add-in on the user's desktop, was retired by Salesforce on March 4, 2017. Its successor, Extended Mail Merge, runs server-side and still works today. Even so, most modern orgs reach for AppExchange tools or native document generation instead, because Mail Merge lives only in Salesforce Classic and outputs Word files.

A Mail Merge Template is a Microsoft Word document stored in Salesforce that drives the platform's native Mail Merge feature. The document holds Salesforce merge fields, written with syntax like {!Account.Name} or {!Contact.FirstName}, that Salesforce swaps for live record data when a user generates a document. Templates live as records on the Mail Merge Template object, reached through Setup under Communication Templates, Mail Merge Templates. Mail Merge Templates are a legacy feature. They power two older generation paths: Standard Mail Merge, which ran in the browser through the Connect for Office Word add-in, and Extended Mail Merge, which renders server-side. Standard Mail Merge and Connect for Office were retired on February 1, 2019. Most current orgs use Lightning Email Templates for email-style merge content and an AppExchange document generation app for richer letters, contracts, and PDFs.

A Maintenance Plan is a Salesforce Field Service record that defines a recurring schedule for preventive maintenance on customer assets. It ties one or more assets to a Work Type and a cadence, then generates Work Orders in batches so technicians service the equipment before it fails. The standard MaintenancePlan object usually mirrors the terms of a service contract or an entitlement. Think of it as the engine that turns a "service every 90 days" promise into actual scheduled work. Instead of staff tracking due dates in spreadsheets, the platform calculates the next service date for each covered asset and creates the Work Orders for you. From there the work flows into normal Field Service dispatch, scheduling, and completion.

A Major Release is one of the three platform-wide upgrades Salesforce ships every year, named after the seasons: Spring, Summer, and Winter. Each one adds new features across every Salesforce product, changes or retires older behavior, and refreshes the platform that runs under your org. Every customer moves to the same version automatically on a published schedule, so a major release is the shared upgrade clock that the whole Salesforce ecosystem runs on. A major release is not a download or an install. Salesforce upgrades your instance during a short maintenance window (often around five minutes), and your org wakes up on the new version. The work for admins and developers happens before that, during the sandbox preview period. That is when teams read the release notes, test against the new code, train users, and clear any changes that Salesforce will enforce automatically later.

Manage Connected Apps is the Salesforce Setup page where an administrator governs every Connected App installed in or created within an org. A Connected App is a configuration record that lets an external application authenticate to Salesforce through OAuth 2.0 and related identity protocols. The page is the control surface for those records: it lists each app, opens its policies for editing, and ties each app to the profiles and permission sets allowed to use it. From this one place an admin decides who may authorize an app, how strictly IP rules apply, how long refresh tokens stay valid, and which session policies are enforced. Because every Connected App is a doorway for outside access, the page is also a security boundary. Loose policies or forgotten apps quietly widen the attack surface, so the work done here matters as much as the apps themselves.

Manage Slack Connection is a Setup page in Salesforce that configures and maintains the connection between a Salesforce org and one or more Slack workspaces. The page provides controls for authenticating the connection through OAuth, mapping Salesforce records to Slack channels, configuring which users can use Slack-aware features, and monitoring the health of the integration over time. It is the central operational surface for any Salesforce-to-Slack integration that the org has enabled. Salesforce acquired Slack in 2021 and has since built deep integration between the two platforms. The Manage Slack Connection page is the front door to that integration, used by admins to wire up features like Slack record sharing, Salesforce sales notifications in Slack channels, Slack-based approval routing, and the Service Cloud-Slack agent collaboration features. Each enabled feature reads from the connection configuration on this page.

Manage Subscription is the self-service area in Salesforce Setup where an org owner views and changes its own Salesforce subscription: the products and editions it pays for, the user license counts, the contract dates, and the billing details. On modern orgs this experience is delivered through the Your Account app, which opens from Setup and the App Launcher. It puts the subscription state and routine purchasing in the admin's hands instead of requiring a call to an account executive for every change. From one place a billing admin can review current products, add licenses for new hires, see renewal dates, update a credit card, and download invoices. The app reaches into Salesforce Checkout for the commerce and billing records behind those actions. Access is gated by the Manage Billing permission, so the financial information stays restricted to the people who should see it.

A Managed Package is a versioned, namespace-locked bundle of Salesforce metadata that an Independent Software Vendor (ISV) develops, signs, and distributes through AppExchange or a direct install URL. The defining traits of a managed package are namespace ownership (every component gets a prefix like vendor__), upgrade tracking (the platform records which package version is installed and can apply minor and patch upgrades cleanly), and code protection (Apex classes can be marked global, public, or private, with private code invisible to subscribers). Managed packages are the technical mechanism behind every AppExchange listing that ships actual platform code. The model serves three audiences: ISVs who need a way to ship and update enterprise software at scale, customers who want third-party functionality without managing the metadata themselves, and Salesforce who runs the AppExchange marketplace and takes a revenue share on paid packages. The packaging tooling has gone through two generations. First-generation managed packages (1GP) use a packaging org as the source of truth. Second-generation managed packages (2GP) use Salesforce DX with the source repository as the canonical model.

A Managed Package Extension is a separate managed package that extends or builds on top of another managed package, treating the underlying package as a dependency. The extension package can reference objects, fields, Apex classes, and components from the base package and add its own components alongside them. AppExchange ISVs use the extension pattern to ship add-on products that augment a base product without forking it: an extension to a CPQ package adds industry-specific pricing logic; an extension to a contract-management package adds e-signature integration. Extensions are a first-class concept in the Salesforce packaging model. The extension declares its dependency on the base package; customers must install the base package before installing the extension. Salesforce enforces install order and version compatibility automatically. The extension can reference (but not modify) the base package''s metadata: Apex classes via global methods, custom objects via fields and lookups, Lightning components via inheritance. The base package author cannot prevent extensions from existing; the extension model is open by design, which is what enables the multi-vendor AppExchange ecosystem.

A manifest file in Salesforce is an XML file, usually named package.xml, that lists the metadata components you want to retrieve from or deploy to an org. The Metadata API reads the manifest as a request specification. It declares which metadata types are involved and which named members within each type are part of the operation. The Salesforce CLI commands sf project retrieve start and sf project deploy start both accept a manifest to scope exactly what moves between your local project and an org. A second manifest, destructiveChanges.xml, uses the same format to list components you want to delete. Together the two files describe a complete deployment: what to add or update, and what to remove. Manifests are the backbone of metadata work outside source-tracked environments. Production deployments, packaging builds, and most CI/CD pipelines all reference a manifest to control precisely which components get touched.

Manual sharing is a Salesforce sharing mechanism that lets a record owner (or a user with Modify All Data) grant access to a specific record to another user, role, or public group, without changing any other access settings. It is the platform's escape hatch for one-off sharing exceptions: situations where the standard sharing model (organization-wide defaults, role hierarchy, sharing rules) does not grant access to a person who needs to see this single record. A manual share is created from the Sharing button on the record detail page (Classic) or from the Sharing modal in Lightning. The grantor picks the user, group, or role to share with, sets the access level (Read Only or Read/Write), and saves. The share record persists in the object's Share table (AccountShare, OpportunityShare, custom_object__Share) until manually removed or until the underlying ownership changes and the platform recalculates. Manual sharing is being supplemented by Restriction Rules and other modern sharing mechanisms, but it remains the foundation for record-level sharing flexibility.

Manufacturing Cloud is the Salesforce industry product built for manufacturers, distributors, and industrial suppliers. It adds a manufacturing-specific data model and a set of workflows on top of the standard Salesforce platform. The headline capabilities are Sales Agreements (long-term contracts with negotiated volumes and pricing), Account-Based Forecasting and Advanced Account Forecasting (revenue projections rolled up by account, product, and period), Program Based Business (forecasts derived from customer demand signals), Partner Visit Management, and a Service side that covers warranties and the asset service lifecycle. Manufacturers sell differently from transactional B2B companies. Sales cycles run long, revenue is tracked by account rather than by single deal, pricing carries volume commitments, and the relationship continues after the sale through equipment service and renewals. Standard Sales Cloud handles deal-by-deal selling well but does not model committed volumes or rolling forecasts out of the box. Manufacturing Cloud fills that gap. The Sales Agreement object holds the commitment, and the forecasting engine ties sales, operations, and service to one account view.

A Many-to-Many Relationship in Salesforce links two objects so that each record on one side can connect to many records on the other side, and the reverse holds too. Salesforce has no native many-to-many field type. You model the relationship with a junction object, which is a custom object that holds two master-detail relationships, one to each parent. Every row on the junction represents a single pairing between one record on the left and one record on the right. This pattern shows up constantly in real data models. A student takes many courses while a course enrolls many students. A property is shown to many candidates while a candidate views many properties. Standard objects use it too: CampaignMember links contacts and leads to campaigns, and OpportunityContactRole links contacts to opportunities. Building one well means creating the junction, configuring both master-detail fields, adding any attribute fields the pairing needs, and relabeling the related lists on each parent.

Maps and Location Settings is a Salesforce Setup page that controls how the platform turns postal addresses into map coordinates and serves location features across Sales Cloud. It is the front door for geocoding, which adds Latitude, Longitude, and accuracy values to Account, Contact, and Lead records so those records can be plotted, filtered by distance, and matched to geographic territory rules. The page works hand in hand with Data Integration Rules, the engine that actually fills in the coordinates. Turning geocoding on is usually a one-time job. The harder part is the quality of the address data feeding it, because vague or malformed addresses produce coarse, low-confidence coordinates that place a record in the wrong spot.

Marketing Automation in Salesforce is the category of products and tools that run marketing tasks on a schedule or in response to behavior, without a person clicking send each time. It covers email and SMS campaigns, drip and nurture sequences, lead scoring and grading, multi-step customer journeys, and real-time web personalization. Salesforce does not ship one product called Marketing Automation. It ships a family. Marketing Cloud Engagement handles high-volume B2C and B2B messaging and journeys. Marketing Cloud Account Engagement (the product formerly named Pardot) handles B2B lead nurturing tied to CRM. Marketing Cloud Personalization decides what each web visitor sees in real time, and Data Cloud supplies the unified profile underneath. Which products a company runs depends on its business model and budget.

Marketing Cloud Account Engagement (MCAE) is Salesforce's B2B marketing automation product, formerly and widely still known as Pardot. It runs lead nurturing campaigns, lead scoring and grading, email marketing, landing pages, forms, and the marketing-to-sales handoff for business-to-business companies. MCAE sits alongside Sales Cloud and feeds qualified leads into the sales pipeline through automated workflows that score, segment, and route prospects based on behavior and demographic fit. Salesforce rebranded Pardot as Marketing Cloud Account Engagement in 2022 as part of consolidating its marketing-tech under the Marketing Cloud umbrella. The product itself is still the Pardot codebase with the new name. Many practitioners and integration platforms still reference Pardot terminology, so both names appear in documentation, AppExchange listings, and community resources. MCAE is licensed separately from Sales Cloud, with Growth, Plus, Advanced, and Premium editions offering increasing capability. The Salesforce-MCAE integration is bidirectional: marketing actions sync prospect records into Salesforce, and Salesforce data shapes marketing segmentation back into MCAE.

Marketing Cloud Intelligence is the Salesforce marketing analytics platform that pulls data from many marketing and advertising sources into one model, then turns it into cross-channel dashboards and reports. It was the Datorama product before Salesforce acquired the company in 2018 and rebranded it as Marketing Cloud Intelligence in 2022. The platform is built for marketers, with a connector library covering hundreds of ad, email, web, social, and CRM sources. The point of the product is comparison across channels. Each platform's own analytics shows only its slice, so questions like "did paid search or email drive more revenue" need the numbers sitting side by side. Marketing Cloud Intelligence ingests every feed, harmonizes the fields into a shared taxonomy, and lets analysts build leadership-ready views on top. Salesforce has since folded these ideas into a newer offering, Marketing Intelligence in Marketing Cloud Next, but the Datorama-era product is still in market and widely deployed.

Marketing Cloud Personalization is the Salesforce product that lets you visualize, track, and manage customer experiences in real time. It captures behavior across web, mobile app, email, and server-side channels, builds a unified visitor profile, and decides what content, product, or offer to surface to each individual at the moment they interact. The product was acquired as Evergage in 2020, renamed Interaction Studio, then rebranded to Marketing Cloud Personalization in the Winter '23 release. The product sits in the Marketing Cloud family as the real-time activation layer on top of profile data. Marketing Cloud Engagement runs email and journey orchestration, while Personalization makes the moment-of-truth decision when a visitor lands on a page or opens the app. Its recommendation and decisioning engines run on Einstein, and Data Cloud increasingly supplies the unified profile behind both products.

A Marketing User in Salesforce is a user who holds the Marketing User feature license, toggled by a single checkbox on the user record. The license grants the ability to create, edit, and delete campaigns, configure advanced campaign setup, and add campaign members and update their statuses with the Data Import Wizard. It is the gate that separates people who only read campaign data from people who actually build and run campaigns. A feature license sits on top of a user license and entitles someone to a capability the base license does not include, such as Marketing. The checkbox is per user, so two people on the same profile can have different campaign rights. Without the Marketing User license, a user may see campaigns through related lists and reports, but the create and edit buttons stay out of reach even when the profile or a permission set grants object access.

A Mass Action in Salesforce is an action that runs on many records at the same time. Users select rows in a list view, then click a button in the action bar to apply one operation across every selected record. The most common form is a mass quick action, which lets people create or update records in bulk instead of opening each one. Built-in examples include Mass Transfer, Mass Delete, and Mass Email, while admins build custom mass actions on top of quick actions. A mass action saves clicks when the same change applies to a batch of records. Instead of editing fifty leads one at a time, a user selects all fifty and runs a single Update a Record action. Salesforce caps a mass quick action at 100 records per run. The list view shows checkboxes per row plus a Select All option, and the configured actions appear in the bar above the list.

Mass Delete Records is a Salesforce Setup tool that lets an administrator delete records in bulk from a short list of standard objects through a guided wizard. You reach it from Setup by typing "Mass Delete" into Quick Find. The wizard supports Accounts, Leads, Contacts, Activities (Tasks and Events), Cases, Solutions, Products, and Reports. You pick the object, set simple filter criteria, review the matching rows, select the ones to remove, and confirm. Each run deletes up to 250 records at a time. The tool sits in Setup because deleting many records at once is a sensitive action that needs administrator access. A standard user with Delete permission on the object cannot run it. The 250-record cap is a deliberate guardrail, so one pass through the wizard cannot wipe tens of thousands of rows. For higher volumes, custom objects, or complex filters, Data Loader is the usual path instead.

A Mass Transfer Approval Requests tool is a Salesforce Setup page that lets an administrator reassign pending approval requests in bulk from one user to another. It exists for a narrow operational problem. When an approver leaves the company, changes role, or goes on extended leave, the requests sitting in their queue stop moving. Without a bulk option, each pending request has to be reassigned by hand, one record at a time, which does not scale for busy approval workflows. The tool acts only on pending requests. Approved or rejected requests have already completed a step, so their history is fixed and cannot be rewritten through this path. A transfer keeps the rest of the chain intact. The original submitter, the submission date, and any earlier approver actions stay the same, and only the current pending step moves to the new approver. That preserves a clean audit trail for compliance reviews that need to reconstruct who approved what.

A Mass Transfer Records tool is a Salesforce Setup utility that reassigns record ownership in bulk from one user to another. It changes the OwnerId on every matching record in a single pass, so administrators do not edit records one at a time. The tool works on accounts, leads, service contracts, and custom objects, with search criteria that scope the transfer precisely. The wizard lives at Setup, under Mass Transfer Records. It exists because ownership changes tend to arrive in batches. A rep leaves, a territory is redrawn, or a manager redistributes a book of business. For accounts, the transfer can cascade to related opportunities, cases, contacts, notes, attachments, and open activities, which keeps the parent and its children under one owner.

Mass Update Addresses is a Salesforce Setup tool that converts the country and state or province values on existing records to standardized values during the State and Country/Territory Picklists rollout. You reach it from Setup under Data Management, and it works on the address fields of Account, Contact, Lead, and Person Account records. Instead of editing thousands of rows by hand, you map each free-text value (such as USA or U.S.) to a single canonical picklist entry and apply the change in bulk. The tool fits one specific point in the picklist project. After you scan your org and convert your customizations, but before or just after you enable picklists, you still have stored text values that have not been re-saved. Mass Update Addresses brings those records onto the standardized list so reports, list views, and filters group by one consistent value per country and state.

The Master HSM is the air-gapped hardware security module that Salesforce uses to generate the master secret behind Shield Platform Encryption. At the start of each Salesforce release, this dedicated device produces the release-specific master secret. That secret later combines with each customer's tenant secret to derive the AES-256 keys that actually encrypt your data, so the Master HSM sits at the top of the key material chain. The Master HSM is platform infrastructure, not customer-facing configuration. You never see it in Setup, call it through an API, or operate it yourself. Salesforce keeps the device physically separated from its production network and stored in a bank safety deposit box, where only designated security officers can reach it. For Shield architects and compliance auditors, the Master HSM is the answer to a specific question: where does the most sensitive secret material in the encryption system come from, and how is it protected from insider access.

A master picklist in Salesforce is the complete, field-level list of values that a picklist field can hold. It is the single source of truth for that field. Every record type on the object draws from this master list, exposing a subset of its values rather than defining its own separate set. The master picklist is independent of all record types and business processes, which is why a value has to exist in the master before any record type can show it. The idea matters because picklist administration runs on two layers. One layer is the master, which answers the question of what values are possible at all. The second layer is the record type, which answers which of those values a given record type displays. Mixing up the two layers causes a lot of avoidable mistakes. Add a value only to the master and no user sees it. Remove a value from the master and it disappears from every record type that included it.

A Master Secret is the top-level, per-release cryptographic input that Salesforce Shield Platform Encryption uses to derive the keys that protect customer data at rest. It is one of several secrets generated inside the Salesforce Master HSM (a FIPS 140-2 hardware security module) and it never appears in plaintext outside that hardware boundary. The Master Secret does not encrypt your records by itself. Instead, the key derivation function combines it with your organization's tenant secret to produce the data encryption key (DEK) that actually encrypts and decrypts data. In the Shield key model, the Master Secret is the layer that Salesforce controls and customers cannot view, export, or edit. Customers manage the tenant secrets that sit above it through the Setup UI and API. Because the Master Secret feeds every derived key in a release, it is the highest-value cryptographic asset in the system, which is why it lives in air-gapped hardware and is rotated on Salesforce's own release cadence.

A Master Wrapping Key is the cryptographic key in Salesforce Shield Platform Encryption that wraps (encrypts) other key material so it can be stored at rest without exposing the plaintext. "Wrapping" is encryption applied to keys rather than to records. In Shield, data encryption keys are never written to disk, and org-specific key material is always kept wrapped. The wrapping key is what makes that protection possible inside the tiered key architecture. The Master Wrapping Key lives inside a hardware security module (HSM) and never appears in plaintext outside that boundary. It sits above tenant secrets and data encryption keys in the chain of trust. When Shield needs to store a tenant secret or a customer-supplied data encryption key, it wraps that material first. When the platform needs the key for an encrypt or decrypt operation, the HSM unwraps it in memory. This wrapping layer is one reason a storage breach alone does not reveal usable keys.

A master-detail relationship is a parent-child link between two Salesforce objects where the detail (child) record inherits sharing, ownership, and lifecycle from the master (parent). If the master is deleted, every detail record is deleted with it. Detail records cannot exist without a parent, and the parent reference cannot be left blank on creation. That tight coupling is what separates master-detail from a lookup. Lookup is optional and loose. Master-detail is required and structural. The choice locks in roll-up summaries, cascade deletes, ownership inheritance, and the ability to build many-to-many junction objects. Once detail records exist, converting the relationship type gets restrictive, so the decision belongs at the design stage, not after data load.

A Matching Rule is the Salesforce setting that tells the platform how to compare two records and decide whether they are the same. Each rule lists the fields to compare, the method to use on each field (exact or fuzzy), and a matching equation that combines those fields with AND and OR logic. It is the engine inside Duplicate Management that produces the actual match. A Matching Rule does nothing on its own. You pair it with a Duplicate Rule, which decides what happens when a match is found, or you reference it from a Duplicate Job that scans existing records in batch. Salesforce ships standard Matching Rules for Accounts, Person Accounts, Contacts, and Leads. You can build custom rules for any object, including cross-object rules so a Lead can match against existing Contacts.

A Matrix Report in Salesforce is a report format that groups and summarizes records by both rows and columns at the same time. The result is a cross-tab grid: each cell holds an aggregated value (sum, count, average, min, or max) for the records that fall under one row group and one column group together. The classic example is revenue by region by quarter, with regions down the side, quarters across the top, and total Opportunity amount in every cell. Salesforce offers four report formats: tabular, summary, matrix, and joined. Matrix is the one to reach for when a question has two dimensions instead of one. Summary reports group by rows only, so they answer single-dimension questions. Matrix adds the column axis, which lets you compare related totals side by side and spot patterns that a flat list or a single grouping would bury.

A Meeting Request in Salesforce is the action a sales rep takes to propose times and send a calendar invitation to one or more attendees, then track the responses (Accepted, Declined, or Tentative). In the current Salesforce stack, that action is the Insert Availability feature inside Salesforce Inbox, which runs as part of the Outlook Integration and the Gmail Integration. The rep picks open slots from their own calendar, the recipient clicks a time that works, and a calendar event is created and logged against the related Salesforce records. The phrase also covers an older, retiring path. Salesforce for Outlook, the legacy desktop add-in, exposed a New Meeting Request button that sent invites from Outlook into Salesforce. That product is retiring in December 2027, and Salesforce points customers to the Outlook Integration with Inbox plus Einstein Activity Capture instead. So when you read "Meeting Request" today, the modern reading is Insert Availability, and the legacy reading is the Salesforce for Outlook button on its way out.

A Member Status is a value on the CampaignMemberStatus object that records how a Lead or Contact engaged with one specific Campaign. Every Campaign owns its own set of these values, so a CampaignMember on that campaign always carries one status from that set. Out of the box, Salesforce gives each new campaign two statuses, Sent and Responded, and admins can add more to fit the campaign type. A Member Status does more than label a row. Each value can be flagged as a response, and the campaign counts members with a responded status as its Total Responses. That count feeds the response rate, the campaign statistics on the record, and the Campaign Influence attribution that credits closed revenue back to marketing. Configure the statuses well and the reporting is meaningful. Configure them poorly and every downstream number is off.

A merge field is a placeholder that Salesforce replaces with real record data when a template, formula, or page is processed. You write the placeholder once, and the platform swaps in the live value at the moment the surface runs. A classic example is {!Contact.FirstName} in an email, which becomes Maria or David depending on who receives the message. The merge field is how personalization works across nearly every template-driven feature in Salesforce. Email templates, formula fields, validation rules, Visualforce pages, approval emails, and letterheads all read field values through merge fields. Almost every standard and custom field is available as one. The exact wrapper changes by surface, but the idea stays the same: name a field, and Salesforce fills it in.

A Message Channel is a Salesforce metadata record that defines a typed publish-and-subscribe channel for Lightning Message Service (LMS). Components publish a message on the channel, and any component subscribed to that same channel receives it. The channel itself is the named contract that both sides agree on. LMS lets components talk to each other across the DOM on a single Lightning page, even when they sit in different component trees and share no parent. It works across Lightning Web Components, Aura components, and Visualforce pages embedded in the same page. The Message Channel is the piece you declare and deploy. The publish and subscribe functions are the runtime API that moves messages through it.

A Chatter Message is a private message sent inside Chatter, Salesforce's built-in collaboration tool. It lets users hold one-on-one or small-group conversations that stay off the public feed. Each message is stored on the ChatterMessage standard object, available since API version 23.0, and grouped into a thread through the related ChatterConversation object. Chatter Messages run alongside the public feed but use a different visibility model. Public posts and comments live on FeedItem and FeedComment and respect record sharing and group membership. Private messages are visible only to the people on the conversation. The feature is still current and shipping, though Salesforce now points most active collaboration toward Slack. Many orgs keep Chatter Messages for quick internal notes and for Experience Cloud sites where Slack is not in play.

Messaging in Salesforce refers to the suite of Service Cloud features for handling asynchronous customer conversations across SMS, WhatsApp, Facebook Messenger, Apple Messages for Business, Google Business Messages, and web messaging widgets. It is the modern evolution beyond Live Chat (which is real-time only) and email-to-case (which lacks the conversational pattern). Messaging fits the way customers actually expect to interact with companies in 2026: send a message from a channel they already use, get a response when convenient, continue the conversation across hours or days without losing context. Messaging in Salesforce runs through several integrated products. Messaging for In-App and Web provides embedded chat widgets in mobile apps and websites with conversational continuity. Messaging for SMS handles inbound and outbound text messages. Messaging for Social handles WhatsApp Business, Facebook Messenger, Instagram Direct, and similar consumer messaging platforms. Each channel routes through Omni-Channel for assignment to the right agent, integrates with Einstein Bots for Tier 1 automation, and surfaces in the Service Console as the agent work surface. Salesforce Messaging is licensed separately from base Service Cloud, with consumption-based pricing for outbound messages on most channels.

A Messaging Component is a reusable, configurable block of structured content that Salesforce sends inside a Messaging for In-App and Web conversation. Instead of plain text, a component can be a tappable button set, a selectable list, a date and time picker, a secure form, an enhanced link, a payment request, or an authentication prompt. Salesforce calls these Interactive Messaging Components, and an admin builds them once in the Messaging Component Builder, then reuses them across enhanced channels. Each component is rendered into the format that the customer's channel understands. The same List Picker shows one way in Enhanced Chat and another way on Enhanced WhatsApp, because Salesforce maps the component to a channel-native format behind the scenes. Components can be sent by a human agent from the conversation window, returned automatically by a flow or Einstein Bot, or pushed through the Messaging API, so the rich experience does not depend on per-channel rendering code.

Messaging for In-App is the Salesforce Service Cloud feature that lets customers message support agents and bots from inside a company's own iOS or Android app. The company adds a Salesforce-supplied SDK to its mobile app, places a chat entry point in the interface, and incoming messages route through Service Cloud to an agent in the Service Console. The conversation lives inside the app, so the customer never leaves for a browser or email. In June 2025, Salesforce began renaming the combined Messaging for In-App and Web product to Enhanced Chat. The In-App portion is also documented as Enhanced In-App Chat. It is the modern replacement for Legacy Chat (the older Live Agent based chat), which Salesforce is retiring on February 14, 2026. Messaging for In-App supports asynchronous conversations, so a customer can send a message, close the app, and pick the thread back up hours later.

Messaging for Web is the Service Cloud channel that lets a customer message a support agent through a chat widget embedded on a website. The visitor clicks a chat button, a window opens, and each message travels to Salesforce as a Messaging Session that an agent works inside the Service Console. Salesforce now markets this channel, together with its mobile sibling, under the name Enhanced Chat. A defining trait is asynchronous conversation. The customer can close the browser tab, return hours later, and find the thread waiting with the agent's reply. That behavior, plus native bot handoff and Omni-Channel routing, separates Messaging for Web from the older Legacy Chat (Live Agent) product, which Salesforce retired on February 14, 2026. New websites should deploy Messaging for Web, not the retired chat.

Messaging Settings is the Salesforce Setup page where administrators create and manage the channels behind Messaging for In-App and Web, Salesforce's customer messaging product in Service Cloud. From this one page you add a channel, pick its type (a web deployment, an in-app mobile deployment, or a third-party channel such as WhatsApp or Apple Messages for Business), give it a developer name, and connect it to the routing and automation that move conversations to the right place. A channel created here is the link between a customer touchpoint and the rest of your org. It ties an inbound conversation to an Omni-Channel queue or flow, to an optional bot, and to the standard objects that record the chat (Messaging Session and Conversation Entry). Because every live conversation runs through these settings, a change made here can reach real customers immediately, which is why the page sits near the center of any messaging rollout.

Metadata in Salesforce is the data that describes the org's configuration, customizations, and structure rather than the business records the org operates on. It includes definitions of objects, fields, page layouts, validation rules, Apex classes, Flows, Permission Sets, Profiles, Sharing Rules, Reports, Dashboards, and every other component that makes up the Salesforce environment. Metadata is what gets deployed between orgs through Change Sets, Salesforce DX, or DevOps Center, and it is the foundation of source-driven development on the platform. Understanding the metadata concept is essential to any non-trivial Salesforce work because every customization the admin or developer makes produces or modifies metadata. When you create a custom field, you create CustomField metadata. When you write Apex code, you create ApexClass metadata. When you build a Flow, you create Flow metadata. The Salesforce Metadata API treats all of these as instances of metadata types, with a unified deploy and retrieve interface. The shift from clicks-only configuration to source-driven development through metadata is one of the most significant Salesforce platform evolutions of the past decade.

A metadata component in Salesforce is a single configurable element of an org's setup, represented as an instance of a metadata type such as ApexClass, CustomObject, Flow, or PermissionSet. Components are not built on sObjects the way records are. Each one extends the Metadata base class and is identified by a fullName, so the platform treats an Apex class, a custom field, and a validation rule as the same kind of thing: a unit of configuration that tooling can read and write. Every change an admin or developer makes touches one or more metadata components. The Metadata API is the programmatic interface for retrieving and deploying them, and the Salesforce CLI, DevOps Center, change sets, and packaging all sit on top of it. Knowing which components a change requires is the basis of any reliable deployment.

A Metadata Coverage Report is the Salesforce-published reference that shows which metadata types are supported by each deployment and packaging channel. The channels it tracks include Metadata API, Source Tracking, Unlocked Packaging, 2GP Managed Packaging, 1GP Managed Packaging, Change Sets, and Apex Metadata API. For every metadata type, the report records whether that channel supports it, supports it partially, or does not support it at all. The report lives at developer.salesforce.com/docs/metadata-coverage and refreshes with each Salesforce release. It is the practical answer to a recurring question on any migration: can this configuration move between orgs, and through which mechanism? Salesforce calls it the source of truth for metadata coverage. If a component type has no support in your chosen channel, you plan to configure it by hand in each target org instead of carrying it in a deployment.

A Metadata Type in Salesforce is a category of platform configuration that the Metadata API understands as a single unit of deployable, retrievable, and version-controlled material. Examples include CustomObject, ApexClass, Layout, Flow, PermissionSet, ValidationRule, Profile, EmailTemplate, and well over 200 others as of recent releases. Each metadata type defines the shape of its data, the operations the Metadata API supports on it, and the rules for how it interacts with other types during deploy and retrieve. The concept of a metadata type is fundamental to every DevOps workflow on the Salesforce platform. Every change set, every SFDX deploy, every metadata API package.xml manifest, and every source-tracked sandbox sync references metadata by type and full name. Understanding what each type contains, which types depend on others, and which types have idiosyncratic deploy behavior is the difference between a smooth release pipeline and a chronic source of mid-deploy failures.

The Metadata WSDL is the SOAP interface definition for the Salesforce Metadata API. WSDL stands for Web Service Description Language, and the file describes every operation, request shape, and response shape the SOAP-based Metadata API exposes. You download it from Salesforce Setup and import it into a development platform like Java or .NET, which reads the file and generates strongly typed stub classes. Your code then calls Metadata API operations through those stubs instead of hand-building raw SOAP envelopes. The Metadata API lets you read and change the configuration of an org as XML, rather than the records that live inside it. Through the Metadata WSDL you can retrieve and deploy components such as custom objects, page layouts, Apex classes, and permission sets. The SOAP-based interface was the original way to reach the Metadata API, and it still works today. Many continuous integration tools use it under the covers, though most everyday teams now reach the same API through the Salesforce CLI.

Metadata-Driven Development is the Salesforce design philosophy where you build and customize applications by editing metadata (declarative definitions of structure and behavior) instead of writing code for every change. Custom objects, fields, validation rules, page layouts, permission sets, flows, Lightning pages, and even Apex classes all live as metadata in the org. The platform reads that metadata at runtime to render the configured experience for each user. This model is what sets Salesforce apart from code-first platforms. When you create a custom field, Salesforce does not build a new database table or compile anything. It stores a metadata definition and uses it at runtime to materialize the field. The same idea runs through multitenancy, packaging, and the three-releases-a-year cadence, so the metadata layer is the foundation that the rest of the platform sits on.

Migrate to Flow is the Salesforce-supplied Setup tool that converts legacy Workflow Rules and Process Builder processes into record-triggered flows in Flow Builder. It reads a source automation, generates an equivalent flow, and lets an admin test the result before switching the live automation over. The tool exists because Salesforce stopped supporting Workflow Rules and Process Builder on December 31, 2025, and Flow is now the single supported point-and-click automation engine. You reach it from Setup by typing "Migrate to Flow" in Quick Find, or from the Workflow Rules page by clicking "Migrate your workflow rules to flows." The tool lists your existing rules and processes, converts the ones you select, and produces a flow you can inspect in Flow Builder. Conversion is assisted, not blind: you review the generated flow, fix anything the tool could not translate, then deactivate the old automation and activate the new flow.

A migration in Salesforce is the planned movement of something from a source to a target. That something can be records, configuration metadata, an entire org, a feature, or a set of user licenses. The word is overloaded, so the first job in any migration conversation is to confirm which kind is meant. The five common types are data migration (records between systems or environments), metadata migration (configuration between orgs), platform migration (an org moving to Hyperforce), product migration (replacing one feature with a newer one), and license migration (moving users between license types). Each type has its own tools and risks, but all follow the same arc: inventory the source, design the target, test in a safe environment, then cut over with a rollback plan ready.

A Milestone in Salesforce Service Cloud is the unit of SLA tracking inside an Entitlement Process. Each Milestone represents one measurable target on a case: First Response within 1 hour, Resolution within 24 hours, Customer Update every 4 hours. The platform tracks elapsed time against the milestone's target using a Business Hours profile, fires Time Trigger actions at configurable offsets (warning, violation, success), and records the outcome on the CaseMilestone object for reporting. Milestones are how a written SLA becomes operational automation. Milestones are defined twice in the data model. First as MilestoneType records, which are reusable definitions of what the milestone represents (First Response, Resolution). Second as instances attached to Entitlement Processes through EntitlementProcessMilestone records, which add the specific timing (Target Time = 60 minutes), Business Hours, and Time Trigger actions for this particular process. The two-level model lets one MilestoneType be reused across multiple processes with different timings: a First Response Milestone Type might be 1 hour on the Platinum process and 4 hours on the Gold process.

Milestone Actions are the time-based automated actions Salesforce fires at predefined points in a Case's milestone lifecycle. Each Milestone (First Response, Resolution, Escalation) has associated actions that run before the milestone target time, when it is reached, or after it has been violated. The actions are flows, email alerts, field updates, outbound messages, or task creation. Together they turn a passive SLA target into active operational signal: send the rep a warning 30 minutes before First Response is due, escalate to a manager if Resolution is missed, fire a custom flow when a milestone completes. Milestone Actions live on the Entitlement Process metadata, configured under Setup, Service, Entitlement Processes, in the Milestones section. Each milestone has three action types: Success Actions (fire when the milestone is completed in time), Warning Actions (fire at a configurable time before the target), and Violation Actions (fire when the target time elapses without completion). The trio is what makes SLA enforcement actually enforceable; without actions, milestones are just decorative date fields on the Case.

A Milestone Type is the Salesforce metadata that defines how a specific milestone (First Response, Resolution, Escalation, custom) is detected as complete on a Case. Each Milestone Type specifies which field change on the Case marks completion, what business rules constitute compliance, and which Milestone instances inherit from this type across multiple Entitlement Processes. Milestone Types are the reusable building blocks; individual Milestones in an Entitlement Process pick a Milestone Type and inherit its completion detection rules. Milestone Types live under Setup, Service Setup, Milestone Types. The standard set ships with First Response (driven by case field changes that indicate the rep responded) and Resolution (driven by Case.Status changing to Closed). Custom Milestone Types support org-specific definitions: a Custom Field Validation milestone, a Customer Approval milestone, an Internal Quality Review milestone. The separation between Milestone Type (definition) and Milestone Instance (usage on a process) is what lets multiple Entitlement Processes share consistent completion detection logic.

A Mini Page Layout is a Salesforce Classic configuration that controls the small subset of fields and related lists shown in compact surfaces like hover details, calendar event overlays, and the Agent Console mini view. It is a trimmed view of an object's full Page Layout. A mini layout inherits record type associations, profile associations, related lists, fields, and field access settings from its parent Page Layout, then lets an admin pick which of those fields and lists actually appear in the condensed display. Mini Page Layouts are an older, Classic-only concept. Lightning Experience does not use them. The Compact Layout took over the same job in Lightning, driving the Highlights Panel at the top of a record, the hover lookup card, the activity timeline, search previews, and the Salesforce mobile app from one definition. Orgs on Lightning configure Compact Layouts instead, so a Mini Page Layout in a Lightning org is effectively dead metadata.

A Mini View is the right-hand frame of the Salesforce Classic Agent Console, a panel that showed records related to whatever record sat in the main detail view. When an agent opened a case in the center of the Console, the Mini View on the right listed the linked Account, Contact, or Asset so the agent could see context without leaving the page. The fields and related lists that appeared there came from a separate configuration called the Mini Page Layout, which an administrator set up per object. This is a legacy concept. The Agent Console it lived inside was retired in the Summer '20 release, and the term applies only to Salesforce Classic. Mini Page Layouts also drove hover details and the event detail overlays in Classic, so the Mini View was one of three things the same configuration controlled. Lightning Experience does not have a Mini View. The Lightning Service Console reproduces the same idea with a Highlights Panel, related-record components, and the utility bar, all assembled in the Lightning App Builder. Treat Mini View as background you need when reading old documentation or planning a Classic-to-Lightning migration.

Mobile Builder for the Seller-Focused Experience is a point-and-click admin tool in Salesforce that customizes how the Seller-Focused Mobile Experience looks and behaves. It lets you add native pages for custom objects and reshape the record home page layouts that sellers see inside the Salesforce mobile app on iPhone and Android. The Seller-Focused Mobile Experience itself is the native interface that Sales Cloud reps use to track accounts, contacts, leads, opportunities, events, and tasks while away from a desk. That experience is enabled by default and works without admin setup. Mobile Builder is the layer on top: it gives admins control over which components appear, how they are ordered, and which quick actions a seller can tap. The builder is enabled by default too, and admins publish a configuration to push their changes to mobile users.

A Mobile Configuration is a legacy Salesforce setup record from the Salesforce Classic Mobile app. An administrator built one to control exactly which objects and records were pushed to, and kept synced on, a user's mobile device. Each configuration defined a data set (the object filters and record limits that decided what downloaded) and was then assigned to specific users and profiles. This feature is retired. Salesforce Classic Mobile was switched off on December 1, 2017, which took named Mobile Configurations with it. The modern Salesforce Mobile App does not use admin-defined configurations at all. It decides offline data with an automatic, predictive model instead. The term still appears in older orgs, certification study guides, and archived help pages, so it is worth knowing what it was and what now does its job.

Mobile Studio is the Salesforce Marketing Cloud application that handles mobile marketing campaigns across SMS, MMS, push notifications, and group messaging channels. Marketers use Mobile Studio to design messages, target audiences through segmentation, schedule send times, personalize content with subscriber attributes, and measure engagement through opens, clicks, and downstream conversions. The app sits alongside Email Studio, Journey Builder, Social Studio, and Advertising Studio inside the broader Marketing Cloud portfolio. Mobile Studio combines several legacy products that Salesforce acquired and merged over time: MobileConnect (the original SMS and MMS platform), MobilePush (the push notification platform), and GroupConnect (the messaging app integration for WhatsApp, Facebook Messenger, and similar channels). The unified Mobile Studio interface exposes all three through a common designer, segmentation, and analytics layer. Mobile is one of the highest-engagement channels for marketing communication; open rates on SMS routinely exceed 90 percent compared to 20-30 percent for email.

Model Builder is Salesforce's tool for managing the large language models that power Einstein generative AI features. It is the layer where admins choose which LLMs Prompt Builder and Agentforce use, configure connections to third-party model providers, monitor model usage, and bring custom models into the platform. Model Builder exists because the right LLM for a given use case varies: Salesforce's own models work for many cases, OpenAI or Anthropic models work for others, and enterprise customers sometimes need to bring their own fine-tuned models for specific domains. The product supports several model sources. Salesforce-hosted models include xGen (the Salesforce-trained foundation models) and other native options. Trust Layer connections expose third-party LLMs (OpenAI GPT-4, Anthropic Claude, Google Gemini, AWS Bedrock-hosted models) through zero-data-retention agreements that protect Salesforce data from being used for model training. Custom Model Connections let enterprises register their own hosted LLMs as endpoints Salesforce can call. Each model has performance, cost, and quality trade-offs that admins can compare and choose based on the use case. Model Builder is the configuration center for these decisions.

A Module in Salesforce most often means a Trailhead module, the basic learning unit on Trailhead, the company's free online training platform. Each module is a self-contained lesson on one topic, made of a few short units of reading plus a quiz or a hands-on challenge. Completing a module earns a badge and points that add up on your Trailblazer profile. The word shows up in a few other places too. JavaScript modules appear in Lightning Web Components, MuleSoft has connector modules in Anypoint, and Heroku has buildpack modules. Within everyday Salesforce learning vocabulary, though, the Trailhead module is the meaning people reach for first.

Monitor Workflow Services is the Setup page in Salesforce Industries that tracks the runs of Data Processing Engine definitions and Batch Management jobs. Each run produces a batch job record, and the page lets you watch that record while the run is in progress and review it after the run ends. You reach it from Setup by searching for Monitor Workflow Services in the Quick Find box. The page is the single place to confirm whether a definition run or batch job actually finished, how many records it processed, and which records it could not. It groups each run into a Details view, a Tasks view that lists the parts the run was split into, and a Failed Records view. Access is limited to users with the System Administrator profile, since the data exposed here spans the whole org.

A Mule application is the deployable unit of integration code that runs on the MuleSoft Anypoint Platform. It reads data from internal or external sources, transforms it, and sends the processed output to other systems. A single application is built as a project of XML configuration files, flows, connectors, and DataWeave scripts, then packaged into one JAR artifact that a Mule runtime engine executes. Mule applications are how MuleSoft (a Salesforce company since 2018) connects Salesforce to the rest of an organization. One application might sync Accounts between Salesforce and an ERP, expose Salesforce data as a REST API for a partner, or react to a platform event and update a back-end system. Because MuleSoft is part of Salesforce, these applications are a common answer when a Salesforce integration outgrows simpler tools.

MuleSoft is the integration platform Salesforce acquired in 2018 for $6.5 billion. It is the enterprise-grade middleware layer that connects Salesforce to non-Salesforce systems (ERP, financial, supply chain, custom databases, third-party SaaS) and routes data between any combination of systems. MuleSoft's core product is the Anypoint Platform, a cloud or self-hosted runtime that runs integration "flows" built in Anypoint Studio (a desktop IDE) or in Anypoint Code Builder (a VS Code-based modern alternative). MuleSoft sits one layer above Salesforce Connect, External Services, and Apex callouts in the integration architecture. Those are point-to-point connections from Salesforce to one external system; MuleSoft is the integration broker that orchestrates many systems, applies enterprise governance (security, monitoring, throttling), and exposes reusable APIs that any consumer can call. For Salesforce orgs at the enterprise tier, MuleSoft is typically the right answer when you have more than three or four non-trivial integrations to maintain. For small orgs with one or two integrations, MuleSoft is overkill.

A MuleSoft Anypoint Platform is the unified integration platform that MuleSoft, a Salesforce company, provides for designing, building, deploying, and managing APIs and integrations across an organization's systems. It bundles a developer tooling layer, a runtime layer, a shared catalog of reusable assets, and a management and monitoring layer into one product. The goal is to replace brittle point-to-point connections with reusable, governed APIs that connect apps, data, and devices. Teams use Anypoint Platform to expose back-end systems as APIs, orchestrate data across them, and operate everything from a single control center. Salesforce acquired MuleSoft in 2018, and Anypoint Platform is now its strategic platform for connecting Salesforce to ERP, billing, marketing, and other back-end systems.

MuleSoft Direct is a Salesforce Setup feature that provides pre-built, no-code integrations between Salesforce and popular enterprise applications, packaged so that admins can connect Salesforce to systems like SAP, Workday, NetSuite, Oracle EBS, Microsoft Dynamics, and ServiceNow through guided setup wizards rather than building integrations from scratch. The feature sits on top of the MuleSoft Anypoint Platform but abstracts away most of the integration complexity, presenting the admin with a configuration wizard rather than the underlying MuleSoft tooling. The product was introduced to address the gap between customers who needed enterprise system integration and the high cost or complexity of full MuleSoft adoption. Many customers who would benefit from MuleSoft never adopted it because the platform required dedicated integration engineering capacity. MuleSoft Direct collapses the adoption barrier by shipping a curated set of integration patterns that handle the most common scenarios with admin-friendly tooling. The trade-off is flexibility: MuleSoft Direct works for the supported patterns, not for arbitrary custom integrations.

A MuleSoft integration is a connection between Salesforce and another system, built and run on MuleSoft Anypoint Platform. The platform is Salesforce's enterprise integration product. Teams use it to move and reshape data between Salesforce and systems like SAP, Oracle, Workday, NetSuite, databases, and partner APIs. Each integration is packaged as one or more Mule applications. A Mule application reads from a source, transforms the payload, and writes to a target, with the connection logic, error handling, and security held in one deployable unit. Salesforce positions MuleSoft as its strategic platform for connecting CRM, Data 360, and Agentforce to the rest of a company's systems.

MuleSoft Observability is the monitoring and analytics layer that surfaces health, performance, and usage metrics for MuleSoft-managed integrations across the Salesforce ecosystem. It consolidates dashboards covering API call volumes, error rates, latency percentiles, throughput, and policy enforcement, giving the integration team a unified view of how their MuleSoft Anypoint Platform deployments are behaving. Inside Salesforce specifically, MuleSoft Observability appears as a Setup area that surfaces the relevant subset of metrics tied to integrations involving the org. The feature matters because MuleSoft integrations sit at the heart of most modern Salesforce architectures. When an integration starts failing or slowing down, the result is broken business processes: order data not flowing from the ERP into Salesforce, inventory updates lagging behind, leads stuck in queue waiting for enrichment. MuleSoft Observability gives the team early warning signals (rising error rates, growing latency, dropping throughput) before the business notices the impact. Mature integration teams build dashboards and alerts on top of the Observability data to drive proactive incident response.

A Multi-Person Event in Salesforce is a calendar Event that has more than one person attached to it, beyond just the organizer who owns it. Each invited person, whether an internal user, a contact, or a lead, gets stored on a related EventRelation record. That child record holds the invitee's identity and tracks whether they accepted, declined, or have not yet responded. The parent Event still carries the subject, the start and end times, the location, and the description. This is how Salesforce represents real meetings with several attendees, such as a sales rep sitting down with a buying committee, an account team kickoff, or a quarterly business review with a client. The model is built on the standard Event and EventRelation objects, so the attendee list is queryable, reportable, and syncable. Email and calendar integrations like Einstein Activity Capture can also create these events automatically when a user schedules a multi-attendee meeting in Outlook or Gmail, pulling the attendee list and response data back into Salesforce.

A multi-select picklist is a Salesforce field that lets users select multiple values from a controlled list and stores them as a single semicolon-delimited string. Unlike a regular picklist, which returns exactly one value, a multi-select picklist can hold any number of values up to the field's character limit and the platform's maximum of 500 values per selection. The structure is convenient at the UI level but uncomfortable nearly everywhere else. Reports cannot aggregate cleanly across multi-select values. Validation rules and Apex must parse the delimited string to check for individual values. SOQL supports the INCLUDES and EXCLUDES operators but with limited filter behavior. For these reasons, multi-select picklists work for casual tagging where reporting matters less, and they fail when the values need clean cross-tab reporting, programmatic logic, or relationship-style traversal. In those cases, a junction object or a set of boolean checkbox fields usually serves better.

Multitenancy is the architecture that runs many customer organizations (tenants) on the same shared infrastructure. The same servers, the same database, and the same application code serve every tenant at once. Each tenant's data stays logically isolated from every other tenant, while the underlying compute and storage are pooled. Salesforce describes its platform as multitenant and metadata-driven, and it has been built this way since the company's founding in 1999. A single Salesforce instance uses one shared multitenant database with a single schema. A multitenant kernel reads metadata and data at runtime to serve each tenant a customized application. Multitenancy is the reason Salesforce can ship the same release to thousands of customers on one schedule. It also explains governor limits, the metadata-driven customization model, and why every customer runs an identical code base.

MVC (Model-View-Controller) is a software architecture pattern that splits an application into three connected parts: the Model (data and business logic), the View (what the user sees), and the Controller (the layer that wires the two together). The point of the split is separation of concerns. A change to how data is displayed should not force a change to the business rules, and a change to the rules should not force a redesign of the screen. On Salesforce, MVC is the design pattern behind Visualforce. The Salesforce documentation states it plainly: Visualforce uses the traditional model-view-controller paradigm. A Visualforce page is the View, an Apex controller is the Controller, and the database (sObjects such as Account and Contact, plus any Apex that reads or writes them) is the Model. The same separation carries forward into Lightning Web Components and Aura, where the vocabulary changes but the layering does not.

My Domain is the Salesforce feature that gives each org its own branded subdomain (acme.my.salesforce.com instead of na123.salesforce.com). It became a mandatory feature for every Salesforce org in 2022; orgs without My Domain configured have one auto-assigned by Salesforce during the rollout. My Domain is foundational to single sign-on, Lightning Web Components security, Lightning Components from packages, and most modern Salesforce identity features that require a stable subdomain. Beyond branding, My Domain enables capabilities that depend on a predictable URL. SSO providers (Okta, Azure AD, Google Workspace) require a My Domain to configure SAML or OAuth flows. Lightning Web Components and Aura components served by Lightning Locker use the My Domain as their security origin. Mobile apps and integrations that need to deep-link into Salesforce records use the My Domain URL pattern. Activating My Domain takes about 24 hours from request to live, and the activation is the kind of change that disrupts every active session in the org.

My Settings is the per-user area in Salesforce where an individual user configures their own personal preferences. It covers things like display language, locale, time zone, email signature, calendar defaults, notification preferences, password, and identity verification methods. In Lightning Experience you reach it by clicking your profile photo (the avatar) in the top-right corner and choosing Settings. The page opens a categorized left menu, with a Quick Find box at the top so you can jump to a setting by typing the first few letters of its name. My Settings is the user-facing counterpart to Setup. Setup holds org-wide configuration that administrators control. My Settings holds per-user preferences that each user controls for themselves, within the limits the admin allows. The org default locale is set in Setup, while a user's personal locale override lives in My Settings. Some preferences carry admin enforcement, so a user cannot use My Settings to disable mandatory multi-factor authentication or relax a password policy.