Inline S-Control
An Inline S-Control is a retired Salesforce feature that embedded custom HTML, JavaScript, or CSS directly into a section of a record detail page, rendering inside an iframe alongside the standard page layout fields.
Definition
An Inline S-Control is a retired Salesforce feature that embedded custom HTML, JavaScript, or CSS directly into a section of a record detail page, rendering inside an iframe alongside the standard page layout fields. It was a placement variant of the broader HTML S-Control feature. Instead of sitting behind a custom button or link, an Inline S-Control appeared right on the page so users saw the custom UI without clicking anything.
Inline S-Controls are retired. Salesforce deprecated the whole S-Control family with the Spring '09 release, and from Spring '10 (rolling out in early 2010) any org that had never used S-Controls could no longer create them. Visualforce pages supersede S-Controls, and existing S-Controls remain editable only in Salesforce Classic. They do not render in Lightning Experience. The modern replacement is a Visualforce page added to the layout as an inline Visualforce area, or a custom component placed on a Lightning record page.
From embedded iframe to native page region
What an S-Control actually was
A custom S-Control was content that Salesforce hosted but the browser executed on the client side. The official description says an S-Control can hold any content you can display or run in a browser, for example a Java applet, an ActiveX control, an Excel file, or a custom HTML web form. In practice most teams used HTML and JavaScript with the AJAX Toolkit to read and write records. The platform stored the markup, served it inside an iframe, and let the client code call the API for data. That client-executed model is the root of why S-Controls aged poorly. Every data read or write was a round trip the developer had to code and optimize by hand. There were no built-in field components and no automatic data binding. The Inline placement was one of several ways to surface an S-Control. Others included custom buttons, custom links, web tabs, dashboards, and custom-object online help. The Inline option was special because it put the custom content directly on the record detail page rather than one click away.
How the inline placement worked on a layout
An admin built the S-Control in Setup, then opened the page layout editor for the object and dropped the S-Control into a section of the detail page. The platform rendered it as an iframe at a fixed height the admin set. Because each section was independent, a single layout could carry more than one inline area, each pointing at a different S-Control. The parent Salesforce frame and the iframe communicated through the browser, and the S-Control's JavaScript used the AJAX Toolkit to pull related data or post updates. This pattern gave admins a way to show custom mini-views without writing a custom page from scratch in a server framework. Teams used it for small summary panels, related-record rollups, embedded reports, and third-party widgets that needed a home on the record. The trade-off was that the iframe sat outside Salesforce's own styling and validation. The S-Control had to load its own stylesheet, and it only enforced required fields or uniqueness rules if the developer wrote that logic by hand.
Why Salesforce retired the S-Control family
Salesforce introduced Visualforce in 2008 and positioned it as the next generation of S-Controls. The official guidance is blunt: use Visualforce instead of S-Controls whenever possible. The deprecation followed quickly. S-Controls were marked deprecated in Spring '09, and the next step landed in Spring '10, when orgs with no prior S-Control history lost the ability to create new ones. The reasons were technical. Visualforce markup is generated on the platform, so pages render more responsively than an S-Control that fires a separate API round trip for every operation. Visualforce ships a standard component library with automatic data binding, so a value typed into a field saves to the database without custom save code. It uses native containers and inherits Salesforce stylesheets automatically, while S-Controls render in iframes and need manual styling. Visualforce respects field metadata such as required and unique constraints, and it talks to Apex directly through custom controllers instead of the indirect web-service calls S-Controls relied on. Every one of those gaps was a daily cost for S-Control maintainers.
The Visualforce inline replacement
The closest like-for-like replacement for an Inline S-Control is a Visualforce page added to the layout as an inline Visualforce area. The admin builds a page with an apex:page tag, optionally backed by a standard or custom Apex controller, then edits the page layout and drops a Visualforce area into a section just as they once dropped an S-Control. The visual result is similar, a custom panel sitting on the record detail page, but the engineering is far cleaner. The page can bind directly to record fields, reuse standard Visualforce components, and inherit Salesforce styling without extra work. Apex controller logic runs server side under the platform's governor limits rather than as loose client JavaScript. For many orgs this is the fastest migration because the mental model maps one to one: an embedded area on a layout becomes another embedded area on the same layout. The caveat is that Visualforce itself is older technology now, so teams planning for the long term often skip straight to a Lightning-native component instead of investing in new Visualforce.
The Lightning-native path
For orgs on Lightning Experience, the durable replacement is a custom component placed on a Lightning record page rather than a page layout. A Lightning Web Component reads the record context, renders custom markup, and runs under Lightning's security model. The component drops into a region of a Lightning record page through the Lightning App Builder, which is the drag-and-drop successor to the page layout editor for record page composition. This path matters because Inline S-Controls do not render in Lightning Experience at all. An org can switch its users to Lightning, but anywhere an S-Control used to appear the region shows up empty. That blank space is the visible signal of unfinished migration work. Lightning's component runtime is also stricter than the old S-Control sandbox, so some legacy JavaScript patterns that worked inside the loose iframe will not run unchanged. Plan to rewrite the logic, not just relocate it. The upside is a component that is responsive, theme-aware, and supported on the platform Salesforce actually invests in.
Packaged S-Controls and migration debt
Some older AppExchange packages were built on S-Controls, and a few used the inline placement to surface their UI on records. Those packages carry extra baggage. The documentation notes that an S-Control inside a package forces Unrestricted API access, and you cannot switch a package to Restricted API access once an S-Control is added. New orgs also cannot create S-Controls, so a package that depends on them will not install cleanly on a fresh org and may not behave correctly under Lightning. If you inherit an org running such a package, the practical move is to ask the vendor for a Lightning-ready version or replace the functionality with a modern package. The same housekeeping applies to home-grown S-Controls. After you migrate the logic to Visualforce or a Lightning component, delete the old S-Control metadata. Leaving retired S-Controls in place pollutes change sets and packages, skews metadata inventory reports, and tempts the next admin into copying a pattern that the platform abandoned more than a decade ago.
Reading old docs without getting burned
Plenty of older Salesforce training material, community posts, and AppExchange listings still describe Inline S-Controls as a normal way to extend a record page. Treat all of it as history. The current platform answer is a Visualforce inline area or a Lightning component, and the S-Control create-and-edit interface is gone for any org that did not already have S-Controls. When you audit an inherited org, search Setup for existing S-Controls, note which page layouts reference them, and check whether the org is on Lightning Experience yet. If it is, the inline regions are already dark. If it is still on Classic, you have a working but fragile feature that will break the moment Lightning becomes mandatory for those users. Either way the destination is the same. Catalog the S-Controls, decide Visualforce versus Lightning per panel based on how long the feature needs to live, rebuild the logic against a supported framework, place it back on the record, then remove the dead S-Control. Following a fifteen-year-old doc verbatim is the fastest way to ship something that cannot run.
Trust & references
Cross-checked against the following references.
- How Do Visualforce Pages Compare to S-Controls?Salesforce
- About S-ControlsSalesforce
Straight from the source - Salesforce's reference material on Inline S-Control.
Hands-on resources to go deeper on Inline 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 was an Inline S-Control in Salesforce Classic?
Q2. In Salesforce Classic, how did an admin surface an Inline S-Control on a record?
Q3. What is the recommended replacement for an Inline S-Control on a Lightning Record Page?
Discussion
Loading discussion…