Article Type
An Article Type is a Classic Salesforce Knowledge construct that defined one kind of article, such as an FAQ, a How-To, a Procedure, or a Release Note.
Definition
An Article Type is a Classic Salesforce Knowledge construct that defined one kind of article, such as an FAQ, a How-To, a Procedure, or a Release Note. Each Article Type was its own custom object with a __kav suffix (short for KnowledgeArticleVersion). It carried a Title plus type-specific fields, its own page layouts, and its own permissions. Authors picked a type, and that choice decided which editor and which fields they saw. Every new kind of article meant a brand new custom object, so the model grew heavy fast.
Lightning Knowledge replaced this design. Instead of many objects, it uses one Knowledge object with Record Types that distinguish the kinds. The functional behaviour carries over, but the schema is far simpler. Most production orgs have finished moving from Classic Knowledge to Lightning Knowledge using a supported migration tool. The phrase Article Type still shows up in older Help pages, blog posts, and some certification material, where it points at the Classic concept rather than current Lightning behaviour. If you read it in a recent context, translate it to Record Type.
From per-type objects to one Knowledge object
How the Classic Article Type was built
Each Article Type was a separate custom object whose API name ended in __kav. The base object is Knowledge__kav, available in API version 39.0 and later, and it represents a single article version. Fields, page layouts, validation rules, and permissions all attached to that specific object. An FAQ type and a How-To type were two different objects with two different schemas. Creating a new kind of article was not a small admin task. It meant defining a new object, building its fields, wiring its layouts, and granting access through profiles or permission sets. Reporting followed the same pattern. A custom report type targeted FAQ__kav or How_To__kav by name, not a generic Knowledge target. Integrations behaved the same way. Apex, SOQL, and external API calls referenced the concrete object name, so each type was a hard dependency in code. This gave teams precise control, but it also meant the data model expanded every time the content strategy grew. Five kinds of article produced five objects to maintain, secure, and report on.
Why Salesforce moved to Record Types
The per-type model created real overhead. An org with five Article Types had five objects, each needing its own field setup, sharing rules, permission assignments, and report types. Cross-type reporting was painful because you could not query one object and see every article. Lightning Knowledge solved this by collapsing the design into a single Knowledge object. Record Types now play the role that separate Article Types used to play. A Record Type like FAQ or Procedure carries its own page layout and its own picklist values, while every record lives on the same underlying object. The practical win is large. Adding a new kind of article becomes an admin-only change, a Record Type plus a page layout, rather than a full object build. Reporting spans every Record Type at once because the data sits in one place. Permissions get simpler too, since access is granted on one object and refined per Record Type. The flexibility that teams valued in Article Types survives, but the cost of maintaining it drops sharply.
How Record Types map to Article Types
The mapping is direct in concept and detailed in practice. Each Classic Article Type becomes one Record Type on the unified Knowledge object. The fields that lived on the old object get consolidated onto the shared object, and the migration step is where field mapping happens. This is rarely a clean one-to-one copy. Lightning Knowledge has its own set of standard fields, so a Question field on an FAQ type and a Symptom field on a Procedure type both need a deliberate target on the new object. Where two types used differently named fields for similar data, you decide whether to merge them into one shared field or keep them distinct and control visibility through the Record Type page layout. Picklist values that were specific to a type move to that Record Type. One behaviour change matters for end users. Because Lightning Knowledge uses Record Types instead of Article Types, you can no longer filter article lists by Article Type the way Classic allowed. Teams plan for that shift in their list views and search filters.
Running the Lightning Knowledge Migration Tool
Salesforce provides a migration tool that does the heavy lifting of converting Article Types to Record Types. It is enabled by default in sandboxes, which is where you test. For production, you log a request with Salesforce Support to turn it on. The tool behaves differently depending on your starting point. Orgs with a single Article Type follow a simpler path. Orgs with multiple Article Types go through a validation stage where you confirm the field mapping across types before activation. The work runs in phases. You migrate in a full-copy sandbox first so you can test against real data and volume. You map fields across every Article Type, freeze user changes during the run, and schedule it for off-peak hours. After activation you verify that page layouts came across correctly and edit them where needed. Most mid-sized programs complete the effort in weeks. Large knowledge bases with many types, heavy customisation, and external integrations can take months of planning and staged execution.
What migrates and what does not
Knowing the boundary saves projects from surprises. Article data and related records migrate, including links to cases, data categories, votes, view counts, and the article feed. Page layouts migrate automatically, though admins must review and edit them afterward because Record Type layouts work differently. Compact layouts for mobile pages come across too. Files that lived in custom fields move to the standard Files object. Several things do not migrate and must be rebuilt by hand. Formulas and field dependencies do not carry over. Dependent picklists do not migrate. Custom code does not migrate, which means Apex classes, triggers, and Visualforce pages that referenced the old Article Type objects need refactoring. Validation rules need recreation. SOQL queries that named a concrete object like FAQ__kav must be rewritten to target the unified Knowledge object with a Record Type filter. Some AppExchange packages built for Classic Knowledge may need updated versions. Treat this list as a checklist during planning, because each item is a separate task with its own owner and test.
Reporting and integration impact
The change from objects to Record Types ripples through everything that reads Knowledge data. Reports built on Classic Article Type objects do not work against Lightning Knowledge, so every Knowledge report and dashboard gets rebuilt on the new object. The upside is that a single report can now span all Record Types, which was hard in Classic. External integrations feel the change most sharply. An ETL job, a middleware connector, or a partner API that queried FAQ__kav by name will break unless it is updated to call the unified Knowledge object and filter by Record Type. The same applies to any Apex web service or REST callout that hardcoded a type object. A useful habit is to inventory every consumer of Knowledge data before scheduling the migration. List the reports, the dashboards, the Apex, the flows, and the external systems. Each one needs a verification pass after cutover. Skipping this inventory is the most common reason a technically clean migration still causes a Monday-morning support incident.
When the term still appears and how to read it
Article Type has not disappeared from the written record even though the construct has been superseded. It appears in Classic-era Help documentation, in older certification study guides, in blog posts and AppExchange listings written before the Lightning migration, and in legacy org metadata that was never cleaned up. When you encounter it, the safe translation is almost always Record Type on the Lightning Knowledge object. A few practical reading rules help. If a document describes creating a new custom object for each kind of article, it is Classic and the modern equivalent is a Record Type. If it mentions filtering article lists by Article Type, expect that capability to be gone in Lightning. If a report type names a __kav object, that report needs rebuilding on the unified object. New platform features land on Lightning Knowledge only, so anything describing Article Type as the current way to extend Knowledge is out of date. Reading old material is fine as long as you map every Article Type reference forward before you act on it.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Article Type.
Hands-on resources to go deeper on Article Type.
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 Article Type in Classic Salesforce Knowledge?
Q2. What has replaced the Article Type concept in Lightning Knowledge?
Q3. Why is the Lightning Knowledge model considered simpler than Classic Article Types?
Discussion
Loading discussion…