Lab #4b: Advanced Forms

🛠️ 1: Walkthrough

1.1: Add the Human Resources Catalog as a Second Domain

1. In Moveworks Setup, navigate to Forms > Ingestion.

2. Open the existing ingestion configuration for the snow integration (the one you created in Lab 4a) to launch the ingestion wizard.

3. Step through the wizard to Step 3: Select Form Catalogs. The five wizard steps are: Select Connectors → Setup Ingestion → Select Form Catalogs → Provide Sample URL Templates → Review Samples.

   About the Advanced mode toggle on this step. In the top-right corner of the Select Form Catalogs page you’ll see an Advanced mode toggle. The subtitle reads: “Switch to advanced mode to include complex filters for ingestion and more such controls.” Toggling Advanced mode unlocks per-domain settings like custom filter queries, Disallowed form IDs, Additional form ID’s to ingest, and additional table names.

   Basic mode is sufficient for §1.1 (adding the HR catalog as a second domain). However, Advanced mode is required later in §1.4 (Disallowed form IDs) and §1.5 (Advanced filter). You can toggle between modes freely; nothing saves until you confirm ingestion at the end of the wizard.

4. In the catalog table, check the Human Resources Catalog row. (The sys_id should already appear in the Catalog IDs column; in most training instances it’s 7b0370019f22120047a2d126c42e7075.)

5. In the Select Domain dropdown for that row, choose HR. All three catalogs (Technical Catalog (IT), Service Catalog (IT), and Human Resources Catalog (HR)) should now be checked with their domain tags assigned.

   

6. Click Next to advance to Step 4: Provide Sample URL Templates. You’ll now see a URL template field for each domain. The IT template should already be populated from Lab 4a.

7. In the Paste Form URL template for HR field, enter the ESC (Employee Center) URL template:

   text

   https://[your-servicenow-instance-name].lab.service-now.com/esc?id=sc_cat_item&sys_id={form_id}

   Replace [your-servicenow-instance-name] with your ServiceNow instance hostname (the same one you used for the IT template in Lab 4a, something like mvwrks-apr-7294-instructor-0001). The {form_id} placeholder is required; Moveworks substitutes it with each ingested form’s sys_id at runtime.

8. Click Next to advance to Step 5: Review Samples. Moveworks will show a preview of forms it found with the current config. You should see approximately 182 forms, up from the ~119 forms you saw with IT-only ingestion in Lab 4a. (The exact count may vary by training instance, but it should be significantly higher than Lab 4a’s baseline.) Confirm HR forms appear alongside IT forms in the sample list, then click Confirm Ingestion.

   

9. A Summary dialog opens with two required fields:

   Field	Suggested Value
   Config Title	form_ingestion
   Change Summary	add HR domain for catalog

   Both fields are mandatory. The Config Title names this ingestion configuration for future reference; the Change Summary creates an audit-trail entry describing what you changed in this revision. Click Confirm Ingestion in the dialog to finalize.

   Sample values for illustration only. The values above are suggestions to keep this lab consistent. Your organization can use any naming convention. The Config Title should describe the ingestion config; the Change Summary should describe the specific revision being saved. Both are surfaced in the configuration’s change history, so future-you (or another admin) can quickly see what changed and why.

   

Ingestion of the HR catalog will start on the next scheduled run. You can check progress under Forms > Ingested Forms.

1.2: Reading Fillability Errors

Once ingestion finishes, open Forms > Ingested Forms and sort by the Fillable column. Many forms will show as Not fillable with one or more optimization errors. Before reaching for overrides, learn to read the errors.

Click any unfillable form to open its detail panel. The Form optimization errors section lists each error with a type, description, and a “Learn how to resolve” link.

1.3: Report a Defect (override demo)

Report a Defect is a record producer with two “requires override” errors and no blocking errors. That makes it an ideal case for demonstrating the override feature end-to-end. After override, the form fills in chat and submits cleanly.

1. In Forms > Ingested Forms, find Report a Defect (sys_id: 6377b7a77f000001070ec31b396896fe) and click into it. You should see 2 Form optimization errors, both “requires override”:

   • “Record producer forms must be manually verified to be working correctly” (IS_RECORD_PRODUCER)
   • “Record producer writes tickets to unsupported table rm_defect” (UNSUPPORTED_RECORD_PRODUCER_TABLE)

   

2. Copy the sys_id from the form detail panel.

3. Navigate to Forms > Advanced Settings > Plugin Settings in the sidebar.

4. Scroll to the Override unfillable forms to be fillable field (the description reads: “Force an override of unfillable forms to be fillable in chat. Note that this only applies to ServiceNow forms due to a client script, UI Policy Script, or virtue of being a Record Producer.”).

5. In the DSL Editor, enter this rule:

   text

   form_source_id.$LOWERCASE() IN ["6377b7a77f000001070ec31b396896fe".$LOWERCASE()]

   The IN [...] syntax is a list. You can extend it later with more form sys_ids separated by commas, each wrapped in .$LOWERCASE(). The case-normalization ensures the rule matches regardless of how ServiceNow returns the sys_id casing.

   

6. Click Validate Syntax to confirm the DSL parses. Then click Save and wait for the next ingestion cycle to re-index the form.

7. Back in Forms > Ingested Forms, refresh Report a Defect. It should now show as Fillable.

   

8. Test in the AI Assistant: type "report a defect" (or similar). The Assistant surfaces Report a Defect with a Complete this request button.

   

   Click Complete this request to open the form modal in chat. It only has two fields: Short description and Description (both mandatory). Fill them in and submit. Verify a new record appears in ServiceNow at rm_defect.list.

   

   Try it from a different angle. What’s another way you could verify the record landed, without opening ServiceNow’s UI? Hint: you set up something for this in Lab 1, the API Playground. See if you can craft a GET /api/now/table/rm_defect request that returns the record you just submitted.

1.4: Item Designer Category Request (when override isn’t enough)

Not every unfillable form can be rescued by override. Item Designer Category Request is the canonical example: override handles two of its three errors, but one is Blocking and nothing clears it.

1. In Forms > Ingested Forms, open Item Designer Category Request (sys_id: 48bcec40eb0311003623666cd206fe24). You’ll see 3 Form optimization errors:

   Error	Tier	Override fixes it?
   Record producer forms must be manually verified	Requires override	Yes
   Record producer writes tickets to unsupported table sc_ic_category_request	Requires override	Yes (but you’d also need to map that table in ticketing)
   Only simple reference qualifiers are supported on the parent field (uses JavaScript)	Blocking	No

   

2. Even if you applied an override rule for this form’s sys_id, the reference qualifier on the parent field still uses JavaScript (javascript:'sc_catalog='+current.variables.sc_catalog), which Moveworks can’t evaluate in chat. The form would stay unfillable.

Since Item Designer Category Request is an admin-facing form that employees won’t use through the AI Assistant anyway, the pragmatic choice is to exclude it from ingestion entirely.

3. Navigate to Forms > Import > Import Settings and open your existing snow ingestion source config. Step through the wizard to Step 3: Select Form Catalogs, and toggle Advanced mode on (top-right of the page). Without Advanced mode, the per-domain configuration block stays collapsed and the Disallowed form IDs field is hidden.

4. Expand the IT domain’s per-domain configuration block, then scroll to the Disallowed form IDs field (description: “Form IDs you do not want ingested. This setting will be respected regardless of other options.”). No DSL rule is needed here. The field is a plain Value / Display Value list; you enter the form’s sys_id directly.

5. Click + to add a new entry. In the Value column, paste the sys_id below. Leave the Display Value column blank, it’s optional and not used by the filter.

   text

   48bcec40eb0311003623666cd206fe24

   

6. Click Save, then advance through the rest of the wizard and Confirm Ingestion. You’ll see the same Summary dialog from §1.1; give the change a fresh title and summary.

7. After the next ingestion cycle, Item Designer Category Request will no longer surface in Forms > Ingested Forms.

1.5: Advanced filtering with a custom query (reference)

Instead of the Default filter, you can switch to an Advanced filter with a custom ServiceNow encoded query. The setting lives in the same per-domain block on the wizard’s Step 3 (Select Form Catalogs) that you used in §1.4. Toggling Advanced mode exposes a Filter type dropdown per domain; switching it to Advanced filter opens an encoded-query field.

The two queries below reproduce the same catalog scoping you already set up in Basic mode in §1.1 (IT pulls from Technical + Service catalogs; HR pulls from the Human Resources catalog). Writing the scoping out as an explicit query produces the same form count as Basic mode, because Basic mode internally generates an equivalent active=true^sc_catalogsIN<sys_ids> query.

IT domain (Technical Catalog + Service Catalog):

active=true^sc_catalogsIN742ce428d7211100f2d224837e61036d,e0d08b13c3330100c8b837659bba8fb4

HR domain (Human Resources Catalog):

active=true^sc_catalogsIN7b0370019f22120047a2d126c42e7075

✅ 2: Verification & Next Steps

1. Multi-domain ingestion working:
   • Human Resources Catalog checked in the existing snow source config (no Error 13008)
   • Domain HR selected for that row
   • HR URL template set to /esc?id=sc_cat_item&sys_id={form_id} on Step 4
   • Step 5: Review Samples shows approximately 182 forms (vs. ~119 from Lab 4a IT-only)
   • Summary dialog completed with Config Title and Change Summary
   • Both IT and HR forms appear in Forms > Ingested Forms after the next ingestion cycle
2. Override demo (Report a Defect):
   • Report a Defect shows as Fillable after the override rule is applied
   • Typing "report a defect" in the AI Assistant starts conversational form filling
   • Submitting the form creates a new record at rm_defect.list in ServiceNow
3. Exclusion demo (Item Designer Category Request):
   • Item Designer Category Request no longer appears in Forms > Ingested Forms

💡 3: Reflecting on This Configuration

Through this lab, you’ve learned the following:

• How to add a second domain (HR) to an existing forms ingestion source config, and why Moveworks rejects a second source config for the same integration with Error 13008
• That stock ServiceNow HRSD record producers don’t expose a requester variable (they rely on hr_ServicesUtil.createCaseFromProducer, a session-based anti-pattern), so in-chat submission needs ServiceNow-side fixes
• How to read fillability errors and distinguish Requires override from Blocking severity
• How to apply a fillability override with a DSL rule to unlock a record producer that’s safe to fill in chat
• When override genuinely won’t help, and how to exclude the form via Disallowed form IDs
• How to use Advanced filter for custom form selection

⚙️ 4: Configuration Details

Use the tables below to fill in the required fields accurately.

HR Catalog (added to the existing snow source config in Basic mode)

Fillability Override Example (Report a Defect, from §1.3)

The setting below lives at Forms > Advanced Settings > Plugin Settings. (§1.4 and §1.5 settings live in the ingestion wizard’s Advanced mode instead.)

Exclusion Example (Item Designer Category Request, from §1.4)

Disallowed form IDs lives on Forms > Import > Import Settings, inside the per-domain block. Item Designer Category Request is in the IT/Service Catalog, so the entry goes under the IT domain block.

Forms Ingestion Settings Reference

All fields below live on the Select Form Catalogs wizard step in Advanced mode. The Scope column shows whether the field is per-domain (inside a ServiceNow related configurations block) or integration-level (shared across all domains under the same integration).