Enable Kb generation Skill to custom table

[joaovicsaa]

Recently I've managed to enable KB generation Skill for a custom table extended from task. As I didn't found any post about this, I've decided to share my result.

Basically, I wanted to use Now Assist Topic "Generate KB article" to create article from a custom table. I've found a way to do it by cloning the "Choose Input" Var set and "Define Availbility" and adjusting the routing to the custom table and its fields. 

I've added the custom table into "Now Assist Skill Config Applicabilities" aswell.

Be sure to match the Access Controls and ACLs from incident to the custom table. 

Then that's my result:

[joaovicsaa]

Next step is to set the custom table and its fields in the Duplicated Config type.
It's very important to avoid changing the Now Assist Skill Variables Types.



By doing that, in Now Assist Admin>Skill>Kb generation it's possible to verify that two new section of configuration was included, which are exatcly what was duplicated.



Q - Why not including the custom table to be target by the original "Choose input" and "Define availability"?
A - By doing this the skill doesn't work neither for Incidents nor the custom table, so the functionality is depricated. 

Also, there is the need to match the Access Control and ACLs from Incident to the custom table. In my case, copying only the actives "incident.knowledge" accesses controls was necessary.

[joaovicsaa]

In order to Debug the Skill access to the table, get the script from "Generate KB article"s Script action utility "is skill enabled for table"  in Virtual Agent Designer and bring it to a Script - Background to test the variables "parsedConfig", "skill_config_id", "skill_active_for_table", "configured_knowledge_base" and "is_valid_state".

[VJ_Srivastava]

Hello @joaovicsaa ,

From an enterprise architecture standpoint, this is a textbook example of maximizing platform extensibility. ServiceNow’s GenAI architecture is inherently powerful, but its true enterprise value is unlocked only when we seamlessly map those AI capabilities to an organization's unique, custom data models rather than restricting them to standard ITIL tables.

When designing system architecture, we must constantly balance innovation with the prevention of technical debt. By abstracting the routing and extending the Skill Config Applicabilities rather than hardcoding custom REST integrations to external LLMs, you have maintained a clean, scalable, and secure data model within the instance boundaries.

This is exactly the type of platform-aligned innovation our top-tier global and offshore engineering talent leverages to deliver a distinct strategic advantage. Empowering highly skilled engineering teams to adapt foundational AI models to bespoke business workflows—while adhering strictly to platform best practices—ensures that the underlying infrastructure remains robust and upgrade-safe.

For long-term scalability, ensuring that these custom tables are properly aligned with your Common Service Data Model (CSDM) framework will further enhance the AI's ability to contextualize the generated knowledge articles across the broader enterprise. Fantastic work sharing this architectural blueprint!

 

[NehaG8791370651]

Hi @joaovicsaa ,

This is an exceptionally well-executed technical workaround for a highly sought-after use case! Extending Now Assist Generative AI capabilities to custom tables is a frequent requirement, and your configuration methodology is exactly how this should be handled.

By specifically cloning the "Choose Input" variable set and adjusting the routing within the Skill Config Applicabilities, you have successfully isolated your customizations. This declarative approach avoids modifying the baseline out-of-the-box (OOB) scripts, which is crucial for maintaining instance health and upgradeability.

Your callout regarding Access Controls (ACLs) is the most critical step that many developers miss. Now Assist skills strictly respect platform security, and missing read permissions on custom tables is usually the number one reason these AI generations fail silently.

For anyone looking to replicate this implementation, here is a technical checklist to ensure a seamless deployment:

• Row-Level ACLs: Ensure the user role executing the Now Assist skill has explicit read access to the custom task table records.

• Field-Level ACLs: Verify that the specific fields being fed into the LLM prompt (such as Short Description, Description, Resolution Notes, or Work Notes) are fully accessible to the AI user context.

• Prompt Mapping: Double-check that your custom table's field names align with the variables expected by the cloned Generative AI template.

• Automated Regression Testing: Because you cloned the OOB configurations, your custom setup will not automatically inherit ServiceNow's backend prompt enhancements in future family releases. Add a mandatory test case to your Automated Test Framework (ATF) suite to validate this routing during your next upgrade cycle.

Excellent contribution to the developer community!