Article Type
An Article Type in Classic Salesforce Knowledge was a custom object that defined one kind of article: an FAQ, a How-To, a Procedure, a Release Note.
Definition
An Article Type in Classic Salesforce Knowledge was a custom object that defined one kind of article: an FAQ, a How-To, a Procedure, a Release Note. Each Article Type had its own field set (Title plus type-specific fields like Question and Answer for FAQ or Steps and Expected Result for How-To), its own page layouts, and its own permissions. Authors created articles of a specific type, and the type drove what they saw in the editor. The model was schema-heavy: every new kind of article meant a new custom object, often with its own metadata files.
Lightning Knowledge replaced the Article Type concept with Record Types on a single unified Knowledge object. The model is simpler: one Knowledge object, one set of base fields, Record Types that distinguish the kinds (FAQ, Procedure, Release Note) with their own page layouts. The functional capabilities carry across, but the data model is far cleaner. Most production orgs have completed the migration from Classic Knowledge to Lightning Knowledge; orgs still on Classic have a defined migration path that is documented and supported but not trivial. Article Type as a phrase still appears in legacy documentation and in some certification material, where it refers to the Classic concept rather than to current Lightning behaviour.
Article Type in Classic Knowledge versus Record Type in Lightning Knowledge
The Classic Article Type model
Each Article Type was a custom object suffixed __kav (KnowledgeArticleVersion). Fields, page layouts, validation rules, and permissions all attached to that object. Creating a new article kind meant creating a new __kav object with its own metadata files. Reporting and integrations referenced the object by name; a custom report type targeted FAQ__kav or How_To__kav, not a generic Knowledge target.
Why Salesforce moved away from it
The per-type model produced metadata bloat. Orgs with five Article Types had five separate objects, each with its own permission set requirements, sharing rules, and migration overhead. Cross-type reporting required UNION queries. Lightning Knowledge collapsed everything into one object with Record Types, which gives the same flexibility with much less complexity.
How Record Types replace Article Types
Lightning Knowledge has one Knowledge object. Record Types like FAQ, Procedure, Release Note each carry their own page layout and field set, but all share the underlying object. New types are admin-only changes (a Record Type plus a page layout) instead of full custom-object additions.
Migration from Classic to Lightning Knowledge
Salesforce provides a migration tool that maps each Article Type to a Record Type. Field-by-field mapping requires planning because Lightning Knowledge has different standard fields. Migrations run in stages: schema migration, content migration, then UI migration. Most migrations are completed in weeks for mid-sized programs and months for large ones.
Backward-compatible objects
Salesforce kept Classic __kav objects available for orgs that had not migrated. They continue to work but receive no new platform investment. New features land on Lightning Knowledge only; staying on Classic Knowledge means staying behind on capabilities.
Reporting and integration impact
Reports built against Classic Article Type objects do not work against Lightning Knowledge. Migrations rebuild every Knowledge report on the new object. External integrations that query a specific __kav object need to update their SOQL or API calls to target the new Knowledge object plus Record Type filter.
When the term still appears
Article Type appears in Classic-era documentation, certification material, blog posts, and AppExchange listings predating the Lightning migration. Reading any pre-2020 Knowledge resource requires translating Article Type to its Lightning Record Type equivalent.
Common migration pitfalls
Three patterns recur. Field-name mismatches between Article Type and Record Type require translation tables. Page layout assignments must be rebuilt for each Record Type. And custom report types that referenced the old __kav objects need to be rebuilt against the unified Knowledge object.
How to migrate from Article Type to Record Type
Migration is a project, not a switch. Plan in stages so reporting, automation, and integrations all land aligned with the new model.
- Enable Lightning Knowledge in a sandbox
Salesforce ships a migration tool that enables Lightning Knowledge and maps existing __kav objects to Record Types on the unified Knowledge object. Run the tool in a sandbox first.
- Map fields per Article Type
Document the field mapping from each __kav object to the corresponding Record Type's layout. Translate validation rules, formula fields, and any per-type Apex code.
- Rebuild reports and dashboards
Classic Knowledge reports do not run against Lightning Knowledge. Identify every report referencing a __kav object and rebuild against the unified Knowledge object with the right Record Type filter.
- Update integrations and Apex
External systems and Apex code that reference __kav objects need to update SOQL and API calls. Confirm Knowledge API integrations support the new schema.
- Validate and cut over production
Once the sandbox migration validates content, reports, and integrations, run the production migration during a planned change window. Plan a freeze on new article authoring during the cutover.
- Classic Article Type objects continue to function but receive no new platform investment. Long-term staying on Classic blocks new Knowledge features.
- Reports built against __kav objects do not run after migration. Plan for rebuilding every Knowledge report.
- External integrations that query specific __kav objects need code changes. Survey all integrations before scheduling the migration.
- Pre-2020 documentation that references Article Type usually translates to Record Type in Lightning Knowledge; treat older guides as historical.
Trust & references
Cross-checked against the following references.
- Migrate to Lightning KnowledgeSalesforce Help
- Knowledge Admin OverviewSalesforce Help
Straight from the source - Salesforce's reference material on Article Type.
- Knowledge ArticlesSalesforce 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 is an Article Type in Classic Knowledge?
Q2. What has replaced Article Types in Lightning Knowledge?
Q3. Why is the Lightning Knowledge model simpler than Classic?
Discussion
Loading discussion…