{"section":"tutorials","requestedLocale":"en","requestedSlug":"using-groups-to-organize-human-attendance","locale":"en","slug":"using-groups-to-organize-human-attendance","path":"docs/en/tutorials/vtex-cx-platform/live-desk/using-groups-to-organize-human-attendance.md","branch":"main","content":"The use of groups to organize contacts that are in human attendance is essential.\n\n> ⚠️ If contacts are not added to a control group, the chatbot will conflict and stop human service by sending the default messages configured in your environment.\n\n## Adding contacts to the control group\n\nIn this article we will refer to the control group as `Human Attendance.`\n\nYou must add the contact to this group in the stream that you open a ticket, as shown earlier.\n\nIt is important to mention that if you open tickets in different streams, **you need to do this in all flows**.\n\n## Ignoring control group participants on triggers\n\n**Ignoring control group participants in triggers** To ensure contacts in human assistance do not receive automatic messages, adding the group is not enough. You must:\n\n1. Add the group to the ignored list **Groups To Exclude** in each trigger configured in your project.\n2. Make this adjustment in **Studio > Triggers**.\n3. Pay special attention to the trigger **\"**An uncaught message starts**\"**.\n\nThis process prevents contacts under assistance from receiving messages from flows while they are in human assistance.\n\nWith this configured, the chatbot will not interrupt human service and the functionality will run as expected.\n\n## Removing contacts from the control group\n\nIt is important to remember to remove contact from this group when the human service session is complete. For this, there is a specific `trigger` type: 'start a flow when a ticket is closed':\n\nThis can be an extremely simple flow, where the only action is to remove the contact from the `Human attendance` control group:\n\n## How do I send custom fields?\n\nThe custom fields to be sent must be defined in the Ticket card body, in JSON format, with each field as an attribute of **custom_fields**, represented by its key and value.\n\n> The value of each field may or may not be enclosed in **\"\"\"\"**.\n\nBelow, observe an example showing the configuration of custom fields, where the **origin** field has its value defined as the result origin, enclosed in **\"\"\"\"** as it is a string type."}