Web Links
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.
Definition
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.
How Web Links work and what to use instead
The three pieces every Web Link has
Every Web Link is defined by three choices. The first is the display type, which controls where it shows up: a detail page link (small text link in the Links section), a detail page button (a button on the record), or a list button (a button on a related list or list view). The second is the content source. URL is a hyperlink built from a static address plus merge fields. OnClick JavaScript runs code in the browser. Visualforce Page renders a custom Apex-backed page. The third is the behavior, which decides how the target opens: a new browser window, the existing window with the sidebar, the existing window without the sidebar, or an inline execution for JavaScript. In the Metadata API these map to fields on the WebLink type, including displayType (link, button, massActionButton), linkType (url, javascript, page, sControl, flow), and openType. Understanding these three axes makes the Setup screen far less confusing, because each dropdown corresponds to one of them.
URL links and merge fields
The most portable kind of Web Link is a plain URL link. You type a target address and drop in merge fields that Salesforce resolves at runtime. For example, {!Account.Id} inserts the current record Id, {!Account.Name} inserts the account name, and {!User.Email} inserts the running user email. Global merge fields like {!$Api.Session_ID} and {!$User.Username} are also available. This lets a single link open a Google search for the account, pass a record Id to an internal portal, or deep-link into a partner system with context already filled in. URL links honor encoding settings so values with spaces or special characters arrive intact. Because a URL link is just a hyperlink, it renders in both Salesforce Classic and Lightning Experience without changes. The one caveat is that some older patterns relied on appending Salesforce UI parameters (sometimes called URL hacking) to prefill standard edit pages. Those parameters are unsupported and unreliable in Lightning, so prefilled-create use cases should move to Quick Actions or Flow with default field values.
Why JavaScript Web Links stop working in Lightning
The OnClick JavaScript content source is the part of Web Links that breaks in Lightning Experience. It simply does not appear when a user is in Lightning, and it cannot be added to Lightning pages. The reason is security. Lightning Experience runs in a hardened model where mixing untrusted JavaScript from many authors with the application code creates real risk. Salesforce chose not to carry that capability forward. In Classic these buttons could do almost anything: read and change field values before save, validate input, call the AJAX Toolkit or external APIs, or perform mass updates from a list view. That flexibility is exactly why they were popular, and also why removing them caused so much rework. If you still run Classic, JavaScript buttons keep functioning there. But any org with a Lightning rollout on the calendar should treat every JavaScript button as something to inventory and replace before the switch, because users will silently lose the action otherwise.
The modern replacements, mapped to use cases
Salesforce documents four supported paths that cover what JavaScript buttons used to do. Quick Actions are declarative and need no code. They handle create-with-defaults, update-a-field, and log-a-call patterns, and an admin can build them in minutes. Flow, built in Flow Builder, replaces multi-step logic: prompt for input, branch on conditions, update related records, or call an Apex action. A screen flow or an autolaunched flow launched from a button covers most workflow-style buttons. Lightning Web Component actions are the code-first option. You mark a component with the lightning__RecordAction target, and it becomes an action invokable from a record, which is the supported way to run custom JavaScript-like behavior in Lightning. Finally, a custom URL button still handles simple navigation and external links. The right choice depends on what the old button did. A button that just opened a URL becomes a URL button. A button that validated and saved becomes a Quick Action or Flow. A button with heavy custom logic becomes an LWC action.
The Lightning Experience Configuration Converter
You do not have to find and rewrite every JavaScript button by hand. Salesforce ships the Lightning Experience Configuration Converter, a free tool that scans an org and recreates JavaScript buttons as Lightning-friendly equivalents. It rebuilds them as Quick Actions, Lightning component actions, or plain custom buttons and links, depending on what the original code did. The tool is strongest with url-hack style buttons, which were the single most common pattern, and it leaves your original buttons untouched so nothing breaks while you test. The converter does not handle every button, so complex logic still needs a developer. A practical migration looks like this: run the converter, accept the buttons it can rebuild, list the ones it skips, then decide case by case whether each leftover becomes a Flow or an LWC action. Pair this with the Optimizer report and the Trailhead "Lightning Alternatives to JavaScript Buttons" module to size the work before you commit a cutover date.
Where Web Links live and how they are stored
Web Links are configured per object under Setup, in the Buttons, Links, and Actions area of the object manager. After you create one, it is not visible until you add it to a page layout or a related list section, so a common gotcha is building the link and then wondering why it never shows. Standard objects and custom objects both support them. Under the hood each link is a WebLink metadata component, which means it travels through change sets, unlocked packages, and the Metadata API like any other configuration. That portability matters for deployments: a button defined in a sandbox can be migrated to production without recreating it by hand. Because the metadata records the linkType, a deployment also makes it easy to audit which buttons are URL, which are Visualforce, and which are JavaScript. Running a metadata query for WebLink entries with linkType javascript is a fast way to find exactly what needs replacing before a Lightning migration, rather than clicking through every object manually.
Create a URL Web Link that survives Lightning
Here is how to create a URL-based Web Link, the variety that works in both Classic and Lightning Experience. The steps are nearly identical for a button; you only change the display type.
- Open the object in Setup
Go to Setup, Object Manager, and pick the object (for example Account). Click Buttons, Links, and Actions, then New Button or Link.
- Set label, name, and display type
Enter a Label and let the API Name auto-fill. Choose a display type: Detail Page Link, Detail Page Button, or List Button.
- Choose URL as the content source
Set Behavior (for example Display in new window) and Content Source to URL. URL keeps the link working in Lightning Experience.
- Build the URL with merge fields
Type the target address and insert merge fields from the picker, such as {!Account.Id} or {!Account.Name}, to pass record context.
- Save and add it to the layout
Click Save, then open the relevant Page Layout (or related list) and drag the new link or button into place so users can see it.
The user-facing text for the link or button.
The unique developer name; auto-generated from the label and used in metadata.
Detail Page Link, Detail Page Button, or List Button.
URL, OnClick JavaScript (Classic only), or Visualforce Page.
How the target opens, such as a new window or the existing window with or without the sidebar.
- A new link is invisible until you add it to a page layout or related list; creating it is only half the job.
- OnClick JavaScript links do not appear in Lightning Experience at all, so never use that content source for a Lightning org.
- URL parameter prefill tricks (URL hacking) that worked in Classic are unsupported in Lightning; use a Quick Action or Flow instead.
- List buttons that act on multiple records need Display Checkboxes (row selection) enabled, or users have nothing to select.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Web Links.
Hands-on resources to go deeper on Web Links.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What are Web Links?
Q2. Do JavaScript links work in Lightning?
Q3. What replaces JavaScript links in Lightning?
Discussion
Loading discussion…