Inbound Request Configuration

  • Release version: Australia
  • Updated August 11, 2026
  • 2 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Inbound Request Configuration

    The Inbound Request Configuration feature, available with the Sales and Service Core API (com.sntmtcore) plugin, allows ServiceNow administrators to define how flows within an Inbound Request are processed and tracked. This configuration is managed via theInbound Request Configuration table (sntmtcoreinboundqueueconfig), which controls whether flows run synchronously or asynchronously and manages notification preferences.

    Show full answer Show less

    This setup is essential for workflows that require completion status tracking, enabling tailored execution modes and notification handling across all CRM flows.

    Key Features

    • Run Mode Configuration: Admins specify whether requests are processed synchronously, asynchronously, or via a custom script (Advanced mode) to dynamically determine processing mode.
    • Notification Control: Options to configure notification behavior include no notifications, default notifications for asynchronous requests, or custom notifications triggered by events or custom scripts.
    • Metadata Management: The configuration records include unique IDs, labels, active status, and domain scope to organize and control request processing settings.
    • API Integration: The Configuration API (IBQConfigBase API - Scoped) supports custom processing logic for inbound requests.

    Configuration Details

    Each configuration record includes key fields such as:

    • Config ID and Label: Unique identifiers for easy reference.
    • Active: Enables or disables the configuration.
    • Run Mode: Defines processing mode with choices Sync, Async, or Advanced.
    • Trigger Notification: Controls notification behavior with options None, Default, or Custom.
    • Configuration API: Specifies any custom script logic needed to process the request.

    Access and Security

    Access to the Inbound Request Configuration table is controlled by roles, primarily the sntmtcore.inboundqueueadmin role, which grants full CRUD and reporting permissions. Administrators configuring these settings should have either the sntmtcore.admin or sntmtcore.inboundqueueadmin role and be assigned as delegated developers for the respective application, with "Manage Update Set" permission to ensure proper change tracking and deployment.

    Practical Benefits for ServiceNow Customers

    • Enables precise control over how inbound requests are processed, improving flow efficiency and resource utilization.
    • Customizable notification settings ensure relevant stakeholders receive appropriate updates without unnecessary noise.
    • Supports advanced scenarios via custom scripting, allowing flexible and dynamic processing tailored to specific business needs.
    • Ensures secure and controlled configuration management aligned with best practices for delegated development and update set management.

    Enables you to define the configurations to determine how each flow is processed and tracked within an Inbound Request.

    Overview of the Inbound Request Configuration table

    The Sales and Service Core API (com.sn_tmt_core) plugin is required to use the Inbound Request Configuration table (sn_tmt_core_inbound_queue_config).

    The Inbound Request Configuration table is a metadata table that must be configured to decide how a particular flow is executed, whether synchronous or asynchronous.

    The table can be used to perform the following tasks.
    • Enable admins to configure synchronous vs asynchronous processing of requests.
    • Adapt the Sales Customer Relationship Management Request Tracker across all CRM flows.
    • Enable configuration of notification types, whether default, custom, or no notifications.

    The Request Configuration field on the existing Inbound Request Table [sn_tmt_core_inbound_queue] is a reference to the new Inbound Request Configuration table (sn_tmt_core_inbound_queue_config).

    Any workflow that requires the tracking of a completion status, can use the Inbound Request Configuration table and configure whether a flow is synchronous or asynchronous.

    Fields on the Inbound Request Configuration Table

    An admin creates a record in the table and specifies the configuration using the run_mode, trigger_notification, and configuration_api fields.
    Table 1. Field and descriptionsList of fields on the inbound request configuration table, their descriptions, and the type of fields.
    Field Description Type
    Config ID Unique configuration ID for the metadata configuration. String
    Label Unique label name for the metadata configuration. Translated text
    Active Specifies whether the Inbound request configuration record is active or not. True/False

    Default value is False

    Run Mode Specifies whether a request runs synchronously or asynchronously. String (choices): Sync, Async, Advanced.
    • Synchronous: Synchronous processing.
    • Asynchronous: Asynchronous processing
    • Advanced: Use custom script to determine if the flow has to be synchronous or asynchronous
    Trigger Notification Specifies how you want to receive notifications.
    A notification is triggered in one of the following situations.
    • Trigger notification field is set to Default.
    • State of a request is Complete and the status is either Success or Partial success.

    The notifications for the record in the Inbound table are only received by whoever has initiated the flow.

    String (choices): None, Default, Custom
    • None: No notifications
    • Default: Notifications only for asynchronous requests.
    • Custom: Custom notification for asynchronous requests based on requirements.

      Configure custom notifications by using the existing event (sn_tmt_core.ibq.custom.notification) or by handling your own custom event.

      Default value for the field is Default.

    Configuration API Script required to process the inbound request.

    To learn more about the configuration API, see IBQConfigBase API - Scoped.

    Reference: sys_script_include
    Domain The current domain scope of the record, for example global. Domain ID

    Security roles

    The security roles for the Inbound Request Configuration table (sn_tmt_core_inbound_queue_config) provide different levels of access to the [sn_tmt_core.inbound_queue_admin] role.
    Table 2. Roles and access
    Role Access
    sn_tmt_core.inbound_queue_admin Create, read, update, delete, report_view, report_on
    Note:
    Add a user with the roles sn_tmt_core.admin or sn_tmt_core.inbound_queue_admin, who is responsible for configuring the Inbound Request Configuration table, as a delegated developer for the application where the configuration is being created. Assign the permission “Manage Update Set” (added under Manage Developers for the respective application). This ensures that all changes are captured in the correct scope and update sets. For details, see Delegated development and deployment.