{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":37529,"path":"order-management/inbound-request-configuration-table.md","title":"Inbound Request Configuration","bundle":null,"doc_type":null,"release":"australia","body":"\n# Inbound Request Configuration\n\nEnables you to define the configurations to determine how each flow is processed and tracked within an Inbound Request.\n\n## Overview of the Inbound Request Configuration table\n\nThe 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\\).\n\nThe Inbound Request Configuration table is a metadata table that must be configured to decide how a particular flow is executed, whether synchronous or asynchronous.\n\nThe table can be used to perform the following tasks.\n\n-   Enable admins to configure synchronous vs asynchronous processing of requests.\n-   Adapt the Sales Customer Relationship Management Request Tracker across all CRM flows.\n-   Enable configuration of notification types, whether default, custom, or no notifications.\n\nThe **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\\).\n\nAny 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.\n\n## Fields on the Inbound Request Configuration Table\n\nAn admin creates a record in the table and specifies the configuration using the **run\\_mode**, **trigger\\_notification**, and **configuration\\_api** fields.\n\n<table id=\"table_f3d_3tv_1fc\"><thead><tr><th>\n\nField\n\n</th><th>\n\nDescription\n\n</th><th>\n\nType\n\n</th></tr></thead><tbody><tr><td>\n\nConfig ID\n\n</td><td>\n\nUnique configuration ID for the metadata configuration.\n\n</td><td>\n\nString\n\n</td></tr><tr><td>\n\nLabel\n\n</td><td>\n\nUnique label name for the metadata configuration.\n\n</td><td>\n\nTranslated text\n\n</td></tr><tr><td>\n\nActive\n\n</td><td>\n\nSpecifies whether the Inbound request configuration record is active or not.\n\n</td><td>\n\nTrue/False Default value is **False**\n\n</td></tr><tr><td>\n\nRun Mode\n\n</td><td>\n\nSpecifies whether a request runs synchronously or asynchronously.\n\n</td><td>\n\nString \\(choices\\): **Sync**, **Async**, **Advanced**.-   Synchronous: Synchronous processing.\n-   Asynchronous: Asynchronous processing\n-   Advanced: Use custom script to determine if the flow has to be synchronous or asynchronous\n\n</td></tr><tr><td>\n\nTrigger Notification\n\n</td><td>\n\nSpecifies how you want to receive notifications.A notification is triggered in one of the following situations.\n\n-   **Trigger notification** field is set to **Default**.\n-   State of a request is **Complete** and the status is either **Success** or **Partial success**.\n\nThe notifications for the record in the Inbound table are only received by whoever has initiated the flow.\n\n</td><td>\n\nString \\(choices\\): None, Default, Custom-   None: No notifications\n-   Default: Notifications only for asynchronous requests.\n-   Custom: Custom notification for asynchronous requests based on requirements.\n\nConfigure custom notifications by using the existing event \\(sn\\_tmt\\_core.ibq.custom.notification\\) or by handling your own custom event.\n\nDefault value for the field is **Default**.\n\n\n</td></tr><tr><td>\n\nConfiguration API\n\n</td><td>\n\nScript required to process the inbound request.To learn more about the configuration API, see [IBQConfigBase API - Scoped](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/api-reference/server-api-reference/IBQConfigBaseAPIBoth.md).\n\n</td><td>\n\nReference: sys\\_script\\_include\n\n</td></tr><tr><td>\n\nDomain\n\n</td><td>\n\nThe current domain scope of the record, for example global.\n\n</td><td>\n\nDomain ID\n\n</td></tr></tbody>\n</table>## Security roles\n\nThe 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.\n\n|Role|Access|\n|----|------|\n|sn\\_tmt\\_core.inbound\\_queue\\_admin|Create, read, update, delete, report\\_view, report\\_on|\n\n**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](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/application-development/c_DelegatedDevelopment.md).\n\n**Related topics**  \n\n\n[IBQConfigBase API - Scoped](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/api-reference/server-api-reference/IBQConfigBaseAPIBoth.md)\n\n"}}