Article-Type Template
An Article-Type Template was a Salesforce Knowledge setting that controlled how an article's sections rendered to readers in each publishing channel.
Definition
An Article-Type Template was a Salesforce Knowledge setting that controlled how an article's sections rendered to readers in each publishing channel. In Classic Knowledge, every Article Type was assigned a template per channel, and that template decided whether the article's sections appeared as clickable tabs, as a single page with a table of contents, or as a fully custom Visualforce layout. The two standard choices were Tab and Table of Contents, and admins could swap them per channel without writing code.
This is a legacy concept. It belonged to the Classic Knowledge data model, and that model is no longer available as of the Summer '25 release. Lightning Knowledge replaced article types and their templates with standard objects, page layouts, and the Knowledge Article component configured through Lightning App Builder and Experience Builder. You will still see Article-Type Template mentioned in older implementation guides, certification prep, and partner blogs, but it no longer maps to a setting you can configure in a current org. Treat any reference to it as historical and translate it to the Lightning equivalent.
How article-type templates shaped Knowledge presentation
Templates versus layouts: two different settings
Classic Knowledge separated two things that people often confused. The Article-Type Layout controlled the edit-time experience, meaning which fields and sections an author saw while writing. The Article-Type Template controlled the read-time experience, meaning how those same sections appeared to someone reading the published article. You configured both on the Article Type, but they answered different questions. The layout grouped fields into sections for the author. The template then decided how a reader moved through those sections. A Knowledge article about a multi-step return process might have five sections defined in its layout. The template determined whether a customer saw those five sections stacked on one long page, split across tabs, or listed as anchor links at the top. Because the layout and template were set separately, you could redesign the reading experience without touching the authoring form, and vice versa. Admins who skipped the template setting got the channel default, which sometimes surprised them when an internal article looked different on the public site. Understanding the split is still useful when you read old documentation that mentions both.
The Tab and Table of Contents standard templates
Salesforce shipped two standard templates, and most orgs never needed more. The Tab template turned each section defined in the article-type layout into a separate tab. A reader clicked across tabs to move between sections, which suited short, distinct chunks of content such as Symptom, Cause, and Resolution. The Table of Contents template did the opposite. It placed every section on a single scrolling page and generated hyperlinks at the top so a reader could jump to any section. That layout suited long reference articles where someone wanted the whole thing on one page but still needed quick navigation. The default depended on the channel. The internal app and the Customer Portal defaulted to Tab. The public knowledge base defaulted to Table of Contents, on the assumption that anonymous searchers preferred a scannable single page. You set the template per channel from the Article Type, so the same content could appear as tabs to agents and as a table of contents to the public. This per-channel control was the practical heart of the feature.
Custom Visualforce templates for branded layouts
When the two standard templates did not fit, developers built custom templates as Visualforce pages. A custom template was a Visualforce page that read the article's fields and rendered them in whatever HTML, CSS, and markup the brand required. This is where multi-column layouts, image-heavy walkthroughs, embedded video, and tightly branded support sites came from. The page had full control, so a developer could ignore the section model entirely and lay out fields by hand. Once written, the custom template appeared in the same per-channel picklist on the Article Type, alongside Tab and Table of Contents, and an admin selected it like any standard option. The trade-off was maintenance. A custom Visualforce template was code, so it needed testing, version control, and someone who understood Visualforce when the design changed. Standard templates updated themselves as Salesforce evolved, but a custom page stayed exactly as written until a developer revisited it. Many orgs that adopted custom templates later found them to be the hardest part of a Lightning migration, because the markup had no automatic equivalent and had to be rebuilt by hand.
Why the template choice changed reader experience
The template setting looked minor in Setup but shaped how readers actually used an article. A ten-section troubleshooting guide rendered under the Tab template forced a reader to click through ten tabs, which buried later content and hurt anyone scanning for one specific step. The same article under the Table of Contents template put everything on one page with jump links, which scanned far better but could feel overwhelming on a phone. Support teams that measured article usefulness sometimes traced low ratings back to a template mismatch rather than to the writing itself. Channel context mattered too. An agent inside a console wanted compact tabs so the article did not crowd out the case. A public searcher arriving from Google wanted the full page so they could confirm at a glance that the article answered their question. Because the template was set per channel, a thoughtful admin tuned each surface to its audience. Teams that left every channel on its default missed this lever entirely. The lesson carries into Lightning, where the equivalent component configuration still decides whether readers can find what they came for.
What Lightning Knowledge replaced it with
Lightning Knowledge removed the explicit template setting and split its job across newer tools. Article fields now live on standard page layouts, the same kind used by every other object, so the section grouping that the old layout handled moved into ordinary layout configuration. The read-time presentation moved to components. On internal record pages and in Lightning console apps, the Knowledge Article component renders the article, and you configure it through Lightning App Builder. On public sites, Experience Builder hosts the article presentation inside an Experience Cloud Help Center. There is no per-channel template picklist anymore because the channel is now defined by which Lightning page and which component you build. The Tab style maps loosely to a record page with tabbed components, and the Table of Contents style maps to a single page with the article rendered top to bottom. Custom Visualforce templates have no direct successor setting. Their closest equivalent is a custom Lightning Web Component that reads the article fields and renders branded markup, then gets dropped onto the page in App Builder or Experience Builder. The use case survived, but the technology and the configuration path are entirely different.
Reading old docs and planning a migration
Because the Classic data model is gone as of Summer '25, you will only meet Article-Type Template in historical material. When an implementation guide from a few releases back tells you to choose a template per channel, read it as background, not as a task you can perform today. The practical work now is migration planning. Before moving off Classic, inventory which template each Article Type used per channel, because that record tells you what reading experience you are expected to reproduce in Lightning. Article types on Tab usually become record pages with tabbed or sectioned components. Article types on Table of Contents usually become a single Lightning page with the Knowledge Article component. Any article type pointing at a custom Visualforce template needs a developer to rebuild the markup as a Lightning Web Component, and that work is invisible until someone tries to migrate without budgeting for it. Document the new model after cutover too, because future admins will go looking for a template setting that no longer exists. Clear notes about which component renders each channel save the next person from searching Setup for a control that Salesforce retired.
Trust & references
Cross-checked against the following references.
- Article-Type TemplatesSalesforce
- Migrate Your Classic Knowledge Base to Lightning KnowledgeSalesforce
Straight from the source - Salesforce's reference material on Article-Type Template.
- Article-Type TemplatesSalesforce
- Add Table of Contents to Knowledge Article PagesSalesforce
Hands-on resources to go deeper on Article-Type Template.
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. In Classic Knowledge, what did an Article-Type Template govern?
Q2. When an org moves to Lightning Knowledge, what replaces the Article-Type Template concept?
Q3. Why does the Table of Contents Article-Type Template matter to customer experience?
Discussion
Loading discussion…