URL S-Control
A URL S-Control was a type of Salesforce S-Control whose content source was set to URL, meaning it embedded an external web page inside the Salesforce user interface instead of holding its own HTML or JavaScript.
Definition
A URL S-Control was a type of Salesforce S-Control whose content source was set to URL, meaning it embedded an external web page inside the Salesforce user interface instead of holding its own HTML or JavaScript. You typed a link into the Content field, and Salesforce rendered that external site inside the page through an iframe. This term is retired. S-Controls were deprecated starting with the Spring '09 release, and orgs that never used them can no longer create new ones.
The URL S-Control was the simplest of the three content sources (HTML, URL, and Snippet). It existed so admins could surface an intranet page, a third-party tool, or a mashup next to Salesforce records without writing code. Visualforce pages superseded S-Controls, and today the same need is met by Visualforce, Lightning Web Components, or Canvas apps.
From external-URL embeds to modern Salesforce UI
What the URL content source actually did
Every S-Control had a Content Source setting that controlled where its output came from. The three options were HTML, URL, and Snippet. With the URL option, you did not write any markup. You pasted the link or address of an external website into the Content area, and Salesforce loaded that page for you. The official help text described it plainly: select URL if you want to enter the link or URL of an external website in the Content area. Under the covers, S-Controls ran inside an iframe. So a URL S-Control was essentially a managed iframe pointing at an outside address. Because the content source was a live URL rather than stored code, the external site stayed under its owner's control. If the target page changed, the S-Control reflected that change immediately with no edit in Salesforce. This made the URL type popular for embedding intranet portals, reporting dashboards, or vendor tools that already had their own web front end.
Where a URL S-Control showed up
A URL S-Control was not visible on its own. You had to attach it to something. The common hosts were custom buttons and links, web tabs, page layout sections, home page components, and dashboards. A web tab built on a URL S-Control gave users a full-page external site that looked like a native Salesforce tab. Dropped into a page layout section, the same S-Control showed the external page in a panel right beside the record's fields. This flexibility is exactly why the pattern spread before Visualforce existed. An admin could wire up a mashup, point a tab at a partner system, or pin a live web form to an account page, all without server-side code. The trade-off was that each placement carried iframe overhead and depended on the external site allowing itself to be framed. Sites that sent anti-framing headers would render blank, which became a frequent and confusing support issue.
Why Salesforce moved away from S-Controls
The performance model was the core problem. According to the Visualforce comparison documentation, S-Controls were less responsive because every call to the API required a round trip to the server. An HTML or JavaScript S-Control talked to Salesforce data through the AJAX Toolkit, and those calls ran from the browser. URL S-Controls avoided that data-binding cost but still inherited the iframe container and its overhead. Visualforce flipped the model. Its markup is generated on the platform server, so the page arrives largely rendered instead of assembling itself through many browser-to-server hops. Visualforce also added standard controllers, automatic data binding to fields, and built-in respect for metadata like uniqueness rules. With S-Controls, a developer had to hand-write JavaScript to enforce things the platform now handled for free. Given those gains, Salesforce positioned Visualforce as the next generation and began the deprecation.
The deprecation timeline
Salesforce labeled S-Controls as deprecated in the Spring '09 release. A follow-up developer post announced that the Spring '10 release would take the next step in S-Control deprecation. The practical effect settled into a clear rule that still holds: Visualforce pages supersede S-Controls, organizations that have not previously used S-Controls cannot create them, and existing S-Controls are unaffected and can still be edited. That phrasing matters. Deprecation here did not mean a hard switch-off. An org that already had URL S-Controls in Spring '09 kept them, and admins could still open and tweak them. What disappeared was the ability to create brand-new ones in any org that had a clean slate. This is the typical Salesforce sunset shape: freeze new creation, let existing artifacts keep running, and steer everyone toward the replacement. Years later, many of those iframes still linger in long-lived orgs.
What replaces a URL S-Control today
The job a URL S-Control did, putting external web content beside Salesforce data, now has cleaner options. Visualforce is the direct descendant and can host an iframe or apex:iframe component pointing at an external URL, with a controller for any logic. For the Lightning Experience, a Lightning Web Component can render an external page in an iframe inside a Lightning page, giving you a modern, responsive container that survives the Classic-to-Lightning move. For deeper integrations, Canvas apps are the purpose-built answer. Canvas frames a third-party application inside Salesforce but adds a signed handshake, so the external app receives trusted context about the user and org instead of a bare URL. That solves the authentication and security gaps a raw URL S-Control never addressed. The choice comes down to need: a Lightning Web Component for a simple embed, Visualforce when you want server-side control, and Canvas when the external system must know who is looking at it.
Migrating a legacy URL S-Control
If you still run URL S-Controls, treat them as migration debt rather than something to keep. Start by finding them. The Tooling API and Metadata API both expose the Scontrol type, so you can query or retrieve every S-Control and read its contentSource value to isolate the URL ones. That inventory tells you which buttons, tabs, layouts, and dashboards depend on each. For each URL S-Control, the swap is usually small. A web tab can become a Lightning page tab with a component that frames the same address. A layout panel can become a Lightning Web Component on the record page. While you migrate, recheck whether the external site even allows framing today, because security headers have tightened across the web since these were built. Many old iframes that worked in 2009 now render blank. Migrating is also the moment to add proper authentication through Canvas if the embedded tool handles sensitive data.
Trust & references
Cross-checked against the following references.
- Custom S-Control AttributesSalesforce
- How Do Visualforce Pages Compare to S-Controls?Salesforce
Straight from the source - Salesforce's reference material on URL S-Control.
- About S-ControlsSalesforce
- Scontrol | Metadata API Developer GuideSalesforce
Hands-on resources to go deeper on URL S-Control.
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 was a URL S-Control in the legacy Salesforce extensibility model?
Q2. Can an admin create a new URL S-Control in a modern Salesforce org?
Q3. Which modern technologies replace the URL S-Control for embedding external content?
Discussion
Loading discussion…