fix(servicenow): servicenow triggers

[waleedlatif1]

Summary

• servicenow triggers

Type of Change

• New feature

Testing

tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[cursor]

PR Summary

Medium Risk
Moderate risk because it introduces new ServiceNow trigger definitions and wires them into the trigger registry and block config, which could affect trigger selection/rendering and webhook payload handling. Changes are largely additive and scoped to trigger metadata/configuration rather than core execution logic.

Overview
Adds first-class ServiceNow trigger support by introducing trigger configs for incident/create+update, change request create+update, and a generic servicenow_webhook, plus shared utilities for setup instructions, extra fields, and output schemas.

Wires these triggers into the app by registering them in TRIGGER_REGISTRY and enabling them on ServiceNowBlock (injecting the trigger sub-blocks via getTrigger(...) and exposing an available trigger list).

Updates integrations.json to populate trigger lists/counts for multiple integrations (notably Greenhouse, HubSpot, Resend, Salesforce, ServiceNow, and Vercel), including “all events” webhook trigger entries where applicable.

^{Reviewed by Cursor Bugbot for commit 85291dc. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Apr 6, 2026 8:39pm

[greptile-apps]

Greptile Summary

This PR adds 5 ServiceNow webhook triggers (incident_created, incident_updated, change_request_created, change_request_updated, and a generic webhook) by creating trigger config files, registering them in the trigger registry, and wiring them into the existing ServiceNow block.

The trigger config structure, barrel exports, block integration, and registry registration all follow established patterns correctly. However, there is a critical gap: unlike every other multi-event provider (Jira, GitHub, Notion, etc.), no servicenow webhook provider handler was added to lib/webhooks/providers/. This means:

• All 5 trigger types behave identically at runtime — there is no matchEvent to route incident_created vs incident_updated vs change_request_* events, so any ServiceNow webhook will fire every configured workflow regardless of trigger type selection.
• The optional tableName sub-block filter silently has no effect because there is no shouldSkipEvent implementation.
• The structured output fields (sysId, shortDescription, urgency, etc.) will only be populated if the user's Business Rule script happens to use the exact same key names, since there is no formatInput normalization.

Key changes:

• triggers/servicenow/ — 6 new files (5 trigger configs + utils)
• triggers/registry.ts — 5 new trigger registrations
• blocks/blocks/servicenow.ts — trigger subBlocks and triggers config added
• integrations.json — trigger metadata added for the landing page

Confidence Score: 3/5

Not safe to merge as-is — trigger type differentiation is fundamentally broken without a ServiceNow webhook provider handler

The P1 issue (missing provider handler in lib/webhooks/providers/) means all 5 new trigger types behave identically at runtime. There is no event matching, so a workflow configured for 'Incident Created' will fire on 'Incident Updated' and 'Change Request Created' events too. The tableName filter also has no effect. These are the core features of the PR, and they don't work without the missing handler.

A new file apps/sim/lib/webhooks/providers/servicenow.ts needs to be created and registered in apps/sim/lib/webhooks/providers/registry.ts with matchEvent, shouldSkipEvent, and formatInput implementations

Important Files Changed

Filename	Overview
apps/sim/lib/webhooks/providers/registry.ts	Not changed in this PR, but missing a 'servicenow' entry — all 5 new triggers fall back to defaultHandler with no event matching, table filtering, or payload transformation
apps/sim/triggers/servicenow/webhook.ts	New generic ServiceNow webhook trigger config; structurally correct but lacks a backing provider handler for event filtering and payload transformation
apps/sim/triggers/servicenow/utils.ts	Shared utility functions for all ServiceNow triggers; tableName filter declared in UI but has no runtime enforcement without a provider handler
apps/sim/triggers/servicenow/incident_created.ts	Primary ServiceNow incident created trigger with dropdown; follows existing patterns correctly
apps/sim/triggers/servicenow/incident_updated.ts	Secondary ServiceNow incident updated trigger; structure consistent with other secondary triggers
apps/sim/triggers/servicenow/change_request_created.ts	ServiceNow change request created trigger; correct structure and output mapping
apps/sim/triggers/servicenow/change_request_updated.ts	ServiceNow change request updated trigger; correct structure and output mapping
apps/sim/triggers/servicenow/index.ts	Clean barrel export for all 5 ServiceNow triggers
apps/sim/triggers/registry.ts	5 ServiceNow triggers correctly registered in alphabetical order
apps/sim/blocks/blocks/servicenow.ts	ServiceNow block updated with trigger support via getTrigger() spread; trigger differentiation won't work at runtime without a provider handler
apps/sim/app/(landing)/integrations/data/integrations.json	ServiceNow integration landing page updated with 5 new trigger entries; data looks correct

Sequence Diagram

sequenceDiagram
    participant SN as ServiceNow
    participant WH as Webhook Handler
    participant PH as Provider Registry
    participant WF as Workflow Executor

    SN->>WH: POST /api/webhooks/trigger/[path]
    WH->>PH: getProviderHandler('servicenow')
    Note over PH: ⚠️ No 'servicenow' entry<br/>Falls back to defaultHandler
    PH-->>WH: defaultHandler (bearer token only)
    Note over WH: matchEvent() → not implemented<br/>shouldSkipEvent() → not implemented<br/>formatInput() → not implemented
    WH->>WF: Execute with raw body
    Note over WF: ALL trigger types fire<br/>regardless of event type<br/>tableName filter ignored

Loading

Comments Outside Diff (1)

1. apps/sim/lib/webhooks/providers/registry.ts, line 44-81 (link)

   Missing ServiceNow webhook provider handler

   Every other provider in this registry has a dedicated handler (e.g. jiraHandler, githubHandler, notionHandler). ServiceNow has no entry here, so the defaultHandler is used — which only does optional bearer-token auth and has no matchEvent, formatInput, or shouldSkipEvent.

   This causes three concrete problems for the new triggers:

   1. No event-type filtering — matchEvent is never called, so a workflow set up with the servicenow_incident_created trigger will also fire for every incident_updated, change_request_created, etc. event sent to that webhook URL. The four specific trigger types are functionally identical to the generic webhook trigger.

   2. No table-name filtering — the optional tableName sub-block added in triggers/servicenow/utils.ts stores a value in providerConfig, but because there is no shouldSkipEvent implementation, that value is never checked and the filter silently has no effect.

   3. No payload transformation — formatInput is the mechanism other providers use to map raw webhook body fields to the structured outputs defined in the trigger config (e.g. Jira's extractIssueData in lib/webhooks/providers/jira.ts). Without it, whatever raw JSON the ServiceNow Business Rule sends is passed through as-is; the named output handles (sysId, shortDescription, urgency, etc.) in the workflow editor will only work if the user's script keys happen to match exactly.

   A servicenow handler needs to be added to lib/webhooks/providers/servicenow.ts and registered here, implementing at minimum:

   • matchEvent — read providerConfig.triggerId and compare against the incoming event type to skip non-matching events (similar to the Jira handler).
   • shouldSkipEvent — check providerConfig.tableName against the body's table identifier.
   • formatInput — normalize the raw payload to the structured output fields.

_{Reviews (1): Last reviewed commit: "docs gen" | Re-trigger Greptile}

[greptile-apps]

Example script sends fewer fields than declared outputs

The sample Business Rule script sends only 5 fields:

{ sysId, number, shortDescription, state, priority }

But the trigger outputs (buildIncidentOutputs, buildChangeRequestOutputs, buildServiceNowWebhookOutputs) declare many additional handles users will see in the workflow editor — description, urgency, impact, category, subcategory, caller, assignedTo, assignmentGroup, createdBy, createdOn, updatedBy, updatedOn, resolvedBy, resolvedAt, closeNotes, tableName, eventType, and record.

Users who copy the example script verbatim will find all those extra output handles empty at runtime. Consider expanding the example to send all declared output fields, or adding a note that the example is minimal and users need to extend the script to populate the additional handles.