Dynamic form fields not populating during RPA bot-driven incident creation

BPM ServiceNow
, , , , , , , ,
1

Our RPA bot submits incidents via ServiceNow Tokyo’s forms-management module using REST API, but dynamic fields that depend on client script execution aren’t populating correctly. This causes ticket routing delays since the assignment group field remains empty.

When a human user creates an incident through the UI and selects Category=‘Hardware’, the client script automatically populates Subcategory options and sets the Assignment Group based on location. However, when our RPA bot posts the same data via REST API, these dynamic fields stay blank.

Example API payload:


{
  "category": "Hardware",
  "location": "Building-A",
  "short_description": "Laptop keyboard malfunction"
}

We’ve verified field-level permissions - the service account has write access to all fields. The issue seems related to client script execution not triggering via REST API versus UI automation. Should we switch to UI automation, or is there a way to trigger client-side logic through the API? Our bot processes 150+ incidents daily, so performance matters.

2

Client scripts run in the browser, not on the server side. REST API calls bypass all client-side logic entirely. You need to either use business rules on the server side or explicitly set all dependent field values in your API payload.

3

This is a classic REST API vs UI automation trade-off. REST API is faster and more scalable but skips client scripts. UI automation (using UI API or browser automation) triggers client scripts but is slower and more fragile.

For your use case with 150+ daily incidents, I’d recommend staying with REST API but implementing server-side business rules to replicate the client script logic. Create a ‘before’ business rule on the incident table that checks category and location, then populates assignment group accordingly. This gives you API performance with dynamic field population.

Alternatively, your RPA bot could call a scripted REST API that executes the same logic server-side and returns the calculated field values, which the bot then includes in the incident creation payload.

4

One thing to watch out for - field-level permissions can behave differently for business rules versus client scripts. Make sure your business rule runs with elevated privileges if your service account doesn’t have direct write access to assignment group. Use ‘setWorkflow(false)’ if you want to bypass additional business rules during testing.

5

Absolutely. Business rules can query any table the client scripts can access. You’d use GlideRecord to query your custom mapping table. The logic would be nearly identical to your client script, just server-side syntax instead of client-side. Performance-wise, server-side queries are actually faster since there’s no browser round-trip.

The key advantage is your RPA bot can continue using REST API without modifications, and the business rule will handle all incidents uniformly whether they come from UI, API, email, or integration.

6

Here’s a comprehensive solution addressing all three critical aspects:

Client Script Execution via API: Client scripts cannot execute through REST API calls - they’re fundamentally browser-based. Your options are:

  1. Replicate logic server-side (recommended for your volume)
  2. Use ServiceNow’s Table API with ‘sysparm_display_value=all’ to get reference field data
  3. Create a custom REST endpoint that executes the logic and returns calculated values

REST API vs UI Automation Decision: For 150+ daily incidents, REST API is the right choice. UI automation would be 5-10x slower and prone to failures. Stick with REST API and implement server-side logic.

Solution - Business Rule Implementation: Create a business rule to replicate your client script logic:

  • Name: “Auto-populate Incident Assignment”
  • Table: Incident [incident]
  • When: before, Insert/Update
  • Conditions: Category changes OR Location changes
  • Script:

var mapper = new GlideRecord('u_assignment_mapping');
mapper.addQuery('category', current.category);
mapper.addQuery('location', current.location);
mapper.query();
if (mapper.next()) {
  current.assignment_group = mapper.assignment_group;
  current.subcategory = mapper.subcategory;
}

Field-Level Permissions: Ensure your service account has these roles:

  • itil (for incident write access)
  • rest_api_explorer (for API access)
  • Plus explicit ACL for assignment_group field if restricted

Verify field-level security by checking System Security > Access Control (ACL) for incident.assignment_group. If there’s a write ACL, add your service account’s role to the required roles list.

RPA Bot Enhancement: Your bot’s payload should now only include base fields:


{
  "category": "Hardware",
  "location": "Building-A",
  "short_description": "Laptop keyboard malfunction",
  "caller_id": "user_sys_id"
}

The business rule will automatically populate assignment_group and subcategory based on your custom mapping table. Test thoroughly with different category/location combinations to ensure mapping coverage. Monitor business rule execution logs in System Logs > Business Rules to verify it’s firing correctly for API-created incidents.