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 or visible = 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

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 a container_start field, Moveworks will render any variables in that group that part of the supported list. Most forms that use the container_start variable typically have a container_end variable as well, however the container_end variables are supported.

If there’s a variable between container_start and container_end that is not supported although Moveworks supports the container_startvariable, the bot will not be able to render the form natively in chat.

Supported dynamic behavior

Basic UI policies are supported given that they:

1. Contain no JavaScript
2. 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

1. Checkboxes that are in a group and marked as required. Moveworks will always mark all checkboxes in a checkbox group as optional.
2. UI policies that apply to a checkbox group container. Moveworks currently only honors UI policies that apply to variables or variable sets.
   1. 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:

1. 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.
2. The record producer must be built with Generated Record Data from Variables only, not from a Template.
3. 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:

1. Record Producer’s Table Name is set to a table that is configured in Moveworks backend.
   
2. 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).
   
3. Category & Catalog are both set on the Record Producer.
   
4. No Catalog Client Scripts on the Record Producer.
   
5. Share the Record Producer's ID with your Moveworks Customer Success team.