HTML S-Control
An HTML S-Control is a now-retired Salesforce feature for embedding custom HTML, JavaScript, or CSS inside a Salesforce page.
Definition
An HTML S-Control is a now-retired Salesforce feature for embedding custom HTML, JavaScript, or CSS inside a Salesforce page. S-Controls were the first supported way for developers to extend the Salesforce user interface with their own code, and the HTML type was the most common. An admin created an S-Control of type HTML, pasted in markup, and referenced it from a custom button, a link, or a page section. The browser rendered that markup in an iframe within the Salesforce page, and the code reached Salesforce data through the AJAX Toolkit, a JavaScript wrapper around the SOAP API.
S-Controls are retired. Salesforce replaced them with Visualforce, and the official guidance is plain: Visualforce pages supersede S-Controls and should be used instead. Orgs that never used S-Controls cannot create them, so the feature is closed to new development. Existing S-Controls still render in Salesforce Classic for backward compatibility, but they do not work in Lightning Experience at all. Any org still carrying live S-Controls needs a migration to Visualforce, Aura components, or Lightning Web Components before it can finish moving to Lightning.
How HTML S-Controls worked and why they were retired
The first way to customize the Salesforce UI
Salesforce launched with a fixed user interface and no native framework for changing it. Customers still wanted custom screens, pop-ups, and embedded tools, so the S-Control filled that gap. An S-Control could hold any content a browser can run, including a Java applet, an ActiveX control, an Excel file, or a custom HTML web form. The HTML type was the workhorse, because it let a developer paste plain markup and script directly into Salesforce. The platform rendered that content inside an iframe on the page. From there, JavaScript in the S-Control called back to Salesforce through the AJAX Toolkit to read and write records. This model powered a generation of early AppExchange apps and internal customizations through the mid-2000s. It was flexible, but it pushed almost all of the work into the browser, which is exactly where its limits started to show.
Everything ran in the browser
An S-Control had no server-side processing on the Salesforce platform. Every interaction depended on JavaScript running in the user browser, with calls back to Salesforce over the AJAX Toolkit. That design carried real costs. Pages felt slow, because each action could mean several API round trips before the screen updated. There was no platform-supplied component library, so each S-Control reinvented basic input fields, buttons, and layout. There was no automatic data binding, which meant a developer had to write code by hand to enforce field rules like required values or uniqueness. Styling did not inherit from Salesforce, so matching the standard look took extra effort. Each S-Control became a small, custom application that the author had to maintain on their own. As the Salesforce surface area grew, this approach produced fragile, inconsistent customizations that were expensive to keep working.
Visualforce arrived as the replacement
Salesforce introduced Visualforce as the next generation of S-Controls, and the documentation is direct about it: Visualforce pages should be used instead of S-Controls wherever possible. The advantages were concrete. Visualforce markup renders on the server, so pages are more responsive than S-Controls that needed multiple API round trips. Building a page takes only HTML and a tag-based markup language, instead of procedural JavaScript and AJAX Toolkit expertise. Visualforce interacts with Apex directly through custom controllers, and it reaches standard platform behavior through standard controllers. Input fields bind to records automatically, so metadata rules like uniqueness are enforced without hand-written code. A standard component library ships with the framework, and pages inherit Salesforce styling on their own. Each of those points maps to a specific S-Control weakness, which is why Salesforce framed Visualforce as the clear path forward.
What the feature looks like in Salesforce today
S-Controls still exist as a metadata type so older orgs do not break. In Setup, an admin enters S-Controls in the Quick Find box and selects S-Controls to see any the org already has. The hard rule is that orgs which never used S-Controls cannot create them, which closes the door on new ones. The Salesforce documentation also notes that existing S-Controls are unaffected and can still be edited, so legacy logic can be touched if it must be. The far more important constraint is rendering. S-Controls are available in Salesforce Classic only. They do not render in Lightning Experience. A custom button or link that points at an S-Control simply fails for any user working in Lightning, which turns every surviving S-Control into a visible break the moment that user moves off Classic.
Choosing a migration target
Migrating an S-Control depends entirely on what it did. A simple HTML pop-up or static screen can become a Visualforce page that reuses much of the same markup. An interactive form is a better fit for a Lightning Web Component backed by Apex methods, which gives a modern, supported, and testable result. A custom dashboard or landing screen often belongs in a Lightning App Builder page assembled from components. The work is rarely a copy and paste. S-Control JavaScript was frequently written before modern Apex and modern client frameworks existed, so the logic usually has to be rewritten rather than transplanted. The upside is that the rewrite removes the AJAX Toolkit dependency, moves validation and data access onto supported APIs, and produces something that fits current Salesforce development instead of fighting it.
The Lightning cutover forces the cleanup
The move to Lightning Experience is the single biggest reason teams finally retire their S-Controls. Salesforce has spent years moving every customer toward Lightning, and an org still on Classic with active S-Controls cannot complete that move while those controls remain. Because S-Controls do not render in Lightning, each one is a blocker, not a cosmetic issue. For that reason it is best to treat S-Control migration as part of the Lightning cutover plan rather than as a separate cleanup task that gets postponed. Before migrating, search the org thoroughly. References hide in custom buttons, custom links, page layouts, and email templates, and a missed reference becomes a broken control in production. Inventory every S-Control, map each one to a target, and schedule the rewrites alongside the cutover so the work actually happens.
Where S-Controls sit for certification
Older Salesforce Platform Developer and App Builder study material referenced S-Controls, but current exams have moved on. For modern certification, the useful facts are narrow. S-Controls existed as the first UI extension model, they relied on the AJAX Toolkit and ran in the browser, Visualforce replaced them, and they do not render in Lightning Experience. That is the full extent of what a current candidate needs. No current platform design should reach for an S-Control, and no current exam tests building one. Treat the topic as historical context that explains why Visualforce and the Lightning component frameworks look the way they do. Understanding the limits of the S-Control model also makes the design choices in Visualforce and Lightning Web Components easier to appreciate, since each of those frameworks was shaped partly by the problems S-Controls left behind.
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 HTML S-Control.
- Defining Custom S-ControlsSalesforce
- AJAX Toolkit Developer GuideSalesforce
Hands-on resources to go deeper on HTML 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. Why were HTML S-Controls considered fragile compared with their successor framework?
Q2. Which framework did Salesforce launch in 2008 as the supported replacement for HTML S-Controls?
Q3. What is the current state of HTML S-Controls in a Salesforce org that still has them?
Discussion
Loading discussion…