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.

Form Filling

Supported fields

Moveworks converts your ServiceNow variables into internal supported types where possible.

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.

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).

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.

  • You can do this by navigating to Forms > Advanced Settings under the Ticketing Automation Module. Look for the Form requester field names field.

    

  • Here you can define the name of the custom field which needs to be pre-populate with the current user info.

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 Attachment Upload for Ingested Forms

A: No, This is not supported.

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.
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 themeta field?

A: No, not at the moment.

Q: My ServiceNow form is ingested and listed in Moveworks Setup, but it isn’t surfacing in the Moveworks bot. Why?

A: When a form is “Serving” but not appearing, it usually indicates a permissions mismatch or User Criteria restriction. Moveworks mirrors your ServiceNow security model to ensure users only see what they are entitled to.

Troubleshooting Steps

1. Verify User Criteria Moveworks strictly adheres to the “Available For” and “Not Available For” related lists on your ServiceNow Catalog Item. If the user (or the Moveworks Service Account) is restricted here, the form will not surface.
2. Check Catalog & Category Status Ensure the form is assigned to an Active Category and Catalog. If the parent category is inactive or hidden, the form may be ingested but remain unreachable.
3. Confirm Search Settings Ensure the “Hide on Service Portal” or “No Search” flags aren’t inadvertently checked in ServiceNow, as these can sometimes impact how items are indexed.

Q: How should I configure my Record Producer?

A: Record Producers can be filed by Moveworks using a default payload which leverages.

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 caller_id).
3. Category & Catalog are both set on the Record Producer.
4. No Catalog Client Scripts on the Record Producer.
5. Once you have your Record Producer ID you can set it up for creation by following this guide on How To Configure Record Producers for Ticket Creation