Custom S-Control
A Custom S-Control is a legacy Salesforce component that allowed administrators to store and execute HTML, JavaScript, or other web content within the Salesforce interface.
Definition
A Custom S-Control is a legacy Salesforce component that allowed administrators to store and execute HTML, JavaScript, or other web content within the Salesforce interface. S-Controls were used to create custom user interfaces, integrate external applications, and add custom behavior to pages. They have been deprecated and replaced by Visualforce pages and Lightning components, which offer better security, performance, and functionality.
In plain English
“Custom S-Controls were an old Salesforce feature for storing HTML and JavaScript that would run inside Salesforce pages. They're deprecated and have been replaced by Visualforce pages and Lightning components, which are safer and more capable.”
Worked example
Larimer Logistics' org has six surviving Custom S-Controls from a 2009 implementation - JavaScript widgets embedded in Visualforce pages that pop custom dialogs from buttons. They've worked for 17 years, but Salesforce deprecated S-Controls in 2010 and any attempt to view them in Lightning throws warnings. The platform team plans a sprint to rewrite each S-Control as a Lightning Web Component invoked from a Quick Action - the modern equivalent - and decommission the legacy code. Until that sprint lands, the S-Controls keep working, but they're a known migration debt the team is explicitly tracking.
Why Custom S-Control matters
A Custom S-Control was a legacy Salesforce feature that let admins store snippets of HTML, JavaScript, or Flash content inside Salesforce and embed them in pages. They were commonly used in the pre-Visualforce era to build custom UI, integrate external content, or add custom behavior to record pages and sidebars. S-Controls could access Salesforce data through the AJAX Toolkit and render arbitrary web content, making them a flexible but increasingly problematic extension point.
S-Controls were deprecated in favor of Visualforce starting in 2009, and new orgs can no longer create them. Existing S-Controls still work in Classic but are not supported in Lightning Experience. Any org that still has S-Controls needs to migrate them to Visualforce pages or Lightning Web Components before moving fully to Lightning. The deprecation was driven by security, performance, and maintainability concerns: S-Controls ran with too few guardrails, and Visualforce and later LWC offered much better security models, versioning, and integration with the platform.
How organizations use Custom S-Control
Discovered a few ancient S-Controls in a legacy sandbox during a modernization audit. They rebuilt the functionality as LWCs and decommissioned the S-Controls as part of their Lightning migration.
Documented every remaining S-Control in a client's org before beginning a Lightning migration. The inventory made the migration plan concrete and surfaced hidden dependencies.
Treats any S-Control encountered in a client org as a migration blocker. Before going Lightning, every S-Control has to be replaced, so they prioritize that work early in the project.
Test your knowledge
Q1. What was a Custom S-Control?
Q2. What replaced S-Controls?
Q3. Do S-Controls work in Lightning Experience?
Discussion
Loading discussion…