L’API d’e-mail vous permet de définir les propriétés des tickets en ajoutant des commandes au corps de votre e-mail de réponse à une notification ou d’un e-mail de création d’un nouveau ticket. Seuls les agents peuvent utiliser l’API d’e-mail. Si ces commandes sont utilisées par un utilisateur final, Zendesk les ignore.
Voici un exemple d’un agent définissant le statut et l’assigné d’un ticket dans la réponse à une notification par e-mail :
Un agent peut également utiliser les commandes dans un nouvel e-mail envoyé à son adresse d’assistance. Ce type d’e-mail crée un nouveau ticket.
Syntaxe
L’API d’e-mail analyse le haut de votre e-mail pour trouver la liste des commandes que vous voulez exécuter.
Les commandes doivent être en texte brut, pas HTML, et suivre le format suivant :
#command value
Si, par exemple, vous voulez définir le statut d’un ticket, utilisez cette commande :
#status solved
Chaque commande doit être sur une ligne indépendante. Si, par exemple, vous voulez définir le statut et l’assigné, rédigez les commandes comme suit :
#status solved
#assignee jake@zendesk.com
Saisissez le corps de votre e-mail après le bloc de commandes.
Commandes - Référence
Vous trouverez ci-après la liste de toutes les commandes prises en charge que vous pouvez ajouter, une ligne à la fois, au corps d’un e-mail valide. Cette liste inclut également les commandes abrégées, des commandes d’un seul mot pour les commandes courantes ne nécessitant pas de valeur. Par exemple, vous pouvez utiliser la commande abrégée #solved
au lieu de #status
solved
.
Commande | Description |
---|---|
#status
|
Les valeurs valides sont open (ouvert), pending (en attente) et solved (résolu). Remarque - #assignee doit être défini pour définir un ticket sur le statut Résolu. Syntaxe abrégée : #solved fonctionne uniquement pour les tickets qui ne contiennent pas de champs obligatoires que l’agent doit remplir avant que le ticket puisse être résolu. |
#requester
|
Définit le demandeur du ticket. Il peut s’agir de l’ID utilisateur dans votre compte ou simplement de son adresse e-mail. S’il n’existe pas dans votre compte, Zendesk le créera pour vous. Cette commande n’est pas disponible pour les agents light. |
#group
|
Affecte le ticket à un groupe. Les valeurs valides sont le nom ou l’ID du groupe.
Cette commande est particulièrement utile pour transférer les e-mails. Quand un agent transfère un e-mail à Zendesk, par défaut le ticket qui en résulte est soit non affecté ou affecté au groupe par défaut de l’agent. (consultez Transfert direct d’un e-mail à votre adresse d’assistance). Les agents peuvent utiliser cette commande pour affecter automatiquement le ticket transféré au groupe spécifié. |
#assignee |
Affecte le ticket à un agent. Les valeurs valides sont l’adresse e-mail ou l’ID Zendesk Support de l’assigné (obtenu, par exemple, par le biais d’une intégration REST). En utilisant cette commande, vous devenez automatiquement un collaborateur (CC) pour le ticket. |
#priority
|
Définit la priorité du ticket. Les valeurs valides sont low (basse), normal (normale), high (élevée) et urgent (urgente). Remarque – Pour définir une priorité, vous devez aussi définir un type de ticket (voir ci-dessous). Syntaxe abrégée : |
#type |
Les valeurs valides sont incident, question, task (tâche) et problem (problème). Syntaxe abrégée : |
|
Définit n’importe quelle balise pour le ticket. Elles peuvent être séparées par des espaces ou des virgules. Remarque – La définition des balises supprime toutes les balises précédemment définies pour ce ticket. |
#public
|
Définit la mise à jour d’un commentaire pour un ticket sur publique. Ne peut être utilisée que lors de la mise à jour d’un ticket. La valeur par défaut pour les tickets publics est true, ce qui signifie que le demandeur verra tout ce que vous incluez d’autre au corps de l’e-mail. La valeur par défaut pour les tickets privés, comme les tickets créés par les agents light, est false. Syntaxe abrégée : |
Commandes non valides
Si vous saisissez des commandes ou valeurs non valides, Zendesk les ignore.
Exemple
Dans cet exemple, l’agent utilise toutes les commandes.
L’e-mail effectue les actions suivantes sur le ticket 178 :
- Définit le statut sur ouvert
- Définit le groupe sur Assistance et l’assigné sur l’agent ayant jake@zendesk.com comme adresse e-mail
- Définit la priorité sur normale
- Définit le type sur question
- Définit les balises sur aide et api
- Définit la visibilité du commentaire sur privée
- Ajoute un nouveau commentaire disant « Salut la compagnie ! » au ticket, qui associé à la commande ci-dessus ne sera pas visible par le demandeur.
27 commentaire
Julian
On Dec 22, 2021, Jeff C said:
Yet, the article says
What would be, now, a turnaround to this scenario:
Goal:
When a partner company forwards a user request to my Zendesk, the forwarded email often includes internal information meant only for my agents and not for the requester.
Need:
I want the first message in the conversation (the forwarded email) to be created automatically as an internal note, so it is not visible to the end user.
Thank you for your ideas.
0
Axel de Jong
This is something we too would really appreciate: some kind of trigger to allow to set the organization on email tickets for users with multiple organisations.
1263792605130 did you ever find a way to achieve this?
0
Justin Near
We have several clients with multiple organizations. I'm not seeing “Organization” in the placeholder list, but I'm also not seeing a way to change organization on a ticket with a trigger. Is there a way to change the organization using a placeholder and/or some other method while forwarding an email?
0
Dainne Kiara Lucena-Laxamana
Hi 5094134994970
That's rather odd. I went ahead & created a ticket to look into that Email trail using the latest comment placeholder. Please keep an eye out for our Email
0
Kiran Yadav
Hi Team, if we are replying to the requester about the ticket and the requester is replying back through their email, is it possible that the requester see only the latest comment and not the other trail mail comments. I have tried using the latest comment placeholder in the trigger but still if the agent replies back the comments are visible in the trail mail
0
Sriram Parthasarathy
Support team, are you planning on getting html-formatted tags to work? We are not able to ask our agents (who all use Outlook) to make sure they switch to plain text email every single time they want to reply to a ticket and use mail api for changing the assignee, status, or adding a note.
0
Patrick Lanwehr
Hi Mike,
just check my comment from the 29.06.2023
I have already added the link.
0
Mike DR
0
Joyce
#brand
is not a supported command for Mail API. All the supported Mail API commands are listed in the Command reference topic of this article.As a workaround, you can use the
#tags
command to add a ticket tag and use this tag as a condition in a trigger to set the ticket brand.Hope this helps.
1
Patrick Lanwehr
Hallo Jennifer,
ich möchte gerne eine E-Mail, die bisher ohne Ticketbezug ist, als internen Kommentar einem bestehenden Tickets hinzufügen.
Im Jahr 2015 gab es dazu mal einen Community-Post mit sehr viel Feedback. Ist das nun die Lösung ?
https://support.zendesk.com/hc/de/community/posts/4409217600666-Ability-to-forward-emails-into-an-existing-ticket
0
Vous connecter pour laisser un commentaire.