Inbound Request Configuration table

  • Release version: Yokohama
  • Updated June 16, 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 table

    The Inbound Request Configuration table (sntmtcoreinboundqueueconfig) allows administrators to define how each inbound request flow is processed and tracked in ServiceNow. It requires the Sales and Service Core API (app-tmt-core) plugin.

    Show full answer Show less

    This metadata table enables configuring whether flows run synchronously or asynchronously and adapts the Sales and Order Management Request Tracker across all CRM flows. It also controls notification types for inbound requests, supporting default, custom, or no notifications.

    The existing Inbound Request Table references this configuration table to determine execution mode and tracking for workflows that require completion status monitoring.

    Key Features

    • Run Mode Configuration: Choose synchronous, asynchronous, or advanced custom scripting to determine request processing mode.
    • Notification Settings: Specify how notifications are triggered—none, default (for asynchronous requests), or custom notifications using existing or custom events.
    • Configuration API: Use the Configuration API script field to customize how inbound requests are processed, leveraging the IBQConfigBase API.
    • Active Flag: Enable or disable specific configurations as needed.

    Fields and Practical Use

    Administrators create records specifying:

    • Config ID and Label: Unique identifiers for each configuration.
    • Active: Indicates if the configuration is currently in use.
    • Run Mode: Defines how the request executes (sync, async, or advanced).
    • Trigger Notification: Controls notification behavior for request completion.
    • Configuration API: Script to customize processing logic.

    Security and Access

    Access is managed via security roles:

    • Admin role: Full create, read, update, delete access.
    • Inbound Queue Admin (sntmtcore.inboundqueueadmin): Create, read, and update permissions.

    What This Enables for ServiceNow Customers

    By configuring the Inbound Request Configuration table, customers can precisely control how inbound CRM-related flows are processed and tracked, improving integration efficiency and visibility. Notification control helps tailor communication to business needs, while the option for advanced scripting provides flexibility for complex scenarios.

    Overall, this configuration empowers ServiceNow administrators to manage inbound request flows with greater customization and control, ensuring processes align with organizational requirements and providing better operational oversight.

    The Inbound Request Configuration table enables users 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 (app-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 and Order 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 a user wants 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
    Admin Create, read, update, delete
    Inbound Queue Admin (sn_tmt_core.inbound_queue_admin) Create, read, update