- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 07-14-2025 11:56 AM
Automating Knowledge Base Article Creation and Versioning for Application CIs in ServiceNow: A Practical Approach for Disaster Recovery Teams
Introduction
In many organizations, maintaining up-to-date Disaster Recovery (DR) documentation is critical for compliance and operational readiness. For teams managing Application Configuration Items (CIs) in ServiceNow, manually creating and publishing Knowledge Base (KB) articles for each new CI can be time-consuming and error-prone.
This article shares a practical, non-duplicate approach that helped us automate the creation, publishing, and versioning of KB articles tied to Application CIs specifically for the Disaster Recovery team. The solution leverages ServiceNow’s native KnowledgeUIAction.publish()
method to ensure proper versioning, immediate publishing, and UI functionality such as the Checkout button.
I hope this approach proves useful to others facing similar challenges. If you have alternative solutions or improvements, please share your insights in the comments.
Business and Technical Requirements
Our automation needed to fulfill the following key requirements:
- Automatic KB Article Creation: Generate KB articles automatically whenever a new Application CI is created.
- Immediate Publishing: Articles must be published immediately upon creation without manual intervention.
- Proper Versioning: Each article should have a clear version history, starting with a major version (e.g., 1.0) upon publishing.
- Checkout Button Visibility: The Checkout button must be visible on published articles to allow easy editing and revision creation by the DR team.
- Preserve Out-of-the-Box (OOB) Workflows: The solution must respect ServiceNow’s native publishing and versioning workflows to avoid breaking functionality or upgrade compatibility.
- Maintain Data Integrity: Relationships between KB articles and their versions must be correctly established and maintained.
Challenges Encountered
During development, we faced several challenges that are common in KB automation projects:
- Manual Workflow State Setting: Directly setting the article’s workflow state to “published” and manually creating version records broke the native relationships between articles and versions.
- Checkout Button Not Visible: Due to broken versioning relationships, the Checkout button did not appear on published articles, limiting user interaction.
- Disabling Workflows: Using
setWorkflow(false)
to bypass workflows prevented the publishing workflow from running, resulting in incomplete version creation and inconsistent article states. - Simultaneous Version Creation Confusion: Two versions—a minor draft (e.g., 0.01) and a major published version (e.g., 1.0)—were created simultaneously, complicating version management and UI behavior.
Attempts and Lessons Learned
We tried several approaches that ultimately failed or caused issues:
- Manual Insertion of
kb_version
Records: Creating version records manually alongside KB articles led to broken relationships and UI inconsistencies. - Forcing Article State in Business Rules: Setting the article’s state forcibly to “published” in Business Rules bypassed native workflows, causing versioning and UI problems.
- Disabling Workflow Execution: Preventing workflows from running to avoid draft creation broke the publishing process and version linkage.
These attempts highlighted the importance of respecting ServiceNow’s native workflow mechanisms to maintain system integrity and UI consistency.
Final Solution: Leveraging KnowledgeUIAction.publish()
Our final, robust solution follows these principles:
- Create Articles in Draft State: KB articles are created in the draft state without manually setting workflow-related fields.
- Programmatic Publishing: Immediately after creation, the native publishing logic is invoked programmatically by calling the
KnowledgeUIAction.publish()
Script Include method. - Workflow-Driven Versioning: The native workflow handles version creation and state transitions, ensuring proper linkage between articles and versions.
- Verification Loop: A wait loop confirms the creation of the
kb_version
record and verifies that relationships (latest_version
andbase_version
) are correctly established. - Checkout Button Visibility: Because the native workflow is respected, the Checkout button appears on published articles, enabling easy editing and revision creation.
Sample Script Snippet
(function executeRule(current, previous) {
var authorIt = gs.getProperty('appCIKnowledgeArticleAutomationAuthor');
var kbBase = gs.getProperty('appCIKnowledgeArticleAutomationKB');
var canReadCriteria = gs.getProperty('appCIKnowledgeArticleAutomationCRUC');
if (!authorIt || !kbBase || !canReadCriteria) {
gs.error("Missing required system properties");
return;
}
var appSysID = current.sys_id;
var currentName = current.name;
var futureDate = new GlideDateTime();
futureDate.setValue("2100-01-01 00:00:00");
var kbCategories = [
"9ece572b1ba1d1d4546fcfcb234bcb7f",
"d23fdf2b1ba1d1d4546fcfcb234bcb68",
"351f572b1ba1d1d4546fcfcb234bcb36",
"022f9fe71ba1d1d4546fcfcb234bcb74"
];
for (var i = 0; i < kbCategories.length; i++) {
var grKbArticle = new GlideRecord('kb_knowledge');
grKbArticle.initialize();
grKbArticle.setValue('kb_knowledge_base', kbBase);
grKbArticle.setValue('kb_category', kbCategories[i]);
grKbArticle.setValue('can_read_user_criteria', canReadCriteria);
grKbArticle.setValue('cmdb_ci', appSysID);
grKbArticle.setValue('short_description', currentName);
grKbArticle.setValue('description', currentName);
grKbArticle.setValue('meta', currentName);
grKbArticle.setValue('author', authorIt);
grKbArticle.setValue('valid_to', futureDate);
grKbArticle.setValue('article_type', 'text');
grKbArticle.setValue('text', 'ATTACH EXCEL TO ME');
var kbSysId = grKbArticle.insert();
if (kbSysId) {
gs.log('KB Article created in draft state: ' + kbSysId);
var kbArticleGR = new GlideRecord('kb_knowledge');
if (kbArticleGR.get(kbSysId)) {
var knowledgeUI = new global.KnowledgeUIAction();
knowledgeUI.publish(kbArticleGR);
gs.log('KB Article published programmatically via KnowledgeUIAction.publish()');
}
var versionSysId = null;
var attempts = 0;
while (attempts < 10) {
var grVersion = new GlideRecord('kb_version');
grVersion.addQuery('knowledge', kbSysId);
grVersion.query();
if (grVersion.next()) {
versionSysId = grVersion.sys_id.toString();
break;
}
gs.sleep(1000);
attempts++;
}
if (versionSysId) {
gs.log('Version record found: ' + versionSysId);
kbArticleGR.get(kbSysId);
if (kbArticleGR.latest_version == versionSysId && kbArticleGR.base_version == versionSysId) {
gs.log('Relationships established correctly.');
} else {
gs.log('Relationships not fully established yet.');
}
} else {
gs.error('Version record not found after waiting.');
}
} else {
gs.error('Failed to create KB Article for category: ' + kbCategories[i]);
}
}
})(current, previous);
Additional Notes on Versioning Behavior
- ServiceNow creates two versions during publishing: a minor draft version (e.g., 0.01) and a major published version (e.g., 1.0).
- This dual-version creation is expected and part of the platform’s versioning model.
- Minor versions can be cleaned up post-publishing if desired to keep version history concise.
Conclusion
By respecting ServiceNow’s native workflows and leveraging the KnowledgeUIAction.publish()
method, this automation reliably creates and publishes KB articles with proper versioning and UI behavior. It ensures the DR team has immediate access to up-to-date, editable documentation without manual overhead.
If you have alternative approaches or improvements, please share your experiences in the comments. Collaboration helps us all build better ServiceNow solutions!
If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'**? This will help other community members who might have the same question find the answer more easily.
Thank you for your consideration.
Selva Arun
- 1,024 Views