Knowledge Management practice questions

Knowledge Article View Count dashboard component.

Why it fails: View count measures how often an article is opened, not how often it is attached to cases. It is tempting because it is an out-of-the-box Knowledge metric, but the manager needs attachment frequency, which comes from case-article reporting rather than viewing statistics.

Service Analytics App embedded Einstein dashboard.

Why it fails: The Service Analytics app reports case and service metrics, but it does not expose article-to-case attachment counts as an embedded Einstein dashboard. It is tempting because it is a packaged analytics app, yet the attachment metric is not surfaced there out-of-the-box.

Article Feedback related list on the Case layout.

Why it fails: Article Feedback captures ratings and comments on an article, not the number of times it is attached to cases. It is tempting because it sits on the Case layout and relates to articles, but attachment frequency requires reporting on the CaseArticle junction object instead.

Publish Articles

Why it fails: Publish Articles governs releasing draft article versions to published status; it does not grant visibility of version history. It is the right permission for authors promoting content, whereas viewing versions requires the Article Version History object permission.

Edit Draft Articles

Why it fails: Edit Draft Articles governs authoring of unpublished content, not visibility of version history. It is tempting because draft editing and versioning both live in the article lifecycle, and this permission would be correct for a knowledge author who must revise unpublished articles before publication. Viewing historical versions instead requires the View permission on the article entity.

Manage Articles

Why it fails: Manage Articles permits deleting, archiving and restoring articles, plus managing publication workflow; it does not by itself expose version history records. It suits knowledge managers administering article lifecycle, while version viewing needs the Article Version History object permission.

Create a custom approval process that routes to tier-2 agents upon submission for publication.

Why it fails: An approval process gates a submission but does not restrict who may publish; tier-2-only publishing for a category is enforced through data category visibility and article-type permissions on profiles. It tempts because approvals imply authorisation control, yet the requirement is publish rights, not review routing.

Set the sharing model for Knowledge to Private and use manual sharing rules.

Why it fails: Knowledge article sharing is governed by data category visibility and article-type access, not by the organisation-wide sharing model or manual sharing rules, which do not apply to Knowledge. It tempts as a familiar access-control pattern, but category visibility plus profile permissions is the actual publishing mechanism.

Modify the record types assigned to the tier-1 support profile to exclude hardware articles.

Why it fails: Record types classify articles but do not control publishing rights; excluding hardware articles from tier-1 record types hides them rather than preventing publication. It tempts because record types commonly segment access, yet data category visibility and article-type permissions on profiles are what restrict publishing.

Create a custom Lightning component override for the New Article button.

Why it fails: Incorrect. Overriding standard buttons with custom components is unnecessary since feed actions support mapping.

Use Workflow Rules with field updates on the Knowledge object.

Why it fails: Workflow rules cannot pre-populate fields on a record an agent is about to create; they fire after save. Workflow field updates are tempting for automated post-save changes, but pre-selecting record type and summary during article creation requires a default value or pre-built action on the Case.

Write an Apex trigger on the Case object that inserts a Knowledge record on creation.

Why it fails: An Apex trigger inserting a Knowledge record on case creation ignores the agent's action of creating an article from the case, and cannot pre-select the FAQ record type in the editor. Triggers are tempting for automated record creation, but this requirement needs the article's default field values configured.

Languages cannot be added after initial setup.

Why it fails: Languages are added later via translation workbench and language settings, so this is not the irreversible structural decision. It tempts because multilingual Knowledge requires planning, but the genuinely locked-in choice concerns article record types and their field-level structure, which cannot be changed once articles exist.

Approval processes become mandatory for all articles.

Why it fails: Approval processes are optional and configurable at any time; they never become mandatory for all articles. The option tempts because approvals govern publication workflow, but the irreversible decision is the article record type model, since record types cannot be deleted or repurposed after articles reference them.

Data categories cannot be modified after creation.

Why it fails: Data categories remain editable — you can add, rename, and reorganise them after creation. This tempts because category architecture needs upfront thought, but the truly locked decision is the article record type structure, which cannot be altered once articles are created against it.

Use field-level security to hide the 'Internal Notes' field from the Experience Cloud guest user profile.

Why it fails: Incorrect. Field-level security applies to profiles, but Knowledge page layouts combined with channel mappings provide precise layout control per channel.

Create a validation rule that checks if the viewing user is external and clears the field.

Why it fails: Incorrect. Validation rules prevent saving data, not viewing data.

Use custom CSS in the Experience Cloud site builder to hide the field DOM element.

Why it fails: CSS hiding only conceals the DOM element client-side; the field data still renders and can be exposed via API or page source. Field-level security or a separate article record type without the field is needed. It tempts because CSS is quick for cosmetic layout tweaks, not access control.

In Service Console App Navigation Rules.

Why it fails: Navigation Rules control which console tabs and components appear for a user, not article creation from the case feed. They are tempting because they govern console agent experience, but the create-article-on-the-fly toggle lives in Knowledge Settings, so navigation rules cannot enable it.

In Knowledge Settings under Feature Settings in Setup.

Why it fails: Knowledge Settings under Feature Settings does hold the article-creation option, but the stem asks where agents create an article while attaching one to a case, which is governed by the Lightning Knowledge setting enabling creation from the case feed, not the general feature settings page alone.

In Object Manager under Case Page Layouts.

Why it fails: Case page layouts control which fields and related lists agents see on a case record, not the ability to author a Knowledge article mid-attachment. Page layouts are tempting because they shape case UI, but the create-on-the-fly capability is a Knowledge setting, not a layout property.

Assignment Rules on the Case object.

Why it fails: Incorrect. Assignment rules route Cases, not Knowledge articles.

Queue-based sharing rules on Knowledge.

Why it fails: Incorrect. Sharing rules control access, not task assignment workflows.

Omni-Channel routing for Knowledge drafts.

Why it fails: Omni-Channel routing distributes work items through queues, skills and capacity rules, but it routes cases, conversations and activities — not Knowledge article records. It is tempting because Omni-Channel is the standard mechanism for assignment by record attributes; it would be correct if the requirement were routing cases by type, rather than authoring tasks by article record type.

Data category groups must be identical across all Knowledge record types.

Why it fails: Data category groups are assigned per Knowledge record type and need not be identical across them, so this is not a limit. It is tempting because record types do constrain which categories apply, which suits scenarios where all article types share one taxonomy rather than differing ones.

Data categories cannot have more than 3 levels of child categories.

Why it fails: Data category hierarchies support up to five levels of child categories, not three, so this understates the actual structural limit. It is tempting because shallow hierarchies are common practise, which suits simple taxonomies rather than the five-level depth Salesforce permits.

A single article can be associated with a maximum of 10 data categories across all groups.

Why it fails: An article can be assigned up to eight data categories per group, not a maximum of ten across all groups, so this misstates the governor. It is tempting because category assignment is genuinely capped, which suits planning around per-group limits rather than a global total.

Create a time-based workflow rule on Knowledge that unpublishes the article on the expiration date.

Why it fails: Time-based workflow rules cannot be created on Knowledge; workflow actions do not support the Knowledge object's article versioning model. It is tempting because time-based workflow is the standard declarative tool for date-driven field updates elsewhere. The correct mechanism is a Knowledge validation process with an expiration action.

Build an Apex scheduled batch job that queries expired articles and updates their status.

Why it fails: A scheduled Apex batch job would work technically but requires custom code, governor-limit management and scheduling, whereas Knowledge validation processes deliver this declaratively. It is tempting because batch Apex handles bulk date-driven updates on most objects. The stem asks how to configure it, implying the built-in validation expiration feature.

Use an escalation rule to notify the article owner when the expiration date passes.

Why it fails: Escalation rules notify owners about cases and cannot unpublish Knowledge articles or set review flags. It is tempting because escalations handle time-based notifications, which resembles the required owner alert. The stem requires automatic unpublishing plus review flagging, which only a Knowledge validation process performs.

Build custom formula fields on Knowledge that increment every time a view occurs on a specific channel.

Why it fails: Formula fields are calculated, not counters, so they cannot increment on each view event. Knowledge article view tracking uses standard Article Version history and reporting. It tempts because formulas appear to offer a custom metric, but they cannot capture discrete user interactions.

Create separate Knowledge objects for internal and external viewing channels.

Why it fails: Duplicating Knowledge objects fragments the article base, breaks unified search and reporting, and does not itself record view counts per channel. Standard view tracking on one object suffices. It tempts when teams want strict separation, but record types and sharing already achieve that.

Use Google Analytics tracking codes embedded in the article templates.

Why it fails: Google Analytics captures page-level traffic on the Experience Cloud site only, missing internal agent views inside Salesforce and providing no reportable Knowledge view data. Native article view history is required. It tempts because Analytics is free and familiar for public web traffic.

Select multiple articles in the Knowledge tab list view and click the 'Archive Selected' button.

Why it fails: Incorrect. Standard list views in Lightning Knowledge do not provide a native multi-select archive button for large batches.

Write an anonymous Apex script that deletes the Knowledge records permanently.

Why it fails: Incorrect. Archiving is preferred over permanent deletion to maintain historical reporting integrity.

Configure a scheduled Flow that iterates through all articles and changes their record type to Archived.

Why it fails: A scheduled Flow cannot archive published articles by changing record type; archiving requires the Article Archive action, and record types do not control archive status. This approach also bypasses bulk archive limits. The correct method is the Knowledge bulk archive action from the article list view.

Configure an outbound message to call the Salesforce REST API and publish the article.

Why it fails: An outbound message only fires on workflow rules and sends SOAP notifications to an external listener; it cannot change article status internally. It is tempting because outbound messaging integrates external systems, which would suit notifying a third-party CMS, but here the status change must happen inside Salesforce.

Instruct the final approver to manually click the Publish button after approving.

Why it fails: Manual publishing leaves the status unchanged until a human acts, so the article is not automatically visible post-approval. It is tempting because approvers can publish articles, and manual steps suit low-volume editorial workflows, but the requirement specifies automatic status transition on approval.

Write an Apex trigger that listens for approval completion events.

Why it fails: Approval completion does not expose a triggerable event, so an Apex trigger cannot listen for it; approval processes are configured declaratively. It is tempting because triggers handle complex automation, and would be correct if no standard post-approval action existed, but here the approval action itself performs the status change.

Einstein Discovery predictive lifecycle models.

Why it fails: Einstein Discovery builds predictive models from historical data, not elapsed-time reporting between draft submission and publication. It tempts because lifecycle analytics sounds predictive, but the requirement is a straightforward duration calculation, which custom report types on Knowledge article versions deliver.

Real-Time Event Monitoring transaction log analytics.

Why it fails: Real-Time Event Monitoring captures security and access events, not article draft-to-publish durations. It tempts because it offers granular timestamped logging, but those logs cover user activity and threats; the required metric needs custom report types joining Knowledge article version history.

Chatter audit trails on article group feeds.

Why it fails: Chatter audit trails record feed posts and moderation actions, not article lifecycle timestamps. It tempts because Chatter feeds can accompany articles, but the draft-to-publish interval requires custom report types over Knowledge article versions, which expose submission and publication dates.

Embed custom Lightning Web Components directly into the Knowledge object page layout via Object Manager.

Why it fails: D-LWC components are placed via Lightning App Builder, not Object Manager page layouts.

Create separate database tables for each page layout configuration.

Why it fails: Incorrect. Salesforce manages the underlying object schema automatically.

Draft versions are immediately visible to public guest users on Experience Cloud sites.

Why it fails: Draft versions are never visible to public guest users on Experience Cloud sites; only published versions are exposed. Drafts remain internal until published. This option would be correct only if discussing internal preview access for authorised users, not public guest visibility.

An article can have multiple published versions simultaneously active at the same time.

Why it fails: Knowledge permits only one published version of an article at any time; publishing a new version supersedes the prior published version. Multiple versions can exist as drafts, but not simultaneously published. This option would be correct if describing draft version coexistence, not published versions.

A mandatory Apex trigger to lock the record during review.

Why it fails: Approval processes lock records automatically through the approval lock action, so no Apex trigger is required; adding one is unnecessary custom code. Apex triggers are tempting for enforcing bespoke locking logic, but they would be the choice only where standard approval locking is insufficient.

A separate approval object for tracking history.

Why it fails: Approval history is stored on the article's approval-related records and the standard approval history related list, so a separate custom approval object is not required. Building one is tempting for bespoke audit reporting, but that suits scenarios needing custom tracking beyond standard approval history.

Create a separate Experience Cloud site for internal security staff only.

Why it fails: A separate internal site does not restrict article visibility — the same articles remain accessible wherever shared. It tempts because site membership feels like an access boundary, but article-level control comes from data categories mapped to profiles, not from segregating the Experience Cloud site itself.

Write an Apex trigger on the Experience Cloud login event to clear cookies.

Why it fails: Clearing cookies on login does not restrict article access; sessions regenerate and article visibility is governed server-side. It tempts because login-time Apex feels like a gate, but the enforcement point is data category visibility per profile, which prevents community users receiving those articles at all.

Use custom sharing rules on Accounts to grant access to policies.

Why it fails: Sharing rules on Accounts govern record access, not article visibility; Knowledge uses article-type visibility settings and data categories to restrict community users. It tempts because account sharing is the standard way to segment customer data, and would be right if policies lived as account-related records rather than Knowledge articles.

Account territory management rules for article ownership.

Why it fails: Incorrect. Territory management applies to accounts and opportunities.

Omni-Channel skill-based routing for static dashboard components.

Why it fails: Incorrect. Dashboards are read-only and do not use skill routing.

Automatic Case Assignment rules based on article topic.

Why it fails: Incorrect. Assignment rules apply to cases, not article reviews.

Set the background color of individual article cards using inline CSS properties.

Why it fails: Incorrect. App Builder properties do not support inline CSS injection.

Embed custom Lightning Web Components directly into the article search results dropdown.

Why it fails: Incorrect. Dropdown templates cannot host arbitrary custom LWC components directly.