> This page is for Assistant Platform. > For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.moveworks.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server. # Optional Lab: Advanced Forms > **Note** > > **This lab is optional.** It builds on Lab #7 with multi-domain ingestion, record producers, fillability overrides, and query filters. No core lab depends on it. > > **Sections 1.1 and 1.3 need plugins a stock ServiceNow instance doesn't include:** the Human Resources Catalog comes with HR Service Delivery, and the **Report a Defect** form comes with Agile Development. If your instance doesn't have them, read those sections and complete Sections 1.2, 1.4, and 1.5. > **Info** > > ## Overview > > * **Learning Objectives:** Add a second catalog (HR) to your existing forms ingestion as a new domain, read and reason about fillability errors by severity, apply a fillability override to a record producer, recognize when override can't fix a form and exclude it instead, and explore advanced filtering options. > * **Estimated Time:** About 35 minutes of active configuration, plus ingestion cycles between sections (after Sections 1.1, 1.3, and 1.4). Plan for up to 48 hours elapsed. > * **Prerequisites:** > * [Lab #7](/ai-assistant/getting-started/labs/moveworks-setup/lab-7-basic-forms) complete (IT catalogs ingested) > * For Sections 1.1 and 1.3: the HR Service Delivery and Agile Development plugins on your ServiceNow instance --- ## 🛠️ 1: Walkthrough ### 1.1: Add the Human Resources Catalog as a Second Domain > **Note** > > **Why this matters:** Adding a second catalog with a different domain demonstrates how Moveworks handles multi-domain form ingestion. IT and HR forms are configured independently so they can have different filtering rules and requester field mappings. > **Warning** > > **Heads up: Error 13008, "At most one source config is allowed per integration ID."** > > If you try to create a brand-new ingestion source config for the `snow` integration, Moveworks will reject it with this error. Each integration can have **only one source config**, and multiple domains live inside it as per-domain configurations. > > **The fix:** open the source config you already created in Lab #7 and add a new domain *inside* it. The steps below use that path. 1. In **Moveworks Setup**, navigate to **Forms > Import > Import Settings**. 2. Open the existing ingestion configuration for the `snow` integration (the one you created in Lab #7) 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**. > **Note** > > **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 shows per-domain settings like custom filter queries, **Disallowed form IDs**, **Additional form ID's to ingest**, and additional table names. > > **Basic mode is enough for Section 1.1** (adding the HR catalog as a second domain). **Advanced mode is required later in Section 1.4** (Disallowed form IDs) and **Section 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; on a standard instance 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. ![](/_fern-files/_img/95030ec72c96cf5b4ceceddef68c933133ae8e43b9502d5588ef435b6f8fbb71.webp) 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 #7. 7. In the **Paste Form URL template for HR** field, enter the ESC (Employee Center) URL template: **`text`** ```plain text https://[your-instance].service-now.com/esc?id=sc_cat_item&sys_id={form_id} ``` Replace `[your-instance]` with your ServiceNow instance name, the same one you used for the IT template in Lab #7. 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 noticeably more forms than in Lab #7** (for example, about 182 compared with about 119 for IT only). The exact count varies by instance. Confirm HR forms appear alongside IT forms in the sample list, then click **Confirm Ingestion**. ![](/_fern-files/_img/95abeb10858548dcc98f6d290b6fd082558452e61496af546c0bd7c6575d332a.webp) 9. A **Summary** dialog opens with two required fields: | **Field** | **Suggested Value** | | ------------------ | ------------------------------------------------------------------------ | | **Config Title** | Keep the existing title from Lab #7 (for example, `servicenow_forms_IT`) | | **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. > **Note** > > **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. ![](/_fern-files/_img/a73bb340535460d73299c4a23a246185773f48c04ec9fa2d28632e31fa98e87c.webp) > **Note** > > **Heads-up about HR record producers.** All 34 HR producers use `sn_hr_core.hr_ServicesUtil.createCaseFromProducer`, which derives the case's `opened_for` from the GlideSession user, so Moveworks submissions get attributed to the service account, not the actual employee. Ingesting still demonstrates multi-domain setup; making in-chat submission attribute correctly would need ServiceNow-side changes (out of scope here). See the [Moveworks Help docs](https://docs.moveworks.com/service-management/forms/forms-integration-servicenow) for context on this anti-pattern. Ingestion of the HR catalog will start on the next scheduled run. You can check progress under **Forms > Import > Imported Forms**. ### 1.2: Reading Fillability Errors > **Note** > > **Why is the ingested count lower than the Step 5 preview?** You'll likely see fewer forms in **Forms > Import > Imported Forms** than the wizard's Sample Preview promised (e.g. \~159 ingested vs. \~182 previewed). The preview query only checks `active=true` and catalog membership; ingestion applies a stricter set of validations and drops anything that fails them. The most common reasons a form is dropped at ingestion: > > * **Empty or inactive category** (the form has no category, or its innermost category is set to inactive) > * **No active catalogs remaining** for the form (after blacklist/inactive filters) > * **`visible_standalone` is false** (the catalog item is hidden as a standalone item) > * **`hide_sp` is true** (the item is configured to hide from Service Portal) > * **`sys_class_name` outside the allowlist** (only `sc_cat_item`, `sc_cat_item_producer`, `sc_cat_item_guide`, `pc_software_cat_item`, `pc_hardware_cat_item`, and `x_fls_appportal_catalog_items` are ingested) > * **Empty name** on the form > > You can ignore the gap. It's expected and doesn't affect the demos in Sections 1.3 and 1.4. Once ingestion finishes, open **Forms > Import > Imported 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. ![](/_fern-files/_img/3b10a30c2c72d44a1e614b31dbd6063312886090fc08bdbf8dac46b71dc6eb42.webp) > **Note** > > **Fillability error cheat sheet** > > Every "Not fillable" error falls into one of two severity tiers. The **"Override unfillable forms to be fillable"** setting clears only the first tier; it has no effect on the second. For the canonical reference (every error type, root cause, and remediation), see the [Form Fillability ServiceNow Error Guide](/service-management/forms/forms-integration-servicenow/form-fillability-error-guide). > > | **Error message (from the Ingested Forms panel)** | **Tier** | **Can override fix it?** | > | ------------------------------------------------------------------------ | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | > | `Record producer forms must be manually verified` | Requires override | Yes | > | `Record producer writes tickets to unsupported table` | Requires override | Yes, also add the target table to your ticketing config | > | `Form contains unsupported client scripts` (catalog item client scripts) | Requires override | Yes, or list the script sys_id in "Script ID's to ignore" (this field only covers `sys_script_client` records, not UI policies or ref qualifiers) | > | `Field type attachment/image/signature is unsupported` | Blocking | No, must deflect to portal | > | `Field type rich_text_label is unsupported` | Blocking | No, cosmetic-only, can be ignored but won't render in chat | > | `Only simple reference qualifiers are supported` (JS in qualifier) | Blocking | No, fix the ref qualifier in ServiceNow | > | `Order guide forms are not supported` | Blocking | No, order guides can't be filled in-chat | > | `Insufficient API access` | Blocking | No, request API permissions in ServiceNow | > > **Rule of thumb:** if every error on a form is "requires override," override will work. If even one error is "blocking," override won't help. You either fix it in ServiceNow, exclude the form, or let it deflect to the portal. ### 1.3: Report a Defect (override demo) > **Note** > > **Where this lives:** The Section 1.3 override rule is on **Forms > Advanced Settings > Plugin Settings**. Sections 1.4 (Disallowed form IDs) and 1.5 (Advanced filter) are configured in the ingestion wizard with **Advanced mode** on. **Report a Defect** is a record producer with **two "requires override" errors** and no blocking errors, so it shows the override feature end to end. After override, the form fills in chat and submits cleanly. 1. In **Forms > Import > Imported 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) ![](/_fern-files/_img/08e6ef5af67e08c20a1f32684f5a2ec4c304f66aeb745f789fdede66cd337024.webp) 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`** ```plain 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. ![](/_fern-files/_img/62ecc157acf3acfb051aa34d412410ce41cf714294ca91cbf709da09a912bbe7.webp) 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 > Import > Imported Forms**, refresh **Report a Defect**. It should now show as **Fillable**. ![](/_fern-files/_img/8d3e716ac52cc311b2cbca6c0dc414bfe218fee8deffb423ac2e94caa0fff539.webp) 8. **Test in the AI Assistant:** type `"report a defect"` (or similar). The Assistant surfaces **Report a Defect** with a **Complete this request** button. ![](/_fern-files/_img/0565e9702921b50f88e2bcc2bc32e2c0030bf025d207a27ce3467f0573983256.webp) 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`. ![](/_fern-files/_img/abc2199189a1ace70cc07f126f289683a73a8492f56ece089a13e4924c7ece13.webp) > **Tip** > > **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 #3](/ai-assistant/getting-started/labs/moveworks-setup/lab-3-connectors-api-playground), the **API Playground**.* See if you can craft a `GET /api/now/table/rm_defect` request that returns the record you just submitted. > **Warning** > > **Pause and think about this.** > > If you haven't completed [Lab #8: Ticketing (Core)](/ai-assistant/getting-started/labs/moveworks-setup/lab-8-ticketing-core) yet, there are a lot of ticketing concepts that *would* be required for end-to-end ticket handling, none of which are configured in your instance right now: > > * **Table mappings**: Moveworks Setup needs to know about each destination table (Incident, Request, Request Item, Task) before it treats records there as tickets > * **Table Actions**: Query, Create, Update, Resolve, Reopen permissions per table > * **Routing & workflows**: which intent routes to which ticket type > * **Field mappings**: `caller_id` / `requested_for` / `requested_by` mappings, custom_data, default values > * **Service Portal URL**: for "View in portal" links in chat > * **Polling & notifications**: for status updates and concierge nudges > > Moveworks Setup even *flagged this exact form* earlier with *"Record producer writes tickets to unsupported table `rm_defect`"*. So why did the AI Assistant just successfully file a record from it? > > Think about it: what did the override actually do, and what code path runs when you hit Submit? Does Moveworks need to know about the destination table to call the record producer's submit endpoint? Of all the ticketing concepts above, which ones *would* you actually need to configure to make this form work the way it just did? And which ones come into play only *after* submission? > > Sit with the question for a moment before reading the next callout. > **Note** > > **Why it worked anyway.** Submission hits ServiceNow's record-producer API (`POST /api/sn_sc/servicecatalog/items/{sys_id}/submit_producer`); Moveworks just calls that endpoint, and ServiceNow's own producer script writes to `rm_defect`. There's no Moveworks-side check at submit time for "is this table in your ticketing config?", and the override already cleared the fillability checks. > > Where the ticketing config *would* matter is **after** submission: tracking the record as a ticket in chat (status, reopen, "View in portal", lifecycle). `rm_defect` isn't mapped, so you get a plain confirmation. To get full lifecycle in a real deployment, you'd add `rm_defect` as a new table mapping (out of scope here). ### 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 > Import > Imported 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** | ![](/_fern-files/_img/30e538c3cd41cbcab15bcd262ccb3db49bbb560f8318e672ce4cdbb744e9def1.webp) 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. > **Note** > > **The real fix is in ServiceNow**, not Moveworks Setup. The blocking error requires either rewriting the `parent` field's reference qualifier as a static encoded query (e.g., `sc_catalog=`) instead of JavaScript, or accepting that this form belongs in the ITSM portal. > > **Why not use Script ID's to ignore?** That setting only filters **client scripts** (sys_script_client records on the catalog item). It does not affect **reference qualifier JavaScript**, which is a different ServiceNow construct handled in a separate code path. No Moveworks configuration field can bypass a `REF_QUALIFIER_USES_SCRIPTS` blocking error. The fix has to happen in ServiceNow. 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. > **Note** > > **Catalog scoping.** Item Designer Category Request lives in the **Service Catalog** (IT domain), not the HR catalog you added in Section 1.1. The exclusion below is added under the **IT domain** block of your existing ingestion source config, not under HR. 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`** ```plain text 48bcec40eb0311003623666cd206fe24 ``` ![](/_fern-files/_img/931f45cda2491dd461da9a28ddfd160aea6ea9b42e3fe58ef1f86ca494f9528f.webp) 6. Click **Save**, then advance through the rest of the wizard and **Confirm Ingestion**. In the same Summary dialog from Section 1.1, give the change a new title and summary. 7. After the next ingestion cycle, **Item Designer Category Request** will no longer surface in **Forms > Import > Imported Forms**. | **Field** | **When to Use** | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Disallowed form IDs** | Exclude specific forms by sys_id. Takes priority over all other filter settings (even whitelisted forms). Use for admin-only, deprecated, or genuinely unfillable forms. | | **Additional form ID's to ingest** | Force specific forms to be ingested regardless of filter rules. Useful for forms outside the selected catalog that you still want available. | ### 1.5: Advanced filtering with a custom query (reference) > **Note** > > **This section is reference-only, not a lab step.** You don't need to apply anything here. Read it to understand what Advanced mode adds, then move on. 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 Section 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 catalog scoping you set up in Basic mode in Section 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` query. **IT domain** (Technical Catalog + Service Catalog): **`text`** ```plain text active=true^sc_catalogsIN742ce428d7211100f2d224837e61036d,e0d08b13c3330100c8b837659bba8fb4 ``` **HR domain** (Human Resources Catalog): **`text`** ```plain text active=true^sc_catalogsIN7b0370019f22120047a2d126c42e7075 ``` | Clause | Effect | | ------------------------ | --------------------------------------------------------- | | `active=true` | Skip retired/inactive catalog items | | `sc_catalogsIN` | Restrict to the listed catalogs (comma-separated sys_ids) | > **Note** > > **The power of Advanced mode is everything you can layer on top of that base.** Once you're writing the query yourself, you can narrow further on any field ServiceNow exposes: a specific category (`category.titleINHardware,Software,Access`), a specific class (`sys_class_nameINsc_cat_item,sc_cat_item_producer` to exclude order guides), recency (`sys_updated_on>=javascript:gs.daysAgoStart(180)`), categorization presence (`categoryISNOTEMPTY`), or any combination. The encoded-query syntax matches what you'd build visually in a ServiceNow list filter, so the easiest workflow is: build the filter on `sc_cat_item.list` in ServiceNow, right-click the breadcrumb to **Copy query**, then paste here. > **Warning** > > **The wizard's Step 5 (Review Samples) preview does not reflect your Advanced filter.** The preview is hardcoded to the baseline `active=true^sc_catalogsIN` query and ignores any extra clauses you add (category, class, date, etc.). Those clauses are only applied at actual ingestion. So Step 5's count is a useful upper bound, but if you've narrowed beyond catalog membership, expect the post-ingestion count to be lower than what the preview shows. --- ## ✅ 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 more forms than Lab #7's IT-only ingestion * [ ] Summary dialog completed with Config Title and Change Summary * [ ] Both IT and HR forms appear in **Forms > Import > Imported 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 > Import > Imported Forms** > **Success** > > **Next:** Return to the [Moveworks Setup labs](/ai-assistant/getting-started/labs/moveworks-setup) to continue with the core labs or pick another optional lab. --- ## 🪞 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 make a record producer that's safe to fill in chat fillable * 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) | **Field Name** | **Action / Value to Enter** | | ----------------------------------- | ----------------------------------------------------------------------------- | | **Catalog** | Human Resources Catalog (`7b0370019f22120047a2d126c42e7075`) | | **Select Domain** | `HR` | | **Paste Form URL template for HR** | `https://[your-instance].service-now.com/esc?id=sc_cat_item&sys_id={form_id}` | | **Config Title** (Summary dialog) | The existing title from Lab #7 | | **Change Summary** (Summary dialog) | `add HR domain for catalog` | ### Fillability Override Example (Report a Defect, from Section 1.3) The setting below lives at **Forms > Advanced Settings > Plugin Settings**. (Section 1.4 and 1.5 settings live in the ingestion wizard's Advanced mode.) | **Setting** | **DSL Rule / Value** | | -------------------------------------------- | ---------------------------------------------------------------------------------- | | **Override unfillable forms to be fillable** | `form_source_id.$LOWERCASE() IN ["6377b7a77f000001070ec31b396896fe".$LOWERCASE()]` | ### Exclusion Example (Item Designer Category Request, from Section 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. | **Field** | **Value** | | ----------------------------------- | ---------------------------------- | | **Disallowed form IDs** (IT domain) | `48bcec40eb0311003623666cd206fe24` | ### 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). | **Setting** | **Scope** | **What It Controls** | | ---------------------------------------------- | ----------------- | -------------------------------------------------------------------------------------------------------------------- | | Catalog IDs to ingest | Per-domain | Which service catalogs to pull forms from for this domain | | Filter type (Default filter / Advanced filter) | Per-domain | Choose between ITSM-mirrored defaults or a custom encoded query | | Disallowed form IDs | Per-domain | Exclude specific forms by sys_id (highest priority; takes precedence over whitelists) | | Additional form ID's to ingest | Per-domain | Force-include specific forms regardless of filter rules | | Additional table names to ingest | Per-domain | Ingest forms from custom tables extending `sc_cat_item` | | Form requester field names | Integration-level | Multi-value list of ServiceNow fields to auto-populate with the requesting user (e.g. `requested_for`, `opened_for`) | | Script ID's to ignore | Integration-level | Skip specific client scripts that block native rendering | | Override unfillable forms to be fillable | Integration-level | Force "requires override" forms to be fillable via a DSL rule | | Override fillable forms to deflect to ITSM | Integration-level | Force specific fillable forms to deflect to portal instead | | Enable form filling for eligible forms | Integration-level | Master toggle for whether eligible forms can be filled in chat | | Enable form deflection to ITSM | Integration-level | Show portal link for unfillable forms instead of hiding them |