Salesforce terms starting with W

Web Direct Leads in Salesforce are leads that arrive through a Web-to-Lead form submitted directly on the company own website, as opposed to leads referred from a third-party site or sourced through paid advertising. The Lead Source field is set to Web (or a finer-grained Web Direct value), with no referring URL or partner identifier captured, since the prospect started on the company own pages and converted there. The category is a reporting convention rather than a separate record type. Marketing teams use Web Direct as the baseline lead source against which paid, referral, and content-syndication channels are measured. A healthy demand-generation funnel almost always has Web Direct as one of the largest sources, since it captures organic search visits, direct URL traffic, and brand-driven returns to the site.

A Web Link in Salesforce is a custom link or button, defined on an object, that sends users to an external URL, runs JavaScript (Salesforce Classic only), or opens a Visualforce page. Admins build them in Setup and place them on page layouts, detail pages, or related list views to add quick navigation or custom actions. In the Metadata API the underlying type is literally called WebLink, which is why the older "web links" name has stuck. Web Links are treated as legacy because the term predates the modern "Custom Buttons and Links" naming, and the JavaScript variety does not run in Lightning Experience. URL-based links still work everywhere, but JavaScript behaviors must be replaced with Quick Actions, Lightning Web Component actions, or Flow when an org moves to Lightning.

Web Referral Leads in Salesforce are leads that arrive through your Web-to-Lead form but originated on a third-party website that linked back to your form. The Lead Source field is set to Web, and additional fields capture the referring URL, the campaign code, or the partner identifier so attribution can distinguish a lead that came in through a partner blog from one that came in through a direct visit to your own site. Salesforce does not ship a dedicated Web Referral Lead record type. The category is a reporting convention built on top of the standard Lead object, the Web-to-Lead form, and the referrer headers and tracking parameters captured during form submission. Marketing teams use it to credit partner sites, content syndication, affiliate programs, and SEO-driven traffic for the leads they produce.

A Web Service in Salesforce is an API endpoint (REST, SOAP, or GraphQL) that enables programmatic communication between Salesforce and external systems. Salesforce both provides Web Services (the platform standard APIs that external systems consume) and consumes Web Services (external endpoints that Apex code calls from inside the org). The bidirectional nature is what makes Salesforce a participant in larger integration architectures rather than an isolated CRM silo. The Salesforce-provided side includes REST API, SOAP API, Bulk API, Streaming API, Connect REST API, GraphQL API, Metadata API, and Tooling API. The Salesforce-consumed side includes Apex HTTP callouts to any external REST endpoint, named credentials for managing authentication, and platform integrations like Salesforce Connect for federated data access. Beyond the standard platform APIs, developers can expose custom Apex methods as REST or SOAP Web Services through the @RestResource and webservice keywords, turning specific business logic into reusable integration points.

Web Services API in Salesforce is the umbrella name for the set of programmatic interfaces that let external systems interact with Salesforce data, metadata, and platform features over HTTP. The collection includes REST API, SOAP API, Bulk API and Bulk API 2.0, Streaming API and the Pub/Sub API, Metadata API, Connect REST API, GraphQL API, Tooling API, and a handful of more specialized ones. Each API targets a different use case but shares the same authentication (OAuth 2.0 or session-based), the same versioning model, and the same rate limits. The term Web Services API is a holdover from the early Salesforce platform when SOAP was the only option and Apex had a Web Services namespace for callouts. Modern Salesforce documentation tends to use API or Platform API instead, but Web Services API still shows up in older content, on certification exams, and in any conversation with a long-tenured Salesforce developer.

A Web Tab is a custom tab type in Salesforce that displays an external web page or web-based application inside the Salesforce user interface. Admins point the tab at a URL, and Salesforce renders that page in a frame (an iframe) so users can reach an outside resource without opening a separate browser window. Web Tabs sit alongside the other custom tab types, such as Object Tabs, Visualforce Tabs, and Lightning Component Tabs. They are configured entirely through Setup with no code, which makes them the quickest way to surface a vendor portal, an internal wiki, or a simple mashup next to a user's Salesforce work.

Web-to-Case is the Salesforce feature that converts HTML form submissions on a public web page into Case records in the org. The admin generates an HTML form snippet through Setup, embeds it on a website (or hands it to a marketing team to embed), and visitor submissions arrive in Salesforce as new Cases with the submitted field values mapped to the corresponding Case fields. Auto-Response Rules can send the submitter an acknowledgment email; Assignment Rules can route the new case to the right queue or owner. Web-to-Case is the entry point for many customer-service workflows. The feature has been in Salesforce since the original Service Cloud release and is intentionally simple. It supports up to 5,000 cases per day at no extra cost. For higher volumes, customers move to Email-to-Case (which has no per-day cap) or build a custom integration through the REST API. Web-to-Case is the right choice for small-to-medium customer-facing forms: support contact forms, warranty registration, product inquiries. It is the wrong choice for high-volume B2C support where 5,000 cases per day is the floor, not the ceiling.

Web-to-Lead is the Salesforce feature that turns a web form on an external website into a direct Lead-creation pipe. Salesforce generates an HTML form snippet that posts directly to the Salesforce servers. A web visitor fills in name, email, company, message, and any custom fields; submission creates a Lead record in the org, fires Lead Assignment rules, and optionally sends an auto-response email. No middleware, no API integration code, no developer involvement. The feature predates modern marketing automation by 15 years and is still the simplest way to capture web inquiries when an org does not have Pardot, Marketing Cloud Account Engagement, or HubSpot in the stack. The HTML form is plain, ugly by default, and trivially customizable with CSS. Per-org caps apply (500 successful Web-to-Lead submissions per day on most editions, expandable via support case), and submissions over the cap are queued or dropped depending on the configured behaviour. Web-to-Lead remains the workhorse for small-business orgs and for backup inquiry capture even at the enterprise tier.

A WebService Method in Salesforce Apex is a method declared with the webservice keyword that exposes custom Apex logic as a SOAP web service endpoint. External applications call the method through the org Apex WSDL, which Salesforce auto-generates from the class declarations. The method runs inside the Apex context with the calling user permissions, making it a way to extend the Salesforce SOAP API surface with org-specific business logic that the standard SOAP API does not cover. The webservice keyword is the SOAP equivalent of the @RestResource annotation for REST. Methods marked webservice must be static, must live in a global class, and must accept and return SOAP-compatible types (primitives, sObjects, custom classes with @InvocableMethod or webservice members). The result is a callable SOAP operation discoverable in the org downloadable WSDL. In 2026, custom SOAP web services are increasingly legacy work; new integrations use REST or GraphQL APIs. WebService Method knowledge remains relevant for maintaining existing SOAP-based integrations and for certification exam questions.

WhatsApp Messaging in Salesforce is the Service Cloud Messaging channel that lets agents communicate with customers through WhatsApp Business directly from the Service Console. Each conversation is stored as a Messaging Session record in Salesforce, with the full message history, media attachments, and conversation context tied to the customer Contact or Person Account record. Agents work the same WhatsApp conversations they would in any other messaging channel, with the same Omni-Channel routing, the same Macros, and the same Service Console layout. WhatsApp is the most-used messaging app in much of the world (especially Europe, India, Brazil, and most of Latin America and Southeast Asia), and Salesforce WhatsApp Messaging integration is the supported way to serve customers who reach out through that channel. The integration uses WhatsApp official Business API, which enforces the messaging policies and templated outreach restrictions that the platform requires for legitimate business use.

Wildcard in Salesforce SOSL and SOQL queries are special characters that match patterns rather than exact text. The two supported wildcards are asterisk (*), which matches zero or more characters, and question mark (?), which matches exactly one character. Wildcards work inside SOSL search strings and in SOQL LIKE clauses, but with subtly different syntax: SOQL uses percent (%) and underscore (_) as wildcards instead of asterisk and question mark in some contexts, depending on whether the query targets the search index or the relational store. The behavior is essential for any search-heavy feature in Salesforce, from the global search bar to custom Apex Search Services. Understanding the difference between SOSL wildcards (asterisk, question mark) and SOQL LIKE wildcards (percent, underscore) is one of the most common Salesforce certification exam topics. The difference matters because the underlying query engines (the text index vs the relational query plan) handle each wildcard differently.

A wizard in Salesforce is a guided, multi-step user interface that walks a person through a structured task one screen at a time, validating input before letting them move forward. Instead of presenting every option at once, a wizard breaks a job into a short sequence of focused steps, so the user always knows what to do next. Salesforce ships several built-in wizards, including the Data Import Wizard for loading records and various setup wizards inside the Setup menu. When admins need a custom guided flow, they usually build one as a Screen Flow in Flow Builder, which provides Next and Previous navigation, stages, and a progress indicator without writing code.

A Work Item in Salesforce Omni-Channel is a record that has been queued for routing to a service agent. The record can be of almost any type that Omni-Channel supports: Case, Lead, Chat Transcript, Voice Call, Messaging Session, custom objects flagged as routable. When the record meets the configured routing criteria, Omni-Channel creates a Pending Service Routing record that represents the work item, and the routing engine evaluates the agent pool to find the right recipient based on skills, capacity, priority, and presence status. Work Items are the unit of work in any Omni-Channel-driven service operation. Each one carries a routing context (the source object, the channel, the required skills, the priority) and a lifecycle (Pending, Assigned, Accepted, Declined, Completed). Agents see work items as they arrive in the Omni-Channel widget inside the Service Console, accept the assignment, and work the underlying record. The work item disappears from the widget when the agent closes the work; the underlying record persists with its own object-specific lifecycle.

A Work Order is a standard Salesforce object that represents a job or piece of service work to be performed for a customer, usually at a specific location such as a home, office, or job site. It is the central record in Field Service, holding the what, where, and how of a task: the work type, priority, service territory, linked account or contact, the asset being serviced, and the related case or contract that triggered the work. Work orders became available in API version 36.0 and act as the parent for two important child records. Work order line items break a job into smaller billable or trackable pieces, and service appointments carry the schedulable time slot that gets assigned to a mobile worker. A work order on its own describes the work; the service appointment under it is what actually lands on someone's calendar.

A Work Order Line Item is a child record of a Salesforce Work Order that represents one subtask within a larger field service job. It lets you break a single work order into smaller pieces, each with its own status, schedule, pricing, and assigned resource. The object became available in API version 36.0 as part of Salesforce Field Service. A line item can stand on its own or sit inside a hierarchy, so a roof repair work order might split into separate line items for inspection, tile replacement, and cleanup. Each one tracks independently, yet all roll up to the same parent work order.

A Work Type is a Salesforce template object that captures the standard attributes of a job, including its estimated duration, required skills, and required products. Work orders, work order line items, and service appointments inherit those values from the Work Type, so similar jobs are described the same way every time. Work Types are used in Field Service and in Salesforce Scheduler (formerly Lightning Scheduler). They became available in API version 38.0. A Work Type is reusable, so one definition such as "Cable Install" or "Annual Service" can stamp consistent values onto thousands of records.

A Workflow Action is an automated action that runs when a Salesforce workflow rule's criteria are met. There are four kinds: a field update, an email alert, a task, and an outbound message. A workflow rule can fire its actions right away, or queue them as time-dependent actions that wait until a date you specify. Workflow Actions belong to Workflow Rules, which are now legacy automation. Salesforce ended support for Workflow Rules on December 31, 2025, so it builds no new features or bug fixes for them. Existing actions keep running, but Salesforce recommends rebuilding them in Flow using the Migrate to Flow tool.

A Workflow Email Alert is an automated email action in Salesforce that sends a templated message to a defined set of recipients when an automation fires. Recipients can include users, roles, public groups, the record owner, related user or contact lookup fields, and up to five plain email addresses. The message body comes from a saved email template, so the content stays consistent every time the alert runs. Email alerts started life as actions for Workflow Rules and approval processes. Workflow Rules reached end of support on 31 December 2025, and Salesforce now points admins to Flow Builder for new automation. The email alert action itself was not retired. A record-triggered flow can call an existing email alert, which is why this remains a legacy but still working piece of the platform.

A Workflow Field Update is a type of workflow action in Salesforce that automatically changes the value of a field when its parent workflow rule fires. It can set a value on the same record that triggered the rule, or, in limited master-detail cases, on a related parent record. Admins reached for it to stamp dates, flip statuses, set checkboxes, and recalculate values without writing code. Field updates are a legacy feature. Salesforce stopped letting orgs create new workflow rules in Winter '23 and ended support for Workflow Rules and Process Builder on December 31, 2025. Existing rules still run, but the modern replacement is a record update inside a record-triggered Flow.

A Workflow Outbound Message in Salesforce is one of the four action types a Workflow Rule can fire when its trigger criteria are met. The action sends a SOAP XML message containing record field data to a specified external endpoint URL when the workflow rule fires. The platform handles authentication (through an optional session id), retry behavior (up to 24 hours with exponential backoff), and message queuing if the external endpoint is temporarily unavailable. Outbound Messages were a common integration pattern in the 2010s for pushing record changes to external systems without writing Apex code. In 2026, Workflow Outbound Messages are part of a deprecated automation toolkit. Salesforce announced the retirement of Workflow Rules in favor of Flow as the single declarative automation platform. Flow supports a similar outbound capability through HTTP Callout actions (with Named Credentials for authentication). Existing Workflow Outbound Messages continue to fire, and Salesforce has not set a hard end-of-support date, but no new investment goes into the technology. Plan migration to Flow on a per-rule basis as Workflow Rules retire.

A Workflow Queue, also called the time-based workflow queue, is the system holding area in Salesforce that stores time-dependent workflow actions until their scheduled time arrives. When a Workflow Rule has a time trigger, the action does not fire when the record is saved. It waits in this queue and runs later, based on a date field plus the offset you defined. The Workflow Queue is older Salesforce technology. Workflow Rules reached end of support on December 31, 2025, and Salesforce now points everyone to Flow. The newer equivalent is a Schedule-Triggered Flow or a scheduled path inside a record-triggered flow. If you still have Workflow Rules running, this queue is where their pending time-based actions live, and it is where admins go to inspect or clear them.

A workflow rule is a Salesforce automation tool that fires one or more actions (field update, email alert, task creation, or outbound message) when a record meets defined criteria on create or edit. It was the platform's first declarative automation framework and ran most no-code business logic from 2007 until Process Builder and Flow took over in the late 2010s. Workflow rules still exist in most established orgs, but Salesforce stopped allowing new ones in late 2022 and is steering all customers toward Flow. A workflow rule has three pieces: an evaluation criterion (when to consider the rule), a rule criterion (which records qualify), and a list of actions to fire. The actions can run immediately when the rule fires, or be time-dependent and queued for the future. Workflow rules are still active and supported on records, but as of Winter '23 you can no longer create new ones in Setup; you can only edit existing rules. Most modernization projects either leave the rules in place or migrate them to Flow as part of broader automation consolidation work.

A Workflow Task in Salesforce is one of the four automated actions a Workflow Rule can fire when its trigger criteria are met. The action creates a Task record (a Salesforce activity) and assigns it to a specified user, role, or record owner, with a configurable subject, status, priority, and due date. Workflow Tasks were the standard way to drive follow-up reminders, action items, and ownership handoffs from rule-based automation for over a decade. In 2026, Workflow Tasks are part of a deprecated automation toolkit. Salesforce announced the retirement of Workflow Rules and Process Builder in favor of Flow as the single declarative automation platform. New automation should use Flow with a Create Records element to write a Task record. Existing Workflow Tasks continue to fire, but Salesforce has published a migration timeline and a Migrate to Flow tool to help orgs convert them before the end-of-support date.

Workforce Engagement Management in Salesforce is a Service Cloud product that handles the planning, forecasting, scheduling, and intraday management of contact center staff. It uses predicted work volumes (call arrivals, chat sessions, email tickets, social-media interactions) and channel mix to determine how many agents to schedule for each interval of the day across multiple service channels, and to adjust staffing on the fly when actual volumes diverge from forecast. The product replaces (or supplements) third-party workforce management tools like Verint, NICE, Aspect, and Calabrio for Salesforce-centric contact centers. Salesforce positions it as the native option for orgs running Service Cloud and Service Cloud Voice, with the advantage of direct integration to the underlying interaction data, Omni-Channel routing, agent skills, and shift schedules. The competitor tools remain mature alternatives for very large contact centers; Salesforce own product fits the mid-market well and is growing into the enterprise tier.

A wrapper class in Apex is a custom class that bundles several values, or several objects, into one object so your code can pass them around as a single unit. Developers reach for a wrapper class when the data a screen or a process needs does not line up with any one Salesforce object. The class declares the fields it needs as public properties, and usually a constructor that fills them in one step. The pattern shows up most often in Visualforce pages and Lightning components that display a table with a checkbox on every row. A SOQL query returns the records, but a record has nowhere to store whether its row is ticked. A wrapper class sits beside each record and holds that extra Boolean, so the page can bind to the record and the checkbox at once. The class is ordinary Apex. It carries no special annotation and can live inside the controller that uses it.

WSC, short for Web Service Connector, is an open-source Java library that generates Java client stubs from Salesforce WSDL files and provides the runtime framework for making SOAP API calls to a Salesforce org from a Java application. Developers download the appropriate WSDL from Salesforce (Enterprise WSDL, Partner WSDL, Metadata WSDL, Tooling WSDL, or a custom Apex web service WSDL), run the WSC code generator against it, and embed the resulting jar file in their Java project. The application then calls Salesforce through type-safe Java method calls instead of hand-crafting SOAP envelopes. WSC has been the standard Java integration toolkit for Salesforce SOAP APIs since 2010. The library is open-source on GitHub (the salesforce/wsc repository), maintained by Salesforce engineering, and pulled into many enterprise integration projects as the SOAP API client. In 2026, REST API has overtaken SOAP for new integrations, but WSC remains the right answer for any Java project that needs SOAP-specific features (Metadata API operations, certain bulk operations) or that has to interoperate with legacy Java code already built on WSC.

A WSDL (Web Services Description Language) file in Salesforce is an XML document that describes the operations, data types, and endpoints exposed by the SOAP API. A development tool reads this file and generates strongly typed client code, so your application can call Salesforce without hand-writing raw SOAP envelopes. Salesforce publishes several WSDLs from Setup. The two you reach for most are the Enterprise WSDL, which mirrors your own org's objects and fields, and the Partner WSDL, which is generic and works against any org. There are also Metadata, Apex, and Tooling WSDLs for those specific SOAP services.