Article-Type Layout
An Article-Type Layout was the page layout attached to a Salesforce Classic Knowledge article type.
Definition
An Article-Type Layout was the page layout attached to a Salesforce Classic Knowledge article type. Each article type, such as FAQ or How-To, had at least one layout that decided which fields appeared on the article, in what order, inside which sections, and which fields each profile could see or edit. The layout connected the article type's fields, stored on the underlying article version object, to the experience an author saw while writing.
The feature is older Classic Knowledge functionality. Lightning Knowledge replaced article types with record types on one unified Knowledge object, and replaced the per-type layout with a standard page layout assigned per record type and profile. Most orgs moved off Classic Knowledge between 2018 and 2022, retiring Article-Type Layouts along the way. The term still shows up in older documentation and certification material, so reading any such reference means translating it to the Lightning record type layout that does the same job today.
From article-type layouts to record-type layouts
The Classic per-article-type layout model
In Salesforce Classic Knowledge, every article type was its own object. An admin who created a How-To article type and an FAQ article type got two separate objects, each with its own fields and its own page layouts. The layout lived under the article type definition in Setup, alongside custom fields, templates, and article actions. Admins built each layout in the standard page layout editor, dragging fields into sections and arranging columns the same way they would on any object. Because the layout was scoped to a single article type, the structure was specific to that content. A How-To layout might carry Steps, Prerequisites, and Expected Result sections. An FAQ layout often carried only Question and Answer. This tight coupling kept each authoring screen focused, but it also meant the number of layouts grew with every new article type, and any change to a shared field had to be repeated across each type that used it.
Fields, sections, and what the layout controlled
An Article-Type Layout controlled three things. First, it decided which fields appeared and in what order, so an author saw the right inputs for that content and nothing extra. Second, it grouped those fields into sections, which gave the editing screen its shape and helped writers move through long articles. Third, through field properties on the layout, it set whether each field was read-only or required, and field-level security further controlled visibility per profile. The layout also drove how the published article looked to readers, since the same field arrangement carried into the view. A field that was missing from the layout was effectively invisible to authors using it, even if the field existed on the object. That is why layout design was the main lever for shaping the Knowledge authoring experience in Classic, well before any code or validation rule entered the picture.
Profile assignment in Classic
Classic assigned each Article-Type Layout per profile. A given profile saw one layout for a given article type, which let different audiences work with different fields on the same content. A support agent profile might see an internal-notes section that a partner profile never saw. There was no permission set option for layout assignment in this model, so every audience variation had to be expressed through profiles. In large orgs with many roles, this became repetitive to maintain. Permissions for what a user could do with articles, such as create, edit, publish, or archive, were handled separately through article actions rather than through the layout. Keeping the two concerns straight, layout for fields and article actions for permissions, was a common source of confusion for admins new to Classic Knowledge.
Why Salesforce moved away from per-type layouts
The per-article-type model did not scale cleanly. Each new Knowledge variant meant a new custom object plus its own layouts, and reporting across article kinds was awkward because the data sat in separate objects. Authors had to learn a different edit screen for each type. Lightning Knowledge consolidated every article kind into one Knowledge object and used record types to tell them apart, the same pattern Salesforce uses on Account or Case. Layouts now sit per record type on that single object. One report can span all article kinds. A shared field is defined once. Adding a new kind of article means adding a record type, not standing up a new object. Salesforce announced that it could no longer filter by article type after migration, because article types no longer exist as objects in the Lightning model. This was the clearest signal that the old layout container was being retired.
The Lightning record type equivalent
In Lightning Knowledge, you customize fields, actions, and related lists for each record type and user profile using a standard page layout. The mechanics match layouts on any other Lightning object, so there is no Knowledge-specific layout editor to learn. Authoring actions added to the Salesforce Mobile and Lightning Experience Actions section appear in the highlights panel on the article record. One detail trips people up during the move: to use inline edit with Knowledge, the Publication Status field must sit on the standard page layout, not on a compact layout. Fields that Classic hard-coded onto the article screen are not automatic in Lightning, so you add them to the layout yourself. The result is more consistent with the rest of the platform, which means anyone who can build an Account layout can build a Knowledge one.
What the migration tool maps and what it does not
The Lightning Knowledge migration tool converts Classic article types into record types and reproduces each Article-Type Layout as a page layout on the unified Knowledge object. Field positions and section structure carry across. The parts that need hands-on work are the ones tied to business logic and access. Permissions change model entirely: Classic used article actions, while Lightning uses profiles and permission sets, so access has to be reassigned after the tool runs. Fields that Classic hard-coded onto the page have to be added to the new layouts by hand. Validation rules and formula fields often need adjustment because field names change in the new object. Salesforce ships a post-migration checklist and a verify-articles step for exactly this reason. Treat the tool as a fast structural copy, then plan admin time for permissions, fields, and rules.
Where the term shows up today
Article-Type Layout appears in Classic-era certification study material, older partner blogs, and AppExchange listings that predate Lightning Knowledge. Current Salesforce Help talks about page layouts per record type, or simply Lightning page layouts for Knowledge. If you meet the term in an exam guide or an old runbook, read it as a historical reference and map it to the Lightning equivalent. The underlying idea did not disappear. A layout still decides which fields an author sees and how they are arranged. Only the container changed, from a layout bolted onto a one-off article type object to a standard layout assigned per record type on a shared object. Knowing both vocabularies is useful when you inherit an org that was built in Classic and never fully cleaned up after its migration.
Set up the Lightning Knowledge layout that replaced it
Article-Type Layouts no longer exist in Lightning Knowledge. The live equivalent is a standard page layout assigned per record type and profile on the Knowledge object. Here is how an admin sets that up today.
- Create or open the record type
In Setup, go to the Knowledge object and open Record Types. Create one record type per kind of article, for example FAQ or Procedure. This is the Lightning replacement for a Classic article type.
- Build the page layout
Under the Knowledge object Page Layouts, create or edit a layout. Drag in the fields and sections each article kind needs, and place authoring actions in the Salesforce Mobile and Lightning Experience Actions section.
- Add the Publication Status field
Put the Publication Status field on the standard page layout, not on a compact layout, so authors can use inline edit on the article record.
- Assign the layout per record type and profile
Open the Page Layout Assignment screen and map each profile and record type combination to the right layout, so each audience sees the correct fields.
The Lightning container that replaces a Classic article type and owns its layout assignment.
The standard layout that decides which fields, sections, and actions appear on the article.
Must be on the standard layout, not a compact layout, to enable inline edit for Knowledge.
The per profile and record type mapping that controls which layout each author sees.
- Permissions do not come from the layout. Lightning uses profiles and permission sets, replacing the Classic article actions model, so grant access separately.
- Fields that Classic hard-coded onto the article screen are not added for you. Place them on the layout by hand after migration.
- Leaving Publication Status off the standard layout silently breaks inline edit, which is easy to miss until an author reports it.
Trust & references
Cross-checked against the following references.
- Article Type Page LayoutsSalesforce
- Page Layout Considerations for Lightning KnowledgeSalesforce
Straight from the source - Salesforce's reference material on Article-Type Layout.
Hands-on resources to go deeper on Article-Type Layout.
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 Layout?
Q2. How do Article-Type Layouts compare to standard page layouts?
Q3. In Lightning Knowledge, what replaces Article-Type Layouts?
Discussion
Loading discussion…