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.

Mail Merge in Salesforce is the feature that generates personalized documents (letters, contracts, proposals, invoices) by merging Salesforce record data into a Microsoft Word document template. The standard Salesforce Mail Merge feature dates from the early Salesforce Classic era and supports generating one document per record by replacing merge fields in the template with field values from the chosen Salesforce record. Users initiate Mail Merge from the record page or from a list view; the platform downloads a generated Word document or pushes it to the customer''s file storage. Standard Salesforce Mail Merge has limited adoption in modern Lightning Experience orgs because it requires the Salesforce Word add-in (a desktop Word plug-in) and produces only Word format. Most enterprises that need document-generation use Conga Composer, Docusign Gen, S-Docs, or other AppExchange document-generation packages, which support richer templates, multiple formats (PDF, Excel), and more sophisticated merge logic. The Mail Merge feature persists in Salesforce for backward compatibility but is rarely the right choice for new deployments.

Mail Merge Templates are the document templates stored in Salesforce that drive the native Mail Merge feature. Each template is a Microsoft Word document containing merge fields (like {!Account.Name} or {!Contact.FirstName}) that the platform replaces with Salesforce record data at generation time. Templates live as records on the legacy Mail Merge Template object accessible from Setup, Communication Templates, Mail Merge Templates. Admins upload Word documents prepared with the appropriate merge syntax; users reference the templates from records to generate personalized documents. Mail Merge Templates inherit all the limitations of the legacy Mail Merge feature: Word format only, requires the Salesforce Word add-in for editing, and a clumsy template-management UI. Most modern orgs use Lightning Email Templates for email-style merge content and AppExchange document-generation tools (Conga Composer, Docusign Gen, S-Docs) for richer document templates. The Mail Merge Template feature persists for backward compatibility but is rarely the right choice for new template development.

A Maintenance Plan in Salesforce Field Service is a record that defines a recurring schedule for preventive maintenance work on installed equipment. It links an Installed Product (or Asset) to a Work Type and a maintenance cadence (every 90 days, every 6 months, every year), and the platform auto-generates Maintenance Work Orders on the schedule. Field Service technicians complete the Work Orders, the platform records the completion, and the next scheduled Work Order generates on the configured interval. Maintenance Plans are the backbone of preventive-maintenance service offerings: HVAC systems requiring quarterly tune-ups, fire-safety equipment requiring annual inspection, industrial machinery requiring biannual service. Without a Maintenance Plan, field service teams rely on ad-hoc reminders or manual spreadsheets to track when equipment is due for service; with one, the platform generates the work automatically. The MaintenancePlan standard object lives in Salesforce Field Service and integrates with Installed Product, Work Order, Service Appointment, and Service Resource for end-to-end preventive-maintenance workflow.

A Major Release in Salesforce is one of the three platform-wide releases shipped per year: Spring, Summer, and Winter. Each major release introduces new features across every Salesforce product, deprecates older capabilities, ships breaking changes flagged by critical updates, and refreshes the underlying platform infrastructure. The releases are global; every customer org receives the same version on a staggered rollout schedule managed by Salesforce''s Customer Trust team. Salesforce publishes detailed release notes for each major release weeks in advance, and customers use the preview window to test their orgs against the new version before production migration. The Major Release cycle is the operational rhythm of every Salesforce org. Admins read release notes, identify features that might benefit their org, test in a Preview-released sandbox, train users on new capabilities, and update documentation. Developers handle deprecated APIs, migrate code that depends on retired features, and adopt new platform capabilities. The three-major-releases-per-year cadence is faster than most enterprise software but slower than consumer apps; it produces a steady rhythm of platform evolution that customers can plan around.

Manage Connected Apps is the Salesforce Setup page that administers OAuth integrations: third-party applications and internal integrations that authenticate to the org through OAuth 2.0 or related protocols. Each Connected App is a configuration record representing an integration's trust relationship with Salesforce, including the consumer key, consumer secret, allowed OAuth scopes, callback URL, and any IP restrictions. The page lets administrators install, configure, monitor, and revoke Connected Apps across the org. Two activities dominate the page. Installing a Connected App receives metadata from a third-party vendor and configures local policies (which users can use it, what scopes are allowed, whether refresh tokens persist). Monitoring views show active OAuth sessions and recently revoked tokens, supporting incident response when an integration is compromised. The administrative discipline around Manage Connected Apps is one of the most important security boundaries in any Salesforce org: every Connected App is a potential pathway for external access, and stale or over-permissioned apps are a security risk that accumulates silently.

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 Salesforce Setup area where customers view and adjust their Salesforce subscription details: the products they own, the user license counts, the storage allocation, and the contract renewal information. The page surfaces what the customer has paid for and what is provisioned, providing a consolidated view that historically required a call to the account team. For self-service operations like adding licenses or upgrading editions, the area integrates with the Salesforce account commerce flow; for complex changes, it points to the account team. The capability is part of Salesforce's broader push to give customers more visibility into their own subscription state without requiring account-team involvement for every operation. Customers in larger contracts still work with their account team for complex commercial changes, but routine operations (adding a few licenses for new hires, viewing renewal dates, downloading invoices) are increasingly self-serviceable. The exact features available depend on the customer's contract type and the products they own; not every org sees every option.

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 (typically named package.xml or destructiveChanges.xml) that lists the metadata components to retrieve from or deploy to a Salesforce org. The Salesforce Metadata API uses manifest files as the request specification: the file declares which metadata types and which named members within those types are part of the operation. The Salesforce CLI''s sf project retrieve and sf project deploy commands consume manifests to scope what metadata moves between local projects and Salesforce orgs. Manifest files are the foundation of Salesforce metadata deployment outside source-tracking-enabled environments. Production org deployments, change sets, managed-package builds, and CI/CD pipelines all reference manifests to control exactly what metadata gets touched. The package.xml format dates from the early 2010s when the Metadata API was the primary deployment mechanism; modern source-tracking workflows handle simple cases without manifests, but every non-trivial deployment falls back to manifest-driven control eventually.

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 Industries Cloud product built for manufacturers, distributors, and industrial companies. It layers manufacturing-specific data model and workflows on top of the standard Sales Cloud platform: Sales Agreement (the long-term contract with negotiated volumes and pricing), Account-Based Forecasting (revenue projections by account and period), Asset Lifecycle Management (track installed equipment through service and renewal), Demand Planning (rolling-window forecast adjustments), and Manufacturing Cloud-specific Lightning components for the deal desk and operations teams. Manufacturing companies have unique sales motion characteristics: long sales cycles with engineering involvement, account-based revenue rather than per-deal revenue, complex pricing with volume commitments, and post-sale equipment service that extends the customer relationship. Standard Sales Cloud handles transactional B2B selling well but misses the structured commitment-tracking and rolling-forecast patterns manufacturing demands. Manufacturing Cloud fills the gap with the Sales Agreement object and a tightly-integrated revenue-tracking model that connects sales, operations, and customer success around a single account view.

A Many-to-Many Relationship in Salesforce links two objects where each record on one side can be associated with many records on the other side, and vice versa. Salesforce does not support native many-to-many fields; the implementation uses a Junction Object: a custom object with two master-detail lookups, one to each parent. The junction object stores one row per parent-to-parent association. The classic example is Account-to-Contact via AccountContactRelation (a standard junction object), letting one Contact relate to multiple Accounts and one Account to multiple Contacts. Many-to-Many relationships appear constantly in real-world data models. A Student takes multiple Courses, a Course enrolls multiple Students. A Contract has multiple Products, a Product appears in multiple Contracts. A Campaign reaches multiple Contacts, a Contact participates in multiple Campaigns (via CampaignMember). Building these correctly requires defining the junction object, configuring both master-detail relationships, optionally adding custom fields to the junction (Relationship Role, Start Date, Status), and configuring page layouts and related lists for both parents.

Maps and Location Settings is the Salesforce Setup page that controls how the platform handles geocoded address fields, route planning, location-based filtering, and the integration with mapping providers used by Sales Cloud features like Maps and Territory Management. The page enables geocoding for standard address fields (Account billing/shipping, Contact mailing, Lead address) so that records gain Latitude and Longitude values used by territory rules, mapping visualizations, and proximity filters. Geocoding runs as a background process; after enabling, the platform processes existing records and continues geocoding new ones automatically. The settings also configure which mapping provider serves the geocoding and visualization layer (typically Google Maps for most orgs) and any region-specific defaults. The accuracy and coverage of geocoding depends on the input addresses; poorly formatted addresses produce low-confidence geocodes that may not place records in the expected location. Most orgs enable geocoding once and leave the settings; the operational concern is the quality of the underlying address data, not the configuration.

Marketing Automation in the Salesforce context refers to the platform-and-tool category that automates marketing tasks: email campaigns, drip sequences, lead nurturing, customer journey orchestration, web personalization, and behavior-triggered messaging. Salesforce offers several marketing-automation products: Marketing Cloud Engagement (formerly ExactTarget) for enterprise B2C and B2B email and journey orchestration; Pardot (now branded Marketing Cloud Account Engagement, MCAE) for B2B-focused lead nurturing; Marketing Cloud Personalization (formerly Interaction Studio) for real-time web personalization; and Data Cloud as the unified profile layer underneath. The term Marketing Automation is intentionally broad. Some customers run a single Marketing Cloud product end-to-end; others stitch Pardot + Marketing Cloud Engagement + Marketing Cloud Personalization + Data Cloud into a complete marketing technology stack. Salesforce''s strategic direction has been consolidating these products under a unified Marketing Cloud brand with Data Cloud at the center, but the historical product silos (Pardot for B2B, Marketing Cloud Engagement for B2C, Personalization for real-time) still drive most enterprise marketing stacks today.

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 cross-channel marketing analytics platform, formerly branded as Datorama before Salesforce acquired and rebranded it in 2022. The product aggregates data from every marketing source (Marketing Cloud Engagement, Pardot/MCAE, Google Analytics, paid-ad platforms like Google Ads and Facebook Ads, Adobe Analytics, web tracking, mobile attribution platforms) into a unified analytics warehouse, then builds dashboards and reports that combine the data into cross-channel views. Marketing teams running campaigns across multiple channels need to compare results: how much did email contribute versus paid search versus social? Each channel''s native analytics tells only part of the story; cross-channel views require pulling data together. Marketing Cloud Intelligence is the platform that does this aggregation at enterprise scale, with pre-built connectors to hundreds of marketing data sources, a flexible data model that maps disparate inputs into a unified taxonomy, and powerful dashboard authoring for marketing executives and campaign analysts.

Marketing Cloud Personalization is the Salesforce real-time personalization product that captures customer behavior across web, mobile app, email, call center, and physical store interactions, builds a unified visitor profile, and decides what content or offer to surface to each customer in real time. Salesforce launched the product as Interaction Studio in 2020 after acquiring Evergage, then rebranded it to Marketing Cloud Personalization in 2022. The product''s core capability is millisecond-latency decisions powered by machine-learning models trained on the visitor''s historical and live behavior. Personalization sits in the broader Marketing Cloud product family as the real-time activation layer on top of unified profile data. Marketing Cloud Engagement handles email and journey orchestration; Marketing Cloud Personalization handles the moment-of-truth decisions when a customer lands on the website or opens the app. Data Cloud increasingly underpins both products as the unified profile platform, with Personalization sourcing visitor profile data from Data Cloud rather than maintaining its own silo.

A Marketing User in Salesforce is a User with the Marketing User checkbox enabled on their User record. The checkbox grants access to Campaign management features: creating campaigns, adding members, importing leads from a campaign-influence file, and using the Campaign-related Lightning components. Without the Marketing User flag, users on otherwise-standard profiles cannot create or edit Campaign records, even when they have the Salesforce CRM Content User and Marketing User permission sets assigned. The Marketing User flag exists because Campaign management is licensed independently from the broader Sales Cloud user license. Salesforce historically tied Campaign edit-access to a specific feature license; the modern model uses the Marketing User checkbox plus permission set assignments. Marketing teams that run campaigns in Salesforce (lead generation, event tracking, customer acquisition) need the flag enabled on every team member. Sales teams that consume campaign data (reading campaign membership on Leads and Contacts) do not need the flag.

A Mass Action in Salesforce is an action that operates on multiple records at once, typically launched from a List View by selecting rows and clicking a mass-action button. Built-in Mass Actions include Mass Edit (change a field value across many records), Mass Delete (delete the selected rows), Mass Transfer (change owner), and Mass Email (send the same email to many recipients). Admins can also build custom Mass Actions via Lightning Quick Actions, Flow-launched buttons, and Apex-backed Visualforce pages exposed on the List View. Mass Actions exist because users routinely need to update or process many records at once. Without them, every record-level operation requires opening each record individually, an obvious productivity loss at scale. The Lightning Experience List View supports mass selection (checkboxes per row, Select All) and exposes the configured mass actions in the action bar above the list. Admins control which mass actions appear via the List View Action Configuration on the relevant object.

Mass Delete Records is the Salesforce Setup feature that lets administrators delete records in bulk from a small list of supported objects: Accounts, Leads, Contacts, Activities (Tasks and Events), Cases, Solutions, Products, and a few others. The tool runs through a guided UI where the admin selects the object, sets filter criteria, previews matching records, and confirms deletion. Each operation caps at 250 records per run, making the tool useful for targeted cleanup rather than large data purges. For deletions exceeding 250 records or on unsupported objects, Data Loader is the standard alternative. Mass Delete Records lives in Setup precisely because it is a sensitive operation requiring the administrator privilege; it cannot be run as a regular user even with Delete object permission. The 250-record cap is a safety mechanism: even an administrator clicking through the wizard cannot wipe out tens of thousands of records in one operation. For large cleanup, the admin must explicitly choose Data Loader or another bulk path.

Mass Transfer Approval Requests is the Salesforce Setup tool that lets administrators reassign pending approval requests in bulk from one user to another. The tool addresses a specific operational pain point: when an approver leaves the company, goes on extended leave, or changes role, their pending approval requests stop moving. Without bulk reassignment, every pending request must be reassigned manually one at a time, which is impractical for high-volume approval workflows. The tool runs through Setup, supports filtering by various criteria (current approver, approval process), and reassigns matching requests to a new user in one operation. The tool only affects pending approval requests; approved or rejected requests cannot be reassigned through this path. The reassignment preserves the approval history: the request retains its original submitter, submission date, and any prior approver actions. Only the current pending step shifts to the new approver. This preserves audit integrity for compliance scenarios where the approval chain must be reconstructible after the fact.

Mass Transfer Records is the Salesforce Setup tool that lets administrators reassign record ownership in bulk from one user to another. The tool addresses a recurring administrative need: when a sales rep leaves, when accounts are reorganized between territories, when a manager redistributes deals, ownership changes are often required for hundreds of records at once. Without bulk transfer, ownership changes happen one record at a time, which is impractical for any organization beyond the smallest. Mass Transfer Records supports Account, Lead, and a small set of other objects, with filter criteria to scope the transfer precisely. The tool changes the OwnerId field on each matching record and optionally cascades to related records based on transfer rules. Cascading is important: transferring an Account often should also transfer its Opportunities, Cases, and Contacts; transferring a Lead does not have downstream effects. The tool exposes the cascade options as checkboxes during setup. Workflow and triggers fire on the OwnerId change, so any logic that depends on owner runs for every transferred record.

Mass Update Addresses is the Salesforce Setup tool that updates the Country, State, or Country Code field on Account, Contact, Lead, or Person Account records in bulk based on a CSV mapping. The tool exists to support the State and Country Picklist migration: when an org enables State and Country Picklists for the first time, all existing address records use free-text Country/State values that need to be standardized to picklist entries. Mass Update Addresses provides the bulk normalization path, mapping the existing free-text values to the new standardized picklist values. The tool is most useful during a one-time State and Country Picklist enablement. After enablement, individual record edits use the picklist directly, so the tool's role becomes limited to bulk cleanup. Some orgs run it periodically as data quality maintenance: catch records with deprecated country names or alternate state spellings, normalize them. The tool is one piece of a broader address data quality program; pair with Address Standardization or Data.com Clean for fuller normalization.

The Master HSM is the central hardware security module that Salesforce uses internally to protect the master keys behind its key management infrastructure. In the Salesforce Shield key hierarchy, customer tenant secrets are themselves protected by wrapping under a higher-level master key, which lives in a FIPS-certified Master HSM operated by Salesforce. The Master HSM is the root of trust: customer-managed tenant secrets derive their working key material through operations involving the Master HSM, and Salesforce-managed keys are entirely controlled by the Master HSM. The Master HSM is platform infrastructure rather than customer-facing configuration. Customers do not interact with it directly through the UI; they trust that Salesforce operates the HSM correctly under documented compliance programs (FedRAMP High, SOC 2, etc.). The Master HSM concept matters for compliance auditors and architects evaluating Shield: it explains how Salesforce-Managed Keys remain protected even from broad Salesforce employee access, and how the chain of trust extends from customer tenant secrets through Salesforce-controlled infrastructure to the underlying HSM hardware.

A Master Picklist in Salesforce is the canonical, complete list of values for a picklist field, defined at the field level and used as the source for any record type that restricts the picklist's values. Each picklist field has exactly one Master Picklist; record-type-specific picklist value sets are subsets of the master. The Master Picklist is where new values are added or retired; record type configurations then choose which subset of master values appear for that record type. The concept matters because picklist administration spans two layers: master-level value management (what is the full list of possible values?) and record-type-level value selection (which values does this specific record type expose?). Confusing these layers produces frequent administrative mistakes: a value added to a record type without first adding to the master fails silently; a value removed from the master propagates to all record types that included it. Understanding the master/record-type relationship is foundational to picklist administration.

The Master Secret in Salesforce Shield is the top-level cryptographic input from which all other keys in the customer's key hierarchy derive. The Master Secret is held in the Salesforce Master HSM (or in the customer HSM for BYOK and Cache-Only scenarios) and never appears in plaintext outside the HSM boundary. Operations needing key material derive it through HSM-mediated key derivation; the Master Secret itself does not encrypt customer data directly. The concept matters for compliance documentation and architecture review. Auditors examining a Shield deployment look for evidence that the Master Secret is properly protected: held in FIPS-certified hardware, accessed only through controlled operations, rotated on a defined schedule, destroyed when no longer needed. The Master Secret is the security anchor; compromise of the Master Secret would compromise every key derived from it, which is why the HSM protection is non-negotiable. Customers cannot view, export, or directly manipulate the Master Secret; their interactions happen through tenant secret operations layered above it.

The Master Wrapping Key in Salesforce Shield is the cryptographic key used to wrap (encrypt) tenant secrets so they can be stored at rest without revealing the plaintext secret material. When Salesforce stores a customer tenant secret, it does so wrapped under the Master Wrapping Key; only the HSM can unwrap it. This wrapping ensures that even if an attacker accesses the storage backing for tenant secrets, the plaintext secrets remain protected by the HSM-controlled wrapping key. The Master Wrapping Key lives in the Master HSM (or in the customer HSM for BYOK and Cache-Only scenarios). Like the Master Secret it protects, the Master Wrapping Key never appears in plaintext outside the HSM. The key participates in two main operations: wrapping tenant secrets when they are first generated or imported, and unwrapping them when needed for derivation operations. The wrapping key is part of the chain of trust that connects customer-facing tenant secrets to the deeper HSM-protected master infrastructure.

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.

Matching Rules are the Salesforce configuration that defines how the platform compares records to identify duplicates. Each Matching Rule specifies which fields to compare and which comparison method to use per field: exact match, fuzzy match, or specific algorithms for normalized comparison of names, companies, emails, or addresses. The rule is the lower-level building block of Duplicate Management; Duplicate Rules reference Matching Rules and decide what to do when a match is found. Standard Matching Rules ship for Account, Contact, and Lead, with pre-built logic appropriate for B2B sales scenarios. Custom objects need administrator-created Matching Rules. A single Matching Rule can be cross-object, allowing a Lead to match against existing Contacts, which is the foundation of the Lead-to-Contact duplicate detection most B2B orgs need. Each object can have up to 5 active Matching Rules; activating a rule takes several minutes and queues other operations on the rule during the activation window.

A Matrix Report in Salesforce is a report format that summarizes data across two dimensions: row groupings and column groupings. The result is a cross-tab grid where each cell shows the aggregated metric (sum, count, average) for the intersection of one row group and one column group. The classic use case is revenue by region by quarter: regions on rows, quarters on columns, opportunity amount in each cell. Matrix Reports answer two-dimensional analytical questions that tabular and summary reports cannot. Salesforce supports four report formats: Tabular (a simple list), Summary (grouped by one dimension), Matrix (grouped by two dimensions), and Joined (combining multiple report blocks). Matrix is the most analytically powerful of the standard formats. The Lightning Report Builder provides drag-and-drop matrix configuration: pick the row grouping, the column grouping, the aggregation field, and the function. Charts on matrix reports use stacked bars, heat maps, or pivot-style visualizations to surface patterns the raw grid would hide.

A Meeting Request in Salesforce is the action that sends a calendar invitation to one or more attendees, proposes a meeting time, and tracks the responses (Accepted, Declined, Tentative). The action lives across several Salesforce surfaces: the Outlook and Gmail Integration add-ins (Schedule a Meeting from inside a Salesforce-linked email), Salesforce Inbox (Insert Availability to propose times), Salesforce Scheduler (full appointment booking via Lightning components), and the older Salesforce Classic Meeting Request feature (legacy, not recommended). Modern Salesforce meeting workflows live primarily in Salesforce Inbox plus the Gmail and Outlook Integrations. A sales rep replying to a prospect''s email clicks Insert Availability, the integration shows the rep''s calendar, the rep picks proposed times, the email goes out with selectable slots, and the prospect''s click creates a calendar event back in the rep''s Salesforce-synced calendar. The pattern eliminates the back-and-forth and integrates the meeting into the Salesforce activity timeline automatically.

Member Status in Salesforce is the picklist field on the CampaignMember object that tracks how a Lead or Contact engaged with a specific campaign. Each Campaign has its own set of Member Statuses (Sent, Responded, Attended, Not Attended), and a CampaignMember record on that campaign carries one of those statuses. Member Status drives campaign effectiveness reporting, response-rate calculations, and the Campaign Influence attribution model used to credit revenue back to marketing campaigns. Each Campaign owns its own Member Status set, configured under the campaign''s related Member Statuses page. Default statuses (Sent, Responded) ship out of the box; admins can add campaign-specific statuses (Attended, Registered, Watched, Engaged) to match the campaign type. One status per campaign is marked Has Responded; CampaignMembers with that status count as responses for the campaign''s Response Rate calculation. The interplay between Member Status and campaign reporting is the foundation of marketing-attribution analysis in Salesforce.

A Merge Field in Salesforce is a placeholder syntax used in formulas, email templates, validation rules, formula fields, Visualforce pages, and many other Salesforce surfaces to inject dynamic record data at runtime. The syntax wraps a field reference in curly braces and an exclamation point: {!Account.Name}, {!Opportunity.Amount}, {!Contact.Email}. When the platform processes the surface (renders an email template, evaluates a formula, runs a Visualforce page), it replaces each merge field with the actual field value from the relevant record. Merge fields are the primary mechanism for personalization across every Salesforce template-driven feature. Email templates use merge fields to address the recipient by name; Visualforce email templates use the same syntax inside Apex-rendered emails; formula fields use merge fields to reference parent-record values; validation rules use them in their criteria expressions. The exact merge-field syntax varies slightly across surfaces (formulas use FIELDNAME, email templates use {!FIELDNAME}, Visualforce uses {!FIELDNAME}), but the underlying concept is consistent: insert dynamic data at render time.

A Message Channel in Salesforce is a typed pub-sub conduit used by Lightning Web Components (LWC) and Aura Components to communicate with each other across the same Lightning page, even when the components are nested in different DOM trees or do not have a parent-child relationship. Message Channels are part of the Lightning Message Service (LMS) framework introduced in Spring 20; each channel is a metadata record declaring the channel name and the schema of messages that pass through it. Components publish messages on the channel; subscribed components receive them. Lightning Message Service solves a real architectural problem. Lightning App Builder pages combine many components from different namespaces (standard, custom, AppExchange), and these components frequently need to coordinate (selecting an item in one component should filter another). Without Message Channels, the coordination required either parent-child events (only works when components share a parent) or custom JavaScript globals (fragile and namespace-unsafe). Message Channels provide a clean, declarative, cross-component-tree communication mechanism with type safety.

Message in Chatter is the direct messaging feature inside Chatter that lets users send private one-on-one or small-group messages outside the public feed. Chatter Messages travel between Salesforce users (internal employees and external Community members) and are stored on the ChatterMessage standard object. The feature exists for conversations that need privacy: discussing a sensitive customer issue, sharing internal-only context on a deal, or coordinating quietly with a colleague without posting to a public group. Chatter Messages run alongside the public Chatter feed and Chatter Groups. Public posts and comments live on FeedItem and FeedComment; private messages live on ChatterMessage. The two systems are separate and have different visibility models: feed items respect record sharing and group membership; messages respect only the participant list. Salesforce''s strategic direction has moved private messaging to Slack for most modern orgs, but Chatter Messages persist in every org for legacy reasons and for orgs that have not adopted Slack.

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.

Messaging Components in Salesforce are the building blocks of structured outbound messages sent through Messaging for In-App and Web (the platform's customer messaging product, formerly Embedded Service Chat and predecessors). Components include rich content elements like images, headers, buttons, lists, time-pickers, and forms that agents and bots compose into messages richer than plain text. The platform renders these components consistently across the supported channels (in-app messaging, web messaging, WhatsApp, Apple Messages for Business, Facebook Messenger), with channel-specific fallbacks when a channel does not support a given component. The components matter because customer messaging has moved beyond plain text. Customers expect rich interactive responses: tappable buttons, structured order summaries, embedded forms, location pickers. Messaging Components are the platform mechanism for building those experiences declaratively, without writing per-channel rendering code. Agents use them through the agent console; bots use them through Einstein Bots; integrations use them through the Messaging API. The component library is configured in Setup, with administrators defining which components are available and how they render per channel.

Messaging for In-App is the Salesforce Service Cloud feature that lets customers exchange messages with support agents inside the customer''s own mobile app, using a Salesforce-supplied SDK. Customers tap a Chat-with-us button in the app; the SDK opens a chat window; messages flow to Salesforce, where they appear in the Service Console for an agent to respond. The conversation stays inside the customer''s app the entire time, providing a seamless support experience without forcing the customer to leave for a web browser or email. Messaging for In-App is part of the broader Salesforce Messaging product family that also includes Messaging for Web (the same capability for desktop websites), Messaging for SMS, and Messaging for WhatsApp. All four products run on the same Service Cloud foundation: messages route through Omni-Channel to the right agent, transcripts persist on the Messaging Session standard object, and Einstein Bots can handle the initial conversation before escalating to a human. Modern customer-service strategies often start with In-App and Web Messaging because they capture intent at the moment the customer is engaged with the product.

Messaging for Web is the Salesforce Service Cloud feature that lets customers exchange messages with support agents through a chat widget embedded on a website. Customers click a Chat-with-us button on the company''s site; a chat window opens; messages flow to Salesforce where they appear in the Service Console for an agent to respond. The product is the web-based sibling to Messaging for In-App, with similar architecture and behavior but deployed via a JavaScript snippet on the website instead of a native mobile SDK. Messaging for Web replaced the older Live Agent (now Salesforce Chat) product as the strategic direction for web-based customer messaging. Both products handle customer-to-agent web chat, but Messaging for Web ships modern async-conversation support (customers can close the browser tab and return hours later), tighter Einstein Bot integration, and a unified Messaging Session data model shared with In-App, SMS, and WhatsApp messaging. New deployments default to Messaging for Web; existing Live Agent deployments are typically migrated.

Messaging Settings is the Salesforce Setup page that controls the org-level configuration for Messaging for In-App and Web, the platform's customer messaging product. The page consolidates the toggles and policies that govern messaging across channels: which channels are enabled (in-app, web, WhatsApp, Apple Messages for Business, Facebook Messenger), how messages route to agents, what bots handle which conversations, and how messaging interacts with the standard Salesforce data model (Cases, Contacts, Leads). The settings are the master control plane for any customer-messaging deployment. Configuration involves coordination across multiple teams: Service Cloud admins for channel routing, integration teams for channel provisioning (WhatsApp Business API, Apple Business Register), bot designers for Einstein Bots integration, and compliance teams for message retention policies. Each Messaging Settings change should go through a defined release process because mis-configuration can take down customer-facing chat entirely or route conversations incorrectly. The page is straightforward when fully understood, but the interactions between settings, channels, and downstream automation make it deceptively complex to operate at scale.

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 configuration: an Apex Class, a Custom Object, a Workflow Rule, a Lightning Page, a Permission Set, a Profile, a Validation Rule, or any of the hundreds of other configuration types Salesforce exposes via the Metadata API. Every change an admin or developer makes to a Salesforce org modifies one or more metadata components. The Metadata API is the programmatic interface for retrieving, deploying, and modifying these components; the Salesforce CLI, DevOps Center, Change Sets, and CI/CD pipelines all operate on metadata components. Metadata Components are the unit of versioning, deployment, and source-control in modern Salesforce DX projects. The SFDX source format stores each component as a file (or set of files) in a folder structure organized by component type. Change Sets bundle components for sandbox-to-production deployment. Managed packages distribute components for installation in subscriber orgs. Understanding which components are needed for a given change is the foundation of accurate Salesforce deployment planning.

The Metadata Coverage Report is the Salesforce-published reference documenting which metadata components are supported by each Salesforce deployment and packaging mechanism: Metadata API, Source Tracking, Change Sets, Unlocked Packages, Managed Packages, Toolkit for SFDX, and other deployment channels. The report is a critical pre-deployment reference for any migration project: before assuming a configuration can move between orgs, check the report to confirm the component type is supported by the chosen deployment mechanism. The report lives at developer.salesforce.com/docs/metadata-coverage and updates per Salesforce release. Each row is a metadata component type (ApexClass, CustomObject, Flow, etc.); each column is a deployment mechanism. Cells show full support, partial support, or no support per combination. Components without support require manual configuration in each target org, breaking the deploy-and-ship workflow. The Metadata Coverage Report is what tells a developer whether a feature can be carried in a managed package, deployed via SFDX, or has to be configured by hand.

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-based interface definition for the Salesforce Metadata API. The Web Service Description Language (WSDL) file is downloaded from Salesforce Setup and imported into developer tools (Java, .NET, or anywhere SOAP clients run) to generate stub code for calling the Metadata API operations: retrieve, deploy, list, and describe. The Metadata WSDL was the original primary interface for metadata operations before Salesforce launched the REST-based Metadata API and the modern Salesforce CLI workflow. The Metadata WSDL is still supported today and powers many enterprise CI/CD tools (Copado, AutoRabit, Gearset) under the covers. Modern developers rarely interact with the WSDL directly; instead, they use the Salesforce CLI, which wraps both the SOAP and REST Metadata APIs and exposes a consistent command-line interface. The WSDL remains relevant for legacy integration patterns, for tools that prefer SOAP, and for Apex code that wants to call the Metadata API programmatically via WSDL2Apex-generated classes.

Metadata-Driven Development is the Salesforce architectural philosophy where the platform itself is configured through metadata (declarative definitions) rather than through hand-written code. Custom objects, fields, validation rules, page layouts, permissions, automation flows, Lightning pages, and email templates all live as metadata records in the org''s configuration. When an admin creates a custom field, Salesforce stores the field definition as metadata; when a developer deploys an Apex class, the class itself is metadata. The platform interprets the metadata at runtime to deliver the configured experience. The philosophy distinguishes Salesforce from traditional code-first platforms. Most cloud platforms require developers to write code for nearly every customization; Salesforce''s metadata model lets admins do most customization declaratively and lets developers focus on the cases that genuinely need code. The metadata-driven approach is the foundation of the entire Salesforce DX delivery model: every change in source-controlled, version-controlled, and deployable as metadata. The same philosophy underpins multitenancy, packaging, and rapid release cadence.

Migrate to Flow is the Salesforce-supplied tool that converts legacy Workflow Rules and Process Builder processes into modern record-triggered flows in Flow Builder. Salesforce announced the retirement of Workflow Rules in 2026 and the gradual deprecation of Process Builder; Migrate to Flow is the migration assistant that makes the transition feasible at scale. The tool reads the source automation, generates an equivalent flow, and lets the admin review and adjust before activating. Migration is one-way: once the flow is active and the legacy rule is deactivated, the migration is complete. The tool sits under Setup, Migrate to Flow. It handles the most common migration cases automatically: simple Field Update actions become Update Records elements; Email Alerts become Send Email Alert actions; Tasks become Create Records elements; the rule criteria becomes the flow''s entry condition. Complex cases (custom formula logic, cross-object updates) may not translate perfectly and need manual cleanup. The tool is essential infrastructure for the Workflow Rules sunset; orgs that ignore it face manual migration of every legacy rule.

Migration in the Salesforce context covers any of several distinct activities: data migration (moving records between systems or environments), metadata migration (deploying configuration between orgs), platform migration (moving an org from legacy infrastructure to Hyperforce), product migration (replacing one Salesforce feature with another like Workflow Rules to Flow), and license migration (moving users between license types). The word is overloaded; understanding which type of migration is being discussed is the first step in any conversation. Each migration type has its own tooling and risks. Data migrations use Data Loader, ETL tools, MuleSoft, or direct API calls. Metadata migrations use Change Sets, SFDX deployments, Unlocked Packages, or DevOps Center. Hyperforce platform migrations use the Hyperforce Assistant. Product migrations use feature-specific tools like Migrate to Flow. License migrations are contract-driven through Salesforce account teams. All share a common pattern: inventory the source, design the target, plan the cutover, test thoroughly, execute with rollback options 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 the legacy Salesforce Classic configuration that defined the contents of the hover-detail popup shown when users hovered over a record name in a list view, related list, or lookup. Each Mini Page Layout selected a subset of fields from the full Page Layout and rendered them in the hover popup, letting users preview a record without navigating to it. The configuration lived under each object''s Page Layout edit screen and could be customized per record type. Mini Page Layouts are a Classic-only concept. Lightning Experience replaced the Mini Page Layout with the Compact Layout, which serves the same purpose (drive hover details and highlight panels) but with a unified configuration that also feeds the Highlights Panel, the Salesforce mobile view, and search-result previews. Orgs migrating from Classic to Lightning typically drop Mini Page Layouts entirely and configure Compact Layouts as the modern equivalent. Mini Page Layout references in legacy documentation are historical context only.

The Mini View in Salesforce Classic was the right-side panel that surfaced record details when a user opened the Service Cloud Console. It showed selected fields from the primary record (the case being worked on), with related records (Contact, Account) listed below. Admins configured the Mini View via the Mini Page Layout for each object that participated in the Console. The feature predated Lightning Experience and was specific to Salesforce Classic''s Console product. Lightning Experience replaced the Mini View concept with the Service Console''s right sidebar (utility bar plus highlights panel plus related records panel), all configured via Lightning App Builder, Compact Layouts, and standard related-list configuration. The Mini View term persists in older training material and inherited org documentation; modern Salesforce orgs do not configure Mini Views because the Lightning Service Console layout is fundamentally different. Treat the term as historical context for any Classic-to-Lightning migration.

Mobile Builder for the Seller-Focused Experience is the Salesforce-supplied mobile experience optimized for outside sales representatives, surfacing the Salesforce data and workflows reps need while on the road. The product (sometimes branded as Salesforce Mobile for Sellers or the Mobile Seller Experience) layers a sales-rep-tailored interface on top of the standard Salesforce mobile app: account 360 view, opportunity pipeline at a glance, today''s scheduled visits, voice-to-text note capture, and offline-capable record editing. The product addresses the gap between the standard Salesforce mobile app (a generic mobile interface that works for every persona) and dedicated field-sales mobility tools. Outside sales reps need fewer clicks to reach the next prospect, voice-driven data entry between meetings, and offline capability for venue Wi-Fi dead zones. Mobile Builder for the Seller-Focused Experience tunes the mobile experience for this persona while still running on the Salesforce platform with all its data, permissions, and audit benefits. The product is part of the broader Salesforce mobile platform investment under the Einstein 1 Platform direction.

Mobile Configuration in Salesforce is the umbrella term for the Setup-side configuration that controls how the Salesforce mobile app and Mobile Publisher-deployed apps behave for end users. The configuration spans several Setup nodes: Salesforce Mobile App Quickstart for the standard mobile-app setup, Mobile Publisher for white-label apps, Mobile Notifications for push-notification routing, Mobile App settings for global mobile behavior, and the broader Lightning App Builder for mobile-specific record pages. Mobile Configuration matters because the Salesforce mobile experience is meaningfully different from desktop Lightning Experience. Mobile users see smaller screens, work in shorter sessions, often without reliable connectivity, and need offline data access. The mobile configuration tunes the experience for these constraints: which pages render on mobile, which actions appear in the global actions menu, which notifications fire, and which data caches offline. Without thoughtful configuration, the mobile experience defaults to a phone-sized desktop UI; with it, mobile users get a tailored experience that matches how they actually work.

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 commonly refers to a Trailhead Module, the basic learning unit on Salesforce''s free training platform Trailhead. Each Trailhead Module is a self-contained lesson on a specific Salesforce topic (Apex Basics, Flow Builder, Service Cloud, Einstein) consisting of a few short units of reading material and one or more hands-on challenges that learners complete in a Trailhead Playground (a free temporary Salesforce org). Completing a module earns points and badges that aggregate into the learner''s Trailhead profile. Beyond Trailhead, the word Module appears occasionally in other contexts: ES6 JavaScript modules in Lightning Web Components, MuleSoft modules in Anypoint integration code, Heroku buildpack modules. In the Salesforce-specific vocabulary, however, Trailhead Module is by far the dominant meaning. Salesforce has invested heavily in Trailhead since 2014, building thousands of modules across every product area; the platform is the primary self-service learning resource for admins, developers, architects, and end users learning Salesforce.

Monitor Workflow Services in Salesforce is the Setup-side capability for viewing and managing the queued time-based actions and the failed async workflow runs that the platform tracks. The feature lives under Setup, Monitor, Time-Based Workflow (for queued time-dependent actions) and Setup, Monitor, Apex Jobs (for failed Apex-driven workflow runs). Admins use the screens to find pending time-based actions, deactivate ones that should not fire, and audit failures across the org''s automation surface. The Monitor surface is essential operational visibility for orgs running Workflow Rules with time-dependent actions. Without it, admins would not know which records have queued actions, when they fire, or which ones failed. The Monitor screens let admins delete pending actions (when the record state changed so the action no longer applies), inspect failure reasons (to debug bad automation), and audit the full set of pending automation work. With Workflow Rules retiring in 2026, the modern equivalent is Setup, Flow Builder''s Paused and Waiting Interviews node for flow-based scheduled paths.

A Mule Application is the unit of integration code that runs on the MuleSoft Anypoint Platform. Each Mule Application is built in Anypoint Studio (the developer IDE) as a collection of flows, sub-flows, connectors, and DataWeave transformations packaged into a deployable artifact. The application typically listens for messages from one or more sources (HTTP endpoints, message queues, scheduled timers, file polls), processes the messages through transformation and orchestration logic, and writes results to one or more destinations (Salesforce, ERP, database, external APIs). Mule Applications are the integration workhorses in MuleSoft-powered Salesforce ecosystems. Customers use them to sync Salesforce data with ERP, push contact updates to marketing automation, expose Salesforce data as REST APIs to partner systems, and orchestrate complex multi-step business processes across multiple back-end systems. The Application model emphasizes reusability through the API-led connectivity pattern: layered applications (System APIs, Process APIs, Experience APIs) that compose into the full integration architecture.

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.

MuleSoft Anypoint Platform is the unified integration platform that MuleSoft (a Salesforce-owned company) sells for designing, deploying, managing, and monitoring integration code across enterprise IT systems. The platform spans Anypoint Studio (the developer IDE), Anypoint Design Center (web-based design tool), Anypoint Exchange (a marketplace of pre-built connectors and templates), CloudHub (managed cloud runtime), Anypoint Runtime Fabric (on-premises Kubernetes runtime), Anypoint Monitoring (observability dashboards), and Anypoint API Manager (API gateway and lifecycle management). The platform is the centerpiece of MuleSoft''s value proposition: an end-to-end integration ecosystem that handles the design, development, deployment, and operation of every integration in an enterprise. Customers running Salesforce-integrated landscapes commonly use Anypoint Platform to sync Salesforce with ERP, marketing automation, billing, and other back-end systems. Salesforce acquired MuleSoft in 2018; Anypoint Platform is now Salesforce''s strategic integration platform, with deep product integration into the broader Salesforce stack via the Salesforce Connector for MuleSoft and shared platform constructs.

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.

MuleSoft Integration is the broad term for using MuleSoft Anypoint Platform to connect Salesforce with external systems (ERP, marketing automation, data warehouses, partner APIs, custom-built applications). Each integration is built as one or more Mule Applications that orchestrate data movement, transformation, and business-process logic across systems. MuleSoft is Salesforce''s strategic enterprise integration platform; customers running Salesforce alongside SAP, Oracle, Workday, NetSuite, or any other enterprise system commonly use MuleSoft as the integration glue. The integration patterns are well-defined: real-time sync of master data (Account, Contact), batch loads of transactional data (Opportunity, Order, Invoice), event-driven workflows (platform events trigger downstream actions), exposing Salesforce as a REST API to partner systems, and orchestrating multi-step business processes. MuleSoft promotes API-Led Connectivity as the architectural pattern: System APIs for back-end systems, Process APIs for business operations, Experience APIs for channel-specific endpoints. The pattern produces reusable, maintainable integration code at enterprise scale.

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 includes multiple invitees beyond the event organizer. Each invitee receives a calendar invitation; the platform tracks the response (Accepted, Declined, Tentative) per invitee on the EventRelation child object. The Event record itself holds the organizer''s details, the time and location, and the meeting subject; the EventRelation records hold the invitee list and their response statuses. Multi-Person Events are the standard way Salesforce models meetings with multiple attendees: a sales rep meeting with five prospects, an account team kickoff with the customer, a quarterly business review with the client''s executive team. The model distinguishes between Salesforce internal users (User invitees) and external attendees (Contact or Lead invitees). The Einstein Activity Capture and Outlook/Gmail integrations auto-create Multi-Person Events when users schedule meetings in their email calendars, syncing the attendee list and response data back to 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 architectural pattern that runs many customer organizations (tenants) on the same shared physical infrastructure: the same servers, the same database, the same application code. Each tenant''s data is logically separated from every other tenant''s data, but the underlying compute and storage are shared. Salesforce was built as a multitenant platform from its founding in 1999; the entire Salesforce stack (Sales Cloud, Service Cloud, Marketing Cloud, Heroku, MuleSoft) shares this architectural foundation. Multitenancy is the reason Salesforce can ship the same release to thousands of customers simultaneously, deliver dramatic cost efficiencies versus single-tenant alternatives, and enforce governor limits to protect tenant-to-tenant resource sharing. The pattern also constrains how customers can customize: every customer runs the same code base, so customization happens through metadata configuration rather than per-tenant code branches. The metadata-driven philosophy and the governor-limits enforcement both derive directly from the multitenant architecture.

MVC (Model-View-Controller) is the software architecture pattern that separates an application into three layers: the Model (data and business logic), the View (UI presentation), and the Controller (orchestration between Model and View). In the Salesforce context, MVC is the design philosophy behind Visualforce: a Visualforce page is the View, an Apex Controller is the Controller, and the Salesforce sObject layer (plus any custom Apex classes manipulating it) is the Model. The pattern lets developers separate concerns and produce maintainable code. While MVC dates from Smalltalk in the 1970s, Salesforce''s Visualforce-era documentation made the pattern explicit for Salesforce developers. Modern Salesforce development has moved to component-based architectures (Aura, Lightning Web Components) that retain MVC-like separation but with different vocabulary (template, JavaScript class, Apex controller via @AuraEnabled). Understanding MVC remains foundational for any Salesforce developer reading legacy Visualforce code or designing modern Lightning Web Components.

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 Salesforce area where individual users configure their personal preferences: display language, locale, time zone, email signature, calendar visibility, notification preferences, password, and various smaller settings. The area is accessible from the user avatar menu in the top-right corner of Lightning Experience, opening a guided menu of categorized settings (Personal, Display & Layout, Email, Calendar & Reminders, Chatter, etc.). Unlike Setup, which holds org-wide configuration controlled by administrators, My Settings holds per-user preferences controlled by the user themselves. The area is the user-facing counterpart to admin-set defaults. The org default Locale is set in Setup; the user's personal Locale override is in My Settings. The org default Email Footer is set in Setup; the user's email signature is in My Settings. Each user can configure their own experience without admin involvement, within the bounds the admin allows. Some settings have admin-side enforcement: an org with mandatory MFA prevents the user from disabling it through My Settings.