Log a Service Request via Virtual Agent with guided questions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10 hours ago
The objective is to enhance the Virtual Agent so it can log Incidents and Service Requests on behalf of users through a guided conversation. Instead of asking users to navigate the service catalog, the Virtual Agent should ask a series of relevant questions to gather the required information (for example, issue description, category, urgency, affected service, or other required fields) and automatically create the appropriate record.
As of now the virtual agent doesn't have the functionality to create incident. Need help on that to create INC via guided questions.
And when it comes to Service request it is creating SR's via Window method. The render type should be conversation with the fields like (Name, description, category, urgency, affected service, short description and other variables). The request should be created and aligned, should match with all the variables present in that particular catalog how we create via service portal.
And the service request should follow ITSM standard process like sending email notifications, approvals etc.
How can we achieve this ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
5 hours ago
Hi @sai9845 ,
Yes, this can be achieved, and most of the requirement is already supported OOB.
I would separate the design into two paths:
Virtual Agent
|
+--> Report an Issue
| -> Guided questions
| -> Create Incident
|
+--> Request a Service
-> Identify Catalog Item
-> Ask Catalog Item variables conversationally
-> Submit normal Service Catalog Request
-> Existing approvals / fulfillment / notifications continueI would NOT create the Incident/RITM using direct GlideRecord or custom Cart scripting unless there is a requirement that the OOB capabilities cannot support.
1. Incident creation is already supported OOB
The statement:
Virtual Agent doesn't have functionality to create Incident
is not correct.
ITSM Virtual Agent provides an OOB reusable topic block:
Create Incident
The supported inputs are:
caller short_description urgency description cmdb_ci
and the output is:
created_incident_sys_id
ServiceNow also provides the OOB:
Open IT Ticket 2.0
topic, which is the recommended ITSM Virtual Agent topic for opening an Incident. It uses:
Contextual Search Create Incident Add Comments - Similar Incident
and can reduce duplicates by checking for similar open Incidents before creating another one.
2. For your own guided Incident conversation
If you want your own sequence of questions, create a new Virtual Agent topic.
Navigate to:
Conversational Interfaces -> Virtual Agent -> Designer
I would recommend duplicating an OOB topic/template rather than modifying it directly.
Your flow could be:
User: "I want to report an issue" VA: "Please briefly describe the issue." -> short_description VA: "Can you provide more details?" -> description VA: "How urgent is this?" -> urgency VA: "Which device/service is affected?" -> cmdb_ci Then: Create Incident Topic Block
Map your topic variables into:
caller short_description description urgency cmdb_ci
After creation, use:
created_incident_sys_id
to show the Incident number/link to the user.
The OOB Create Incident topic block is specifically designed to be called from another topic with these inputs.
3. What about Category, Subcategory, Service and Service Offering?
This needs an important design decision.
The OOB Create Incident topic block exposes:
caller short_description urgency description cmdb_ci
It does NOT expose every Incident field such as:
category subcategory business_service service_offering
I would not clone/modify the protected OOB Create Incident topic block just to add those fields.
You have two better approaches.
Option A - Recommended when values can be derived
Ask the user only for meaningful information and derive the technical fields using existing platform logic.
For example:
User describes: "Outlook is not sending email" VA collects: Description + CI Then platform logic determines: Category = Software Subcategory = Email Service = Messaging Service Offering = Corporate Email
You can perform this through:
Flow / Subflow Decision Table Assignment logic Predictive Intelligence / classification where applicable
This gives a much better employee experience than asking users technical questions they may not understand.
Option B - Record Producer for a highly customized Incident intake
If the business explicitly requires the conversation to match a defined Incident intake containing many variables, create/use an Incident Record Producer.
For example:
Record Producer: Report an IT Issue Variables: Affected user Short description Description Category Subcategory Urgency Affected service Configuration item
Then make that item available through the conversational catalog experience.
This is especially useful when the same guided intake must work in both:
Employee Center / Portal and Virtual Agent
because the variables stay defined in one place rather than being duplicated separately inside the VA topic.
4. Service Requests - do not recreate all variables manually
For the Service Request requirement, use the OOB:
Request Catalog Item
topic block.
If the user already selected/identified the catalog item, pass:
catalog_item_id = <catalog item sys_id>
Virtual Agent can then retrieve the questions belonging to that catalog item and request the values conversationally.
You do NOT need to manually create:
VA question 1 -> catalog variable 1 VA question 2 -> catalog variable 2 VA question 3 -> catalog variable 3 ...
for every catalog item.
The OOB topic block returns the catalog item's questions through the variables output and creates the actual requested record after submission.
5. Why you are currently seeing the Window method
This is most likely because that catalog item is currently considered:
Non-conversational
A catalog item can render in Virtual Agent as:
Conversational / Conversational-agentic Web / Window / Popup
For your requirement, you want:
Conversational
or, if you have Now Assist:
Conversational-agentic
Australia supports Conversational-agentic catalog requests where Now Assist gathers the required information step-by-step rather than displaying the complete catalog form.
6. Configure the Catalog Item for conversational ordering
Navigate to:
Service Catalog -> Catalog Definition -> Maintain Items -> <Catalog Item>
If using Now Assist conversational catalog requests, verify:
Make the item non-conversational in VA = Unchecked
If you want the LLM experience, also verify:
Use NLU for conversational requests = Unchecked
ServiceNow then evaluates whether the catalog item satisfies the conversational requirements. Simply clearing the checkbox does not force an unsupported catalog item to become conversational.
7. Check the variables used by the item
Not every complex catalog implementation behaves identically in every VA conversational mode.
Australia supports many common variable types, including:
Single Line Text Multi Line Text Yes / No Select Box Multiple Choice Reference Lookup Select Box List Collector Date / Date Time Attachment Requested For
with some restrictions depending on NLU vs LLM conversational mode.
For example, advanced reference qualifiers and pricing behavior have restrictions in certain conversational modes, while UI Page variables aren't rendered as normal conversational questions.
Therefore, if an item is still opening in a Window, inspect:
Variable types Catalog Client Scripts Catalog UI Policies Custom variables Pricing logic Reference qualifiers
before trying to override the render behavior.
Do not force a complex unsupported item into conversational mode with custom DOM/UI code.
8. If you have Now Assist, prefer Conversational Catalog Request
On Australia, the stronger architecture is:
User: "I need a laptop" VA / Catalog Agent: -> Determines the Catalog Item -> Reads its questions -> Uses conversation context -> Prefills what it already knows -> Asks for missing required information -> Confirms request -> Submits item
ServiceNow calls this:
Now Assist in Conversational Catalog Request
The Catalog Agent performs dynamic slot filling, meaning the user does not necessarily have to answer the catalog form field-by-field in exactly the same order as the portal form.
9. Existing approvals and notifications do NOT need to be rebuilt
This is another important point.
When the request is submitted using the OOB Request Catalog Item capability, it remains a normal Service Catalog request.
Therefore your existing catalog fulfillment should remain:
Catalog Item -> REQ / RITM -> Flow / Workflow -> Approval -> Catalog Tasks -> Notifications -> Fulfillment
Virtual Agent is simply another request channel.
Do not rebuild:
Approvals Email notifications Catalog Tasks Fulfillment logic
inside the VA topic.
If you also want users/approvers to interact with the request through chat, ITSM Virtual Agent provides OOB actionable notifications for scenarios such as:
Approval request Approval reminder Request approved/rejected Requested Item updated Requested Item commented
These can be activated in Workflow Studio.
10. Recommended final architecture
I would implement:
User starts Virtual Agent
|
v
What do you need?
|
+-------------------------+
| |
v v
Report Issue Request Service
| |
v v
Open IT Ticket 2.0 Search/identify Catalog Item
or custom parent topic |
| v
v Request Catalog Item
Guided questions |
| v
v Conversational variables
Create Incident |
topic block v
| Confirm submission
v |
Incident created v
REQ / RITM created
|
v
Existing Catalog Flow
|
+-------------+-------------+
| | |
v v v
Approval SCTASK NotificationMy recommendation
For Incident:
Simple Incident intake -> OOB Open IT Ticket 2.0 / Create Incident topic block
For a complex Incident questionnaire:
Incident Record Producer -> Conversational request
For Service Request:
Request Catalog Item topic block -> Conversational / Conversational-agentic rendering
This gives you one source of truth for catalog variables and keeps the complete OOB ITSM fulfillment process intact.
I would avoid:
Direct GlideRecord inserts into incident Direct GlideRecord inserts into sc_request/sc_req_item Legacy Cart API Duplicating every Catalog variable as a VA question Modifying OOB Virtual Agent topic blocks Custom Window/DOM handling Rebuilding approvals inside Virtual Agent
Official ServiceNow references:
Create Incident and ITSM reusable topic blocks:
https://www.servicenow.com/docs/r/it-service-management/itsm-virtual-agent/itsm-va-topic-blocks.html
ITSM Virtual Agent OOB topics / Open IT Ticket 2.0:
https://www.servicenow.com/docs/r/it-service-management/itsm-virtual-agent/itsm-va-self-service-topi...
Conversational Catalog Request:
https://www.servicenow.com/docs/r/servicenow-platform/service-catalog/explore.html
Request Catalog Item through Now LLM:
https://www.servicenow.com/docs/r/servicenow-platform/service-catalog/request-topic-blocks-va-llm.ht...
Configure Conversational Catalog Request:
https://www.servicenow.com/docs/r/servicenow-platform/service-catalog/configure-gen-ai-catalog-item....
Variable support:
https://www.servicenow.com/docs/r/servicenow-platform/service-catalog/variables-availability.html
Related accepted ServiceNow Community example for Create Incident:
The accepted solution there follows the same supported pattern:
Parent topic
-> collect Incident inputs
-> call the OOB Create Incident topic block.
Hope this helps!
If this response helped, please mark it as Helpful.
If it resolves your requirement, please Accept it as Solution.
Kind Regards,
Abhishek Pal
