Web Control
A Web Control, more commonly called an S-Control, was a legacy Salesforce feature for embedding custom HTML and JavaScript inside the user interface.
Definition
A Web Control, more commonly called an S-Control, was a legacy Salesforce feature for embedding custom HTML and JavaScript inside the user interface. Admins and developers used S-Controls to add interactive elements to custom buttons, links, Web tabs, page layouts, dashboards, and Home page components. The control could display almost anything a browser could render, including a Java applet, an ActiveX control, an Excel file, or a custom HTML web form.
This feature is retired. Salesforce labeled S-Controls deprecated in the Spring '09 release and stopped letting organizations create new ones in early 2010. Visualforce replaced them, and orgs that never used S-Controls cannot create them at all. Treat any surviving S-Control as a migration candidate.
From S-Controls to Visualforce: the story of Salesforce's first custom UI
What an S-Control actually was
An S-Control was a stored snippet of HTML, JavaScript, or other browser content that Salesforce served inside the application. The "S" was often read as "Super," and the feature gave teams their first real way to put custom logic in front of users. You could attach an S-Control to a custom button or link, surface it as a Web tab, drop it into a page layout, or pin it to a dashboard or Home page component. Because the content type was open, an S-Control could hold a custom HTML web form, a Java applet, an ActiveX control, or even an embedded Excel file. That flexibility made S-Controls popular in the early platform years. It also made them fragile. Each S-Control was hand-written front-end code with no native binding to Salesforce data. To read or write records, the JavaScript inside the control had to call the API directly, usually through the AJAX Toolkit. The platform did not validate fields or enforce layout rules for you. Everything was the author's responsibility, which is part of why Salesforce eventually moved on.
Why Salesforce retired it
Salesforce deprecated S-Controls in the Spring '09 release and removed the ability to create or distribute new ones in early 2010. The core problem was the execution model. An S-Control ran inside an iframe, isolated from the rest of the page, rather than rendering natively on the platform. That isolation meant the control could not inherit Salesforce styling automatically, could not reuse standard components, and could not bind input fields straight to database columns. Developers wrote manual JavaScript and API calls for tasks that the platform should have handled. Every data read or write became a separate round trip to the server, so pages felt slow and chatty compared to server-rendered output. Validation also fell on the author. To respect a field's uniqueness or required status, the S-Control had to make describe calls and check the rules by hand. Maintenance costs piled up as orgs accumulated bespoke scripts that nobody wanted to touch. Visualforce solved these issues directly, so Salesforce pointed everyone toward it and froze S-Controls in place.
Visualforce, the official replacement
Visualforce pages supersede S-Controls, and the official guidance is to use Visualforce whenever possible for better performance and easier authoring. The difference starts with where code runs. A Visualforce page renders natively on the Lightning Platform and generates its markup on the server, so it is more responsive than an iframe full of client-side scripts. Visualforce uses a tag-based markup language instead of procedural JavaScript, and it ships with a library of standard components you can drop in. Input components bind directly to record fields, so the platform writes values back to the database without custom API code. A Visualforce page can use a standard controller to reach record data straight away, where an S-Control had to call Apex web service methods through the API. Visualforce inherits Salesforce stylesheets automatically and honors field metadata such as uniqueness and required rules without hand-written describe calls. For teams maintaining an old S-Control, rebuilding the same behavior as a Visualforce page usually means less code and fewer moving parts.
Where S-Controls used to live
Part of what made S-Controls feel powerful was how many places accepted them. A custom button or link on a record could fire an S-Control to run a calculation, call an external system, or pop a custom screen. A Web tab could host an entire S-Control as a full-page experience. Page layouts could embed an S-Control section so a record page showed live custom content next to standard fields. Dashboards and Home page components could surface S-Control output too, which let admins show charts or widgets the native tools did not offer yet. Because the feature touched so many surfaces, retiring it was not a single swap. An org migrating away has to inventory every button, link, tab, layout, and component that points at an S-Control, then decide what each one should become. Some convert to Visualforce pages. Others become Lightning components, Flows, or simple JavaScript-free configuration once newer features cover the original need. The breadth of the integration is exactly why a careful audit matters before you delete anything.
Migrating off a surviving S-Control
If your org still has S-Controls, they keep working but they are technical debt. Start by listing them in Setup and tracing where each one is referenced, since a control can be wired to several buttons or layouts at once. For each control, read what it does before you assume Visualforce is the answer. A control that only opened a URL or ran a small piece of JavaScript on click might convert to a simple custom button with a URL or OnClick JavaScript source, or better yet to a Flow that needs no code. A control that rendered a custom form or dashboard widget is a strong candidate for a Visualforce page or a Lightning Web Component. Rebuild the behavior in the modern feature, repoint the button, link, tab, or layout to the new target, and test in a sandbox before you remove the old control. Keep in mind that orgs which never used S-Controls cannot create them, so there is no path to add new ones if you delete a control you still need. Document each replacement so the next admin understands the history.
What replaced S-Controls in modern Salesforce
Today the custom UI toolkit is much larger than the single S-Control mechanism. Visualforce was the direct successor and is still supported for server-rendered pages and email templates. For component-based work, the Aura component framework arrived with Lightning, and Lightning Web Components now serve as the standard, standards-based way to build fast, reusable UI. For logic that admins want without code, Flow handles screen flows, record-triggered automation, and guided processes that an S-Control once approximated with hand-written scripts. Custom buttons and links still exist as configuration and can call a Visualforce page, a Lightning component, or a Flow instead of an S-Control. The practical takeaway is that there is no scenario in current Salesforce where a new S-Control is the right tool, because every job it used to do has a supported, better-performing home. Knowing the term still matters when you inherit an older org, read release notes about deprecated features, or study how the platform's customization model evolved from raw browser snippets into governed, native components.
Trust & references
Cross-checked against the following references.
- About S-ControlsSalesforce
- How Do Visualforce Pages Compare to S-Controls?Salesforce
Straight from the source - Salesforce's reference material on Web Control.
Hands-on resources to go deeper on Web 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 did a Web Control refer to in the legacy Salesforce customization model?
Q2. Should an admin build new functionality on Web Control components in a modern org?
Q3. Which technology family superseded the interactive UI role that Web Controls once filled?
Discussion
Loading discussion…