S-Control
An S-Control was a legacy Salesforce component that ran custom HTML, JavaScript, and AJAX in the browser to build user interface elements.
Definition
An S-Control was a legacy Salesforce component that ran custom HTML, JavaScript, and AJAX in the browser to build user interface elements. Admins and developers used it to add custom buttons, web tabs, and page-layout content before Visualforce existed.
S-Control is retired. Salesforce labeled it deprecated in the Spring 2009 release, and Visualforce pages superseded it. Organizations that never created an S-Control can no longer make new ones, though any existing S-Controls can still be opened and edited.
How S-Controls worked and why Salesforce moved on
What an S-Control actually was
An S-Control was a container for custom markup and script that Salesforce stored and served on your behalf. The platform called it a "custom content component." You wrote HTML, JavaScript, and CSS, and the S-Control rendered that code inside the Salesforce user interface. It was the first real way to build custom screens on the platform, predating Visualforce by several years. Each S-Control had a content source that decided how it behaved. The HTML source held a full markup snippet. The URL source pointed at an external page. The Snippet source held a reusable block you could pull into other S-Controls. The OnClick JavaScript source ran script when a user clicked a custom button or link, with no page reload. Because so much logic lived in the browser, S-Controls often used the AJAX Toolkit to call the Salesforce API directly from JavaScript. That gave a lot of freedom, but it also meant your business logic ran on the client where it was hard to secure and reuse.
Where S-Controls showed up in an org
S-Controls plugged into several places in Salesforce Classic. The most common was the custom button or link on a record detail page. An OnClick JavaScript S-Control let a button run a quick action, update a field, or call out to another system without leaving the page. Admins also dropped HTML S-Controls onto page layouts so a record screen could show calculated content or an embedded mini-application. Beyond record pages, S-Controls powered web tabs and some dashboard components. A web tab backed by an S-Control gave you a full custom screen that lived next to the standard object tabs. Developers packaged S-Controls into managed packages on the AppExchange too, so an installed app could ship its own custom screens. Because the rendering happened in the browser, the look and feel depended heavily on the script you wrote. Two S-Controls in the same org could behave very differently, which made large deployments hard to maintain over time.
The timeline of deprecation and retirement
Salesforce labeled S-Controls as deprecated in the Spring 2009 release. Deprecation here did not mean instant removal. It was a signal that the technology was frozen and that a replacement, Visualforce, was the path forward. The Spring 2010 release marked the next phase of that wind-down. The practical effect arrived around March 2010. From that point, any organization that had never created an S-Control lost the ability to create one at all. New orgs spun up after that date never saw the feature. Orgs that already had S-Controls kept them, and admins could still open and edit those existing definitions. Salesforce framed this as a long, gentle migration rather than a hard cutoff, because so many early customizations and AppExchange packages relied on S-Controls. That backward-compatible stance is why you can still find live S-Controls in very old orgs today, even though the door to building new ones closed more than a decade ago.
Why Visualforce replaced it
Visualforce pages were built to fix the structural problems with S-Controls. The official guidance is direct: Visualforce pages supersede s-controls, and they should be used instead. The biggest difference is where code runs. An S-Control executed its logic in the browser, while a Visualforce page runs its controller logic on the Salesforce server in Apex. Server-side execution is easier to secure, test, and govern. Visualforce also introduced standard controllers, so a page could bind to an object and reuse built-in save, edit, and list behavior with little code. It added a component model, view state to track form data between requests, and a clean separation between the view markup and the Apex logic behind it. S-Controls had none of that structure. Visualforce pages also run inside the platform governor limits, which keeps a single page from consuming shared resources. For a developer in 2009 or 2010, moving an S-Control to Visualforce meant trading loose browser scripts for a managed, testable framework.
How to think about migration today
If you still see an S-Control in an org, treat it as technical debt to retire, not a pattern to copy. The first step is inventory. Look in Setup under the S-Controls list, and check custom buttons, web tabs, page layouts, and any installed packages for references. The Metadata API and Tooling API both still expose the Scontrol type, so you can pull a full list programmatically for an audit. For the rebuild, the right target depends on the surface. A simple OnClick button can often become a Lightning quick action, a screen flow, or a Lightning Web Component action. A full custom screen is usually best rebuilt as a Lightning Web Component, which is the current standard for new interfaces. Visualforce remains supported and is a valid stepping stone, especially if the org is still heavy on Salesforce Classic. The point is that no new work should start from an S-Control. Plan the move deliberately, test the replacement, then remove the old S-Control once nothing references it.
A worked example: a custom Close button
Picture an early Salesforce org around 2008. A team wanted a button on the Case detail page that set Status to Closed and stamped a closed date, all without a page reload. The admin built an OnClick JavaScript S-Control. The script grabbed the record Id from a merge field, called the AJAX Toolkit to run an update against the API, then refreshed the page. It worked, and it shipped fast. The trouble showed up later. The logic lived in browser JavaScript, so it could not be unit tested and was hard to reuse across objects. A browser change or an API version bump could break it silently. When Visualforce arrived, the same button became a small Visualforce page with an Apex controller that performed the update server-side, inside governor limits, with a test class behind it. Today that same need would likely be a screen flow or a Lightning Web Component quick action. The example shows the arc: S-Controls solved a real problem early, and each newer tool made that solution safer and easier to maintain.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on S-Control.
Hands-on resources to go deeper on 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 is an S-Control?
Q2. Should you use S-Controls today?
Q3. What's the modern alternative?
Discussion
Loading discussion…