1. How do you manage who can read, edit, and publish knowledge articles in ServiceNow?

Managing access to knowledge articles is paramount. You don’t want just anyone publishing critical information or, worse, viewing sensitive content. In ServiceNow, we primarily use **Roles and Groups** in conjunction with **Access Control Lists (ACLs)** to dictate who can do what.

The best practice is always to assign roles to groups, not directly to individual users. This makes administration much easier. When a user joins or leaves, you simply add or remove them from a group, and their roles (and thus permissions) are automatically managed. For example, you might have a “Knowledge Contributors” group with the knowledge_manager or knowledge_admin roles, and an “IT Users” group with the knowledge role.

When you create a new table, ServiceNow automatically generates four basic ACLs (for Create, Read, Write, Delete operations), assuming the ‘Create access controls’ checkbox is marked. For existing tables like kb_knowledge (the Knowledge article table) or custom knowledge tables, you’d define specific ACLs. These ACLs can be based on roles, conditions, or even scripts (e.g., “only the article owner can edit this draft”).

Why This Question Matters for KM

This question tests your understanding of foundational ServiceNow security and best practices. In KM, it’s critical to control content quality and confidentiality. Showing you understand group-based role assignment and ACLs demonstrates you can build a secure and maintainable knowledge environment.

Troubleshooting Tips for KM Access

2. How would you configure a hierarchical category and subcategory system for knowledge articles?

A well-organized category structure is vital for user navigation and search. For creating a hierarchical system like Category and Subcategory on knowledge articles, we use **Dependent Values** in dictionary entries.

Here’s how it generally works:

• First, you define your “parent” field, let’s say “Category,” with its list of choices (e.g., Hardware, Software, Network).
• Next, you configure your “dependent” field, “Subcategory.” In its dictionary entry, you’ll specify that it’s dependent on the “Category” field.
• Finally, for each choice in the “Subcategory” field, you’ll link it to a specific value of the “Category” field. So, if Category is “Hardware,” the Subcategory choices might be “Laptop,” “Desktop,” “Printer.” If Category is “Software,” choices would be “Operating System,” “Application,” etc.

This dynamic filtering ensures that users only see relevant subcategories based on their initial category selection, making the article creation and search experience much cleaner.

Why This Question Matters for KM

This demonstrates your ability to create intuitive form experiences and logical data structures, which directly impacts the usability and findability of knowledge articles. Interviewers want to see you can build practical solutions for organizing content.

Real-world Example for KM Categories

3. How do you dynamically control fields (visibility, mandatory, read-only) on a knowledge article form?

For client-side control over form fields on a knowledge article, we use **UI Policies**. UI Policies are excellent for making fields mandatory, read-only, or hidden based on certain conditions—all without writing a single line of script, unless you choose to for complex logic.

Key aspects of UI Policies you’d apply to knowledge article forms:

• Conditions: Define when the policy should trigger (e.g., when “Article State” is “Draft,” or “Category” is “HR Policies”).
• Actions: Specify what happens to specific fields (e.g., make “Reviewer Comments” mandatory, “Publish Date” read-only, or hide “Internal Only” field).
• On Load: If checked, the policy evaluates when the form first loads. Unchecked means it only triggers when a field changes after load.
• Reverse if false: If checked, the actions are reversed when the condition is no longer met. For example, if a field was made mandatory when true, it becomes optional again when false.
• Global: If checked, the policy applies to all form views. Uncheck it to target a specific view.
• Inherit: If your knowledge article extends another table, checking this applies the UI Policy to child tables too.
• Run scripts: Yes, you can add client-side JavaScript for more complex logic if needed, but always try to use the UI Policy conditions/actions first!

Why This Question Matters for KM

Interviewers want to know you can create user-friendly and guided experiences for knowledge authors. Controlling form fields ensures data quality and relevance, adapting the form dynamically based on the article’s context or state.

Troubleshooting UI Policies for KM

4. Explain the role of Data Policies in Knowledge Management. When would you use a Data Policy vs. a UI Policy for knowledge articles?

While UI Policies handle client-side form behavior, **Data Policies** are about enforcing data integrity at a deeper level. They ensure consistency and validity of data across all entry points, not just forms. Data Policies work at both the client and server side.

For knowledge articles, a Data Policy might enforce that the “Category” field is mandatory, regardless of whether the article is created via the form, an import, or an API call. It’s about the data itself, not just how it’s presented on a form.

Data Policy vs. UI Policy for KM

• UI Policy:
  • Scope: Client-side (form only).
  • Purpose: Improve user experience, guide data entry on a form.
  • Use Case in KM: Dynamically hide/show “Reviewer Notes” field based on article state; make “Justification” mandatory if an article is being retired.
  • Limitations: Does not apply if data bypasses the form (e.g., imports, scripts).
• Data Policy:
  • Scope: Both client and server-side (all data sources).
  • Purpose: Enforce data integrity and consistency for critical fields.
  • Use Case in KM: Always make “Short Description” mandatory for every article, regardless of how it’s created; ensure “Valid To” date is always read-only once published.
  • Conversion: You can convert a UI Policy into a Data Policy, but there are limitations. For instance, if a UI Policy controls visibility, views, related lists, or scripts, it cannot be directly converted because Data Policies don’t handle those UI-specific aspects.

Why This Question Matters for KM

This question gauges your understanding of data governance and how to maintain the quality of your knowledge base. It highlights your awareness of different enforcement mechanisms and when to choose the right tool for the job.

5. How can you enable or disable attachments specifically for knowledge articles or certain types of articles?

Attachments are often crucial for knowledge articles (e.g., screenshots, diagrams, reference documents). To control attachments at the table level (like for kb_knowledge), we use **Attributes** on the table’s **Collection field**.

Every table has a special dictionary entry of type “Collection” which represents the table itself, not a specific field on it. Changes made to this collection field’s attributes apply to the entire table. To disable attachments for all knowledge articles, you would:

• Navigate to the dictionary entry for the kb_knowledge table (its “Collection” type entry).
• Add the attribute no_attachment. This will disable the attachment icon for all records on that table.

Conversely, if attachments were disabled globally and you wanted to enable them for knowledge, you’d ensure this attribute isn’t present, or use a dictionary override on a specific field if you needed more granular control at the field level (though for table-wide attachment control, the collection field is the primary method).

Why This Question Matters for KM

Attachments are a common component of knowledge articles. This question tests your knowledge of how to manage core platform functionalities like attachments at the table level, which is a practical skill for any ServiceNow admin working with content.

6. When would you use Dictionary Overrides in the context of Knowledge Management? Provide an example.

**Dictionary Overrides** are incredibly useful when you have a child table that extends a parent table, and you want a field on the child table to behave differently than the same field on the parent. This is especially relevant if you create custom knowledge article types that extend the standard kb_knowledge table.

Imagine your organization has a standard kb_knowledge table. However, you decide to create a new table, u_hr_policy_knowledge, that extends kb_knowledge, specifically for HR policies.

Real-world Example for KM Dictionary Overrides

Why This Question Matters for KM

This demonstrates an advanced understanding of table inheritance and customization. For organizations with diverse knowledge types, overrides are essential for tailoring forms and data fields without resorting to complex client scripts.

7. How can you restrict the options displayed in a reference field on a knowledge article form (e.g., selecting a specific author or reviewer group)?

To filter options in a reference or list field on a knowledge article form, you’d use a **Reference Qualifier**. These are powerful tools to ensure users select valid and relevant options.

There are three main types:

• Simple Reference Qualifier:
  • Description: A fixed query to filter records.
  • Example in KM: On the “Author” reference field, you might only want to display active users: active=true. Or on a “Knowledge Base” field, show only specific knowledge bases: name=IT Knowledge Base^ORname=HR Knowledge Base.
• Dynamic Reference Qualifier:
  • Description: Uses a pre-defined “Dynamic Filter Option” that can adapt based on context.
  • Example in KM: You could define a dynamic filter option called “My Knowledge Groups” that automatically filters the “Assignment Group” field to show only groups the current user is a member of. This is useful for assigning articles for review.
• Advanced Reference Qualifier (JavaScript):
  • Description: Uses custom JavaScript to build a complex query dynamically, often based on multiple fields or the current user’s context.
  • Example in KM: On a “Reviewer” field, you might want to show only users who are members of the article’s “Category Owner Group” AND who have the knowledge_manager role. This would require a script like:

    javascript: 'roles=knowledge_manager^EQ^assignment_group=' + current.getValue('u_category_owner_group');

Why This Question Matters for KM

Accurate linking and assignment are crucial for effective Knowledge Management. This question confirms you can guide users to select appropriate reviewers, categories, or related records, maintaining the integrity and workflow of your knowledge articles.

8. Can you use scripting within UI Policies or other areas to automate actions for knowledge articles? Provide an example.

Absolutely! While ServiceNow offers a lot of no-code/low-code options, sometimes scripting is necessary for complex automation. Yes, you can enable the “Run scripts” checkbox within a **UI Policy** to execute client-side JavaScript. This allows for advanced form manipulation that simple conditions might not cover.

Beyond UI Policies, scripting is fundamental:

• Business Rules: For server-side automation (e.g., automatically setting an article’s state after a certain event, or notifying a group when an article is nearing its review date).
• Client Scripts: For more granular client-side interactions beyond UI Policies.
• Scheduled Jobs: To run maintenance scripts on knowledge articles (e.g., retiring old articles, cleaning up drafts).
• Flow Designer/Workflows: Often include script steps for complex logic in article approval or publishing processes.

Real-world Example for KM Scripting

function onCondition() {
    g_form.setMandatory('reviewer', true); // UI Policy Action might handle this, but can be done here too
    
    var gdt = new GlideDateTime();
    gdt.addDays(7);
    g_form.setValue('review_due_date', gdt.getDate()); // Set review due date
    
    g_form.addInfoMessage('Article is now pending review. Please notify the assigned reviewer!'); // Custom message
}

Why This Question Matters for KM

This demonstrates your ability to extend ServiceNow’s capabilities beyond out-of-the-box features. For KM, scripting can automate tedious tasks, improve the authoring experience, and ensure adherence to complex organizational workflows.

9. How do you represent and manage the different stages (e.g., Draft, Review, Published) of a knowledge article in ServiceNow?

The lifecycle of a knowledge article is typically managed using a **State field** (like workflow_state on kb_knowledge) combined with **Process Flows**, **Workflows/Flow Designer**, and **ACLs**.

• State Field: This is a choice list field that tracks the article’s current status (e.g., Draft, Review, Published, Retired, Outdated).
• Process Flow: This is a visual indicator at the top of a form that shows the current stage of a record. For knowledge articles, it clearly displays the workflow state, guiding users through the publishing process. You configure this under “Process Flow Formatters” in the form design.
• Workflows/Flow Designer: These automate the transitions between states. For example, when an article moves from “Draft” to “Review,” a workflow might trigger an approval process, send notifications to reviewers, or update fields.
• ACLs: Access controls play a role in state transitions too. For instance, only users with the knowledge_manager role might be able to move an article from “Review” to “Published.”

By combining these elements, you create a robust, guided, and automated process for managing articles from creation to retirement.

Why This Question Matters for KM

Understanding the knowledge article lifecycle is fundamental to effective KM. This question confirms you can implement and explain the process that ensures articles are reviewed, approved, and maintained appropriately, leading to high-quality, up-to-date content.

10. How can you automatically populate specific fields on a knowledge article based on other selections or predefined rules?

Automatically populating fields is a great way to reduce manual effort and improve data consistency for knowledge authors. There are a few key mechanisms:

• Data Lookup Rules: This is an excellent no-code solution for populating fields based on conditions. You define a “Data Lookup Definition” and then “Matcher” and “Setter” fields.
  • Example in KM: If a user selects “Category: Hardware,” a Data Lookup Rule could automatically set the “Default Reviewer Group” field to “Hardware Team Lead” and the “Review Frequency” field to “Quarterly.” These rules live in separate tables and are quite efficient.
• Client Scripts: For more complex client-side logic, a client script can populate fields dynamically based on user input (e.g., fetching a user’s department once their name is selected).
• Business Rules: For server-side population, business rules are ideal. They can set field values before or after an insert/update (e.g., automatically setting the “Published By” field to the current user when the article state changes to “Published”).
• Calculated Values (Dictionary Property): If a field’s value can always be derived from other fields using the current record’s data, you can set it as a “Calculated value” in its dictionary entry using a script. This is less common for direct KM content but could be used for metadata like “Time Since Last Review.”

Why This Question Matters for KM

Efficiency and data accuracy are crucial in KM. This question explores your ability to automate form population, streamlining the authoring experience, and ensuring critical metadata is consistently captured, which improves searchability and governance.