Say who is handling a thread
assign_conversationPuts a colleague's name on a thread of a helpdesk queue: what says, to everyone working that queue, that this one is being dealt with and by whom. It hands over the WORK and not the access, so the thread stays readable by the whole team and nobody loses sight of it. Somebody who does not work that queue is refused rather than named on a thread they cannot open, and so is a deactivated account: put them on the queue first with add_queue_operator. Threads of a mailbox are refused too, a box being held rather than assigned. Name "team" instead of "person" to hand it to a team (list_teams names them): every member who works the queue sees it as theirs to take until one of them does, and a team none of whose members works the queue is refused. unassign_conversation gives the thread back to the queue. To hand several threads to the same colleague or team, give conversation_id the list of their ids, in ONE call rather than one call per thread: the answer then lists in "results" the outcome of each thread in the order given ("ok", with its "result" or its "error") and counts "succeeded" and "failed". Each thread passes exactly the checks it would alone, so one refused or out of reach ("not found") leaves the others done, and the call is an error only when none succeeded.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | The slug of a team of the account, as list_teams gives it, in place of "person". | |
| person | No | The email address the person signs in with, which is not the same thing as the mailbox: it is how the account knows them. | |
| conversation_id | Yes | The id of the conversation, as list_conversations gives it, or a list of up to 50 ids to do the same to every one of them in a single call. |