Forms Integration - ServiceNow
Overview
You use Moveworks Form Integration with ServiceNow to:
- Enable powerful automations, leveraging Workflows or Flow Designer.
- Trigger custom approval workflows in ServiceNow
- Structure inputs from your employees for faster time to resolution.
What types of forms does Moveworks ingest?
Moveworks Bot will ingest Catalog Items available in your Service Catalog, based on the catalogs configured in Moveworks. When Moveworks ingests forms, it applies a number of filters based on attributes on each catalog item:
- visible_standalone = true
- hide_sp = false
- category is active
- category is not empty
- catalog is active
- catalog is not empty
- catalog or tag is not filtered out (based on what you have configured in your Moveworks implementation)
- sys_class_name is one of the following:
sc_cat_item
pc_software_cat_item
pc_hardware_cat_item
sc_cat_item_producer
sc_cat_item_guide
Once these forms are ingested, Moveworks will link your employees to them by redirecting them to {base_service_portal_url}?id=sc_cat_item&sys_id={form_sys_id}
.
Note: This URL can configured to link to a custom Service Portal or ESC Portal.
When does Moveworks start ingesting Forms?
Moveworks starts ingesting forms every day at 6pm Pacific time. The entire process takes place over a few hours, and ingests new catalog items, as well as any updates or removals that may have happened over the course of the day.
Note on triggering
This is only to make the form available for basic triggering (using the form title for example). Typically it takes a few days to a week for the form to become more robust in triggering for different user utterances. If you continue to see issues well after the form has been made available in your ServiceNow instance, please contact Moveworks Support at [email protected].
Form Filling
Supported fields
Note on inactive fields
If you set the field in your ServiceNow instance to inactive (
active
=false
) or always hidden (hidden
=true
orvisible
=false
), Moveworks will ignore this setting. Please remove the field if it is truly inactive, or add a UI policy (with condition =true
) that hides the field.
Moveworks converts your ServiceNow variables into internal supported types where possible.
- Moveworks does not support fields that have names longer than 75 characters
- Moveworks does not display the text of a container field header unless it is a checkbox group
Form Field Type Conversion
System | External Field Type | Moveworks Type |
---|---|---|
ServiceNow | Group | Supported: No experience implications |
ServiceNow | Yes/No | Dropdown: Single |
ServiceNow | Multi Line Text | Text: Multi-line |
ServiceNow | Multiple Choice | Dropdown: Single |
ServiceNow | Numeric Scale | Dropdown: Single |
ServiceNow | Select Box | Dropdown: Single |
ServiceNow | Single Line Text | Text: Single line |
ServiceNow | Checkbox | Checkbox: Single |
ServiceNow | Reference | Dropdown: Single |
ServiceNow | Date | Date |
ServiceNow | Datetime | Datetime |
ServiceNow | Label | Supported: No experience implications |
ServiceNow | Break | Unsupported |
ServiceNow | Macro | Unsupported |
ServiceNow | UI Page | Unsupported |
ServiceNow | Wide Single Line Text | Text: Single line |
ServiceNow | Macro with Label | Unsupported |
ServiceNow | Lookup Select Box | Dropdown: Single |
ServiceNow | Container Start | Supported: No experience implications |
ServiceNow | List Collector | Dropdown: Multiple |
ServiceNow | Lookup Multiple Choice | Dropdown: Single |
ServiceNow | HTML | Text: Single line |
ServiceNow | Container Split | Unsupported |
ServiceNow | Masked | Unsupported |
ServiceNow | Text: Single line | |
ServiceNow | URL | Text: Single line |
ServiceNow | IP | Unsupported |
ServiceNow | Duration | Unsupported |
ServiceNow | Requested For | Dropdown: Single |
ServiceNow | Attachment | Unsupported |
For all drop downs, Moveworks ingests all the options from the reference tables, applying any simple reference qualifiers (static filters on the underlying table) will be okay. Make sure not to use any dynamic comparators either (as pictured below) if you want your form to be fillable in chat. Complex reference qualifiers are not supported.
If there are more than 100,000 options after applying the reference qualifier, ingestion is skipped and the form is marked as not fillable.
Note on container_start + container_end fields
The
container_start
variable is used to group a set of variables. When a form uses acontainer_start
field, Moveworks will render any variables in that group that part of the supported list. Most forms that use thecontainer_start
variable typically have acontainer_end
variable as well, however thecontainer_end
variables are supported.If there’s a variable between
container_start
andcontainer_end
that is not supported although Moveworks supports thecontainer_start
variable, the bot will not be able to render the form natively in chat.
Supported dynamic behavior
Basic UI policies are supported given that they:
- Contain no JavaScript
- Are not applied to any container-like field types (including Checkbox containers).
Client UI Scripts are not supported
Be sure to disable client UI scripts on any forms that you want fillable in bot.
Additional details on Checkbox group containers
- Checkboxes that are in a group and marked as required. Moveworks will always mark all checkboxes in a checkbox group as optional.
- UI policies that apply to a checkbox group container. Moveworks currently only honors UI policies that apply to variables or variable sets.
- Note: Moveworks does not follow UI policies that apply to containers.
Submitting on behalf of the user
To submit on behalf of the user, Moveworks will provide the submitter as a field in the submission.
- First, Moveworks will look for an exact match for a requested_for variable.
- Then, Moveworks will look to see if any variable name contains requested_for (e.g. u_requested_for). If there are multiple, the field closest to the bottom of the form will be used.
Once the field is defined, that field will be pre-populated when the form is rendered and used when submitting the form.
Simple Reference Qualifiers are supported
Moveworks offers support for simple reference qualifiers on all types of reference fields, given that they contain less than 100,00 options after the reference qualifier is applied. For user fields with unsupported reference qualifiers, Moveworks will default to using the full list of users.
ServiceNow Permission Requirements
In order for us to display your forms within your bot we will need your help getting the right permissions setup. The required attributes listed below are not exhaustive. In addition, Moveworks expects a certain schema of nested attributes. Additional table access may also be required as the Moveworks form skill evolves.****
sc_cat_item
- Attributes needed: sys_id, active, hide_sp
sc_catalog
- Attributes needed: sys_id, active, title
sc_category
- Attributes needed: sys_id, active, title
item_option_new
- Attributes needed: default_value, sys_id, question_text, description, mandatory, active, type, choices, lookup_table, lookup_value, reference_qual_condition, variable_set
catalog_ui_policy
- Attributes needed: sys_id, active, catalog_item, variable_set, catalog_conditions, reverse_if_false, order, applies_catalog, global
catalog_ui_policy_action
- Attributes needed: sys_id, catalog_item, variable_set, mandatory, cleared, disabled, visible, order, ui_policy
sys_ui_policy
- Attributes needed: sys_id, short_description, description, ui_type, script_true, script_false, reverse_if_false, sys_name, run_scripts, order, active, on_load, conditions
sys_db_object
- Attributes needed: sys_id, name, super_class
sys_dictionary
- Attributes needed: element, display, name
In addition to the above tables, the Moveworks service account will need “read” access to all tables that are referenced in Reference / Choice / List collector fields (to be able to display the options to the user) and need access to the form via the Service Catalog API:
GET: https://{}.service-now.com/api/sn_sc/v1/servicecatalog/items/<form_id>
- Attributes needed: sys_id, variables, picture, categories, catalogs, visible_standalone, sys_class_name, ui_policy, client_script, title, name, short_description, description
FAQ
Q: How does the requestor get populated when a form is filled in Moveworks?
A: When a user chooses to fill out a form in the Moveworks bot, the requestor on the resulting ticket will always be the user chatting with the bot. Which variable is used to capture the requestor is based on how your form is configured:
- First Moveworks will look for an exact match for a requested_for variable. If this is present, that is pre-populated when the form is rendered in the WebUI and used when submitting the form.
- If this field does not exist, Moveworks will look to see if any variable name contains requested_for (e.g. u_requested_for) and the last match that is found is the field used to pre-populate the requestor.
- If all forms use a specific (custom) field for the requestor, Moveworks can be configured to always look for this specific field and use it to capture the requestor. Please coordinate with your Moveworks Customer Success team as this requires a change in the Moveworks configuration for your bot. Once configured, those requestor fields will also be pre-populated.
Q: Does Moveworks support Two-Step Checkout? (only applicable for the Legacy Service Catalog UI)
A: No, this must be disabled.
- This behavior is governed by the system property
glide.sc.checkout.twostep
. - If this is enabled, this prevents the bot from correctly submitting catalog items that don’t have a “Requested For” field on behalf of the user - when submitted, they will incorrectly have “Requested For” populated as the bot account.
- Thus make sure
glide.sc.checkout.twostep
is set to false.
Q: Does Moveworks support record producers?
A: Yes, as long as the record producer meets the following requirements:
- The record producer must create a ticket that is available in Moveworks Concierge. You can work with your customer success team to configure your ticket table for Concierge.
- The record producer must be built with Generated Record Data from Variables only, not from a Template.
- The record producer script must not use the function
gs.getUserId()
or any other GlideSession APIs functions. This can lead to strange behavior where the caller field on the resulting ticket belongs to the service account rather than the employee that filled out the record producer. Instead, Moveworks recommends adding a field on the Record Producer for the requesting user e.g:requested_for
.
Q: Does Moveworks support the meta
field?
A: No, not at the moment.
Q: How should I configure my Record Producer?
A:
- Record Producer’s Table Name is set to a table that is configured in Moveworks backend.
- Record Producer has a variable dedicated to the submitter of the form. The submission script uses that attribute to populate the subject of the ticket (in this case the callerid).
![](https://files.readme.io/ba3d241-Untitled-_2023-03-13T135035.369.png) - Category & Catalog are both set on the Record Producer.
- No Catalog Client Scripts on the Record Producer.
- Share the Record Producer's ID with your Moveworks Customer Success team.
Updated 3 months ago