{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":4585,"path":"conversational-interfaces/agent-chat/ci-agent-chat-reference.md","title":"Agent Chat reference","bundle":null,"doc_type":null,"release":"australia","body":"\n# Agent Chat reference\n\nReference topics provide descriptions about Agent Chat.\n\n## Domain separation and Agent Chat\n\nDomain separation is supported in the Agent Chat application. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.\n\n### Support level: Standard\n\n-   Includes all aspects of **Basic** level support.\n-   Application properties are domain-aware as needed.\n-   Business logic: The service provider \\(SP\\) creates or modifies processes per customer. The use cases reflect proper use of the application by multiple SP customers in a single instance.\n-   The instance owner must configure the minimum viable product \\(MVP\\) business logic and data parameters per tenant as expected for the specific application.\n\nSample use case: An admin must be able to make comments required when a record closes for one tenant, but not for another.\n\nFor more information on support levels, see [Application support for domain separation](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/domain-separated-apps.md).\n\n### Requirements\n\nAll domain support features require the Domain Support - Domain Extensions Installer \\[com.glide.domain.msp\\_extensions.installer\\] plugin. For details, see [Request domain separation](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-security/t_ActivateDomainSeparation.md).\n\n### Configuring Agent Chat with domain separation\n\nDomain separation allows organizations to segment their data and processes based on specific criteria such as business unit, geography, or other factors.\n\nA service provider \\(SP\\) has one chat setting \\(Agent Chat\\) record in the global domain when the instance is provisioned.\n\nThe admin of a subdomain can specify Agent Chat settings for that subdomain, such as work queues and assignment groups. For details, see [Setting up Agent Chat](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/conversational-interfaces/agent-chat/ac-configure-agent-chat.md).\n\nWhen a user logs into a subdomain, a seeded Agent Chat settings record is created.\n\nWhen using domain separation in Agent Chat, keep the following points in mind:\n\n-   Domain Separation applies to both the agent side and the customer side of the chat. This means that agents will only be able to access chat records and data that are in their domain, and customers will only be able to see chat records that are associated with their domain.\n-   Agent Chat records are automatically tagged with the domain of the agent who handled the chat. This ensures that the chat record is associated with the correct domain, and that agents can only view chat records that are associated with their domain.\n-   When an agent is assigned to a chat, the chat is automatically assigned to the domain of the agent. This ensures that the chat record is associated with the correct domain from the start.\n-   If an agent needs to transfer a chat to another agent or escalate the chat to a higher level of support, the chat is transferred to an agent who is in the same domain as the original agent. This ensures that the chat record stays within the correct domain.\n\n## Building a report to track the number of help requests\n\nCreate a report that tracks the number of help requests.\n\n### Before you begin\n\nRole required: admin\n\n### Procedure\n\n1.  Activate the Interaction Events business rule.\n\n    1.  Navigate to **Interaction** > **All**.\n\n    2.  Right-click the **Number** heading.\n\n    3.  Click **Configure** > **Business Rules**.\n\n    4.  On the Business Rules screen under the **Name** column, click **Interaction Events**.\n\n    5.  On the Business Rules - Interaction Events screen, select the **Active** check box if it is not already selected.\n\n    6.  Click **Update**.\n\n2.  Create a new metric definition for Interaction \"help requested\" on the Metric Definition - New record screen by entering `Interaction` in the **Table** field and selecting **Help Requested** from the **Field** list.\n\n    For detailed steps on creating metric definitions, see [Define a metric](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-administration/create-metric.md).\n\n3.  Create a new chat as a requester.\n\n4.  Accept the same chat as an agent.\n\n5.  While still logged in as that agent, enter the quick action `/help`.\n\n6.  Navigate to **Metrics** > **Instances** and record the ID of the single instance record created for help\\_requested=true.\n\n7.  Navigate to the Admin window and open the interaction from the previous step.\n\n8.  Join the conversation \\(either privately or publicly\\).\n\n9.  Navigate to **Metrics** > **Instances** and observe that one instance record was created for help\\_requested=true.\n\n    For more information about using the Metric Instance Table, see [Metric instance](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-administration/c_MetricInstance.md).\n\n\n## Agent Chat Interaction related records\n\nThe Interaction related record \\[interaction\\_related\\_record\\] table tracks tasks and Knowledge Base \\(KB\\) articles that are created, updated, or viewed in the context of a particular interaction. The Interaction related record table references the interaction, related document, whether the relationship is to a task or KB article, and what type of operation on the related document formed the basis for the relationship.\n\n### Interaction related record table overview\n\nThe Interaction related record table tracks task and KB article records that were created, updated, or viewed in a particular interaction. The Interaction related record table records\n\n-   the interaction\n-   the related document\n-   whether the relationship is to a KB article or a task\n-   what type of operation on the related document formed the basis of the relationship\n\n### Creating Interaction related records\n\nInteraction related records can be created manually or automatically.\n\n-   Manually - records are manually created via an Interaction related record form. The form is opened on a workspace through an Associated record UI action. When this form is used to create the relationship, the operation field is not set to any value.\n-   Automatically created via business rules\n-   Automatically created via client calls from a workspace\n\n### Configuring automatic creation of interaction related records\n\nYou can update or create entries in the Interaction relationship policy \\[interaction\\_relationship\\_policy\\] table to manage which types of operations result in the auto-creation of interaction related records. These determine whether interaction related records may be created for each of the following actions:\n\n-   Insert - record created from workspace in the context of the interaction.\n-   Update - record updated from workspace in the context of the interaction.\n-   Mention - record number mentioned in a chat, resulting in the rendering of a record card.\n-   Open - record opened in workspace in the context of the interaction.\n-   Unknown - interaction related record created by automated logic other than via agent actions from workspace.\n\nTwo policies that are included with the base system govern behavior for relationships to the task and kb\\_knowledge table. To override behavior for a particular task type, you can add an additional entry for the appropriate Document table.\\[Omitted image \"interaction\\_relationship\\_policies.png\"\\] Alt text: Interaction relationship policies screenshot\n\nThe com.glide.interaction.autocreate\\_relationships property is set to true by default. If it is set to false, only relationships created via the interaction\\_related\\_record form are created. All others are blocked by the \"Block relationship autocreation\" business rule.\n\n"}}