Custom S-Control
A Custom S-Control is a legacy Salesforce component that stored HTML, JavaScript, ActiveX, or Java content directly inside Salesforce metadata and ran it inside the Salesforce interface to provide custom UI or behavior.
Definition
A Custom S-Control is a legacy Salesforce component that stored HTML, JavaScript, ActiveX, or Java content directly inside Salesforce metadata and ran it inside the Salesforce interface to provide custom UI or behavior. S-Controls were the original answer to how to extend the Salesforce UI before Visualforce existed. They could render as full pages, embedded HTML blocks, or custom buttons that fired JavaScript.
Salesforce shipped S-Controls in the early 2000s, deprecated them in 2008 when Visualforce arrived as the structured replacement, and stopped issuing new S-Control IDs in 2010. Existing S-Controls continue to work in long-running orgs but cannot be created from scratch in any new org. Most have been migrated to Visualforce or Lightning by now; the remaining ones are typically small utility scripts that no one has rewritten because they still happen to work.
What S-Controls were and what they became
The S-Control model
An S-Control was a metadata record on the CustomSControl object holding a blob of HTML, JavaScript, or other web content. Admins created S-Controls in Setup, gave them a name, pasted content into the body field, and saved. Salesforce served the S-Control content to the browser when a user accessed a page that referenced it.
How S-Controls were used
The three common uses were custom pages (an S-Control could be a full screen replacing the standard Salesforce UI for a specific tab or button), embedded panels (an S-Control rendered inside a record page sidebar), and custom buttons (a button click executed S-Control JavaScript that called the Salesforce SOAP API and manipulated records). S-Controls predated AJAX in mainstream web development and pioneered the pattern for Salesforce.
Why S-Controls were deprecated
S-Controls had no Salesforce-managed security boundary. JavaScript in an S-Control ran with the user full session ID accessible, which made cross-site scripting attacks trivial. Multi-tenant isolation was weak. The server-side rendering Salesforce added later for Visualforce was impossible to add to S-Controls. By 2008, S-Controls were a clear security and architectural liability.
Visualforce as the replacement
Visualforce shipped in 2008 as the structured, secure replacement for S-Controls. It introduced server-side rendering, an Apex-backed controller model, automatic CSRF protection, and an XML-based markup syntax. Salesforce migrated S-Control patterns to Visualforce equivalents and deprecated S-Controls in the same release.
Why the migration took so long
S-Controls are still present in many long-running Salesforce orgs because the migration is per-S-Control work. Each S-Control has to be rewritten as a Visualforce page or Lightning component, tested, and swapped in. For mature orgs with dozens of S-Controls scattered across page layouts and custom buttons, the migration was project-scale work that often got deprioritized. Salesforce never forced retirement of working S-Controls.
What S-Controls still do in 2026
The few S-Controls still alive are typically read-only display panels or static informational widgets. Anything with API interaction has long since been rewritten because the SOAP API patterns S-Controls used have evolved and the JavaScript is brittle. Static HTML panels just keep working because Salesforce has not removed the rendering path.
Migration path to modern Lightning
The right migration in 2026 is to Lightning Web Components, not Visualforce. The work: read the S-Control content, identify what it does (display data, run a button action, render a form), build an equivalent LWC, place the LWC on the same page layout, and remove the S-Control reference. Test in sandbox first; some S-Controls have subtle dependencies on Classic-only behaviors that LWC handles differently.
How to migrate Custom S-Controls to Lightning
S-Controls cannot be created new and cannot be modernized in place. The migration is per-S-Control: build an LWC equivalent, swap references, retire the original.
- Inventory existing S-Controls
From Setup, search for S-Controls. List every Custom S-Control in the org with its name, body length, and where it is referenced (page layouts, custom buttons, custom tabs).
- Categorize by purpose
Static display panels (lowest effort), API-calling buttons (medium effort), full UI pages (highest effort). Migrate easiest first to build momentum.
- Build equivalent LWC
For each S-Control, write an LWC that does the same thing. Reuse standard SLDS styling, call Apex through AuraEnabled methods, and place on the same locations the S-Control occupied.
- Update page layouts and buttons
Replace the S-Control reference with the LWC. Test the page renders correctly and the LWC behaves like the S-Control did.
- Retire the S-Control
Once all references are swapped, delete the S-Control metadata. Document the migration so successor admins know the LWC is the canonical replacement.
- Repeat across all S-Controls
Work through the backlog. Long-running orgs may have 50 to 100 S-Controls; the migration is project-scale.
- New S-Controls cannot be created in any org after 2010. If you find an S-Control feature you want to extend, the only path is migration.
- S-Controls store full HTML and JavaScript with no security boundary. Any S-Control with API logic is a potential security risk if compromised; audit before retiring.
- Some S-Controls have hard dependencies on Salesforce Classic. LWC migration may require Classic-only behavior simulation; document the gap.
- Custom buttons that fire S-Control JavaScript do not auto-migrate when you build the LWC. Update the button to call the LWC method explicitly.
- Removing an S-Control with active references silently breaks the page. Always swap references first, then delete.
Trust & references
Straight from the source - Salesforce's reference material on Custom S-Control.
- Visualforce Developer GuideSalesforce Developers
- S-Controls Overview (Legacy)Salesforce Help
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 Custom S-Control?
Q2. What replaced S-Controls?
Q3. Do S-Controls work in Lightning Experience?
Discussion
Loading discussion…