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.
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:
Once these forms are ingested, Moveworks will link your employees to them by redirecting them to
Note: This URL can configured to link to a custom Service Portal or ESC Portal.
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].
Note on inactive fields
If you set the field in your ServiceNow instance to inactive (
false) or always hidden (
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
|System||External Field Type||Moveworks Type|
|ServiceNow||Group||Supported: No experience implications|
|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||Label||Supported: No experience implications|
|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||Text: Single line|
|ServiceNow||URL||Text: Single line|
|ServiceNow||Requested For||Dropdown: Single|
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
container_startvariable is used to group a set of variables. When a form uses a
container_startfield, Moveworks will render any variables in that group that part of the supported list. Most forms that use the
container_startvariable typically have a
container_endvariable as well, however the
container_endvariables are supported.
If there’s a variable between
container_endthat is not supported although Moveworks supports the
container_startvariable, the bot will not be able to render the form natively in chat.
Basic UI policies are supported given that they:
- 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.
- 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.
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.
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.
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.****
- Attributes needed: sys_id, active, hide_sp
- Attributes needed: sys_id, active, title
- Attributes needed: sys_id, active, title
- Attributes needed: default_value, sys_id, question_text, description, mandatory, active, type, choices, lookup_table, lookup_value, reference_qual_condition, variable_set
- Attributes needed: sys_id, active, catalog_item, variable_set, catalog_conditions, reverse_if_false, order, applies_catalog, global
- Attributes needed: sys_id, catalog_item, variable_set, mandatory, cleared, disabled, visible, order, 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
- Attributes needed: sys_id, name, super_class
- 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:
- Attributes needed: sys_id, variables, picture, categories, catalogs, visible_standalone, sys_class_name, ui_policy, client_script, title, name, short_description, description
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 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:
Q: Does Moveworks support the
A: No, not at the moment.
Q: How should I configure my Record Producer?
- 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).
- 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