チケットトリガは、チケットの作成や更新の直後に実行され、指定された条件を満たした場合に自動的にアクションを実行するビジネスルールです。たとえば、チケットがオープンされたことをカスタマーに通知するためにチケットトリガを使用できます。
トリガは、トリガ起動の要件となる条件と、その条件が満たされた時に実行されるアクションで構成されます。詳しくは「トリガの構造」を参照してください。つまり、条件が真であれば、トリガはアクションを実行します。
独自のトリガを作成できるだけでなく、標準のチケットトリガのセットも用意されています。管理者とビジネスルールを管理する権限のあるカスタムロールのエージェントが、チケットトリガを作成することができます。
チケットトリガに関する重要な情報
- チケットトリガとカテゴリの順番は、トリガが起動される順序を指定します。トリガとカテゴリは、目的のワークフローに合わせて適切な順序で並べることが重要です。
- チケットイベントログには、トリガによってチケットフィールドの値が実際に変更された場合のみ、そのチケットに適用されたアクションが記録されます。トリガが実行され、起動しても、チケットに変更がない場合、イベントログには記録されません。
- アクティブなチケットトリガを最大で7,000個まで保持できます。これには、アクティブな標準のチケットトリガとカスタムのチケットトリガがすべて含まれます。
- 大量のチケットトリガを管理しやすくするために、トリガをカテゴリに整理することができます。
- チケットトリガは、管理センターのトリガページにリストされた順番で実行されます。あるトリガによって適用されたアクションは、他のトリガがチケットによってどのように実行され、起動するかに影響するため、実行順序は重要です。
- チケットトリガへのエージェントのアクセス権は、プランと権限によって異なります。
- Enterpriseプランでは、トリガを管理する権限を持つカスタムロールのエージェントは、トリガのリストを表示し、個々のトリガを表示、追加、編集、および削除できます。この権限を持たないカスタムロールのエージェントは、トリガのリストにアクセスできず、個々のトリガには読み取り専用でアクセスできます。
- Enterprise以外のプランでは、エージェント、ライトエージェント、および閲覧担当はトリガのリストにアクセスできず、個々のトリガには読み取り専用でアクセスできます。
チケットトリガの実行と起動のタイミングについて
チケットが作成または更新されるたびに、そのチケットに対して、すべてのチケットトリガがリストの並び順どおりに一定のサイクルで実行されます。そのサイクル中に条件が満たされたときに、チケットトリガが起動し、チケットを更新します。チケットがすべてのチケットトリガと照合されるプロセス全体を「サイクル」と呼びます。
サイクル中にチケットトリガがチケットを更新すると、そのサイクルは最初からやり直しになります。すでに起動してチケットを更新したチケットトリガを除く、すべてのチケットトリガが再度実行されます。つまり、すべてのトリガが、チケットを更新するか、条件を満たしていないためにスキップされるまでは、チケットに対してチケットトリガのリストが何度も実行されることがあります（下の図を参照）。
チケットトリガは、サイクル中に繰り返し実行（確認）されることがありますが、同じサイクル中に複数回起動（チケット更新）されることはありません。これは、いちど起動したトリガは、同じサイクル中に再度確認されることがないためです。また、条件が満たされない場合、トリガはサイクル中に起動されません。
チケットトリガのサイクルは、トリガが起動するたびにやり直されるので、チケットトリガのアクションが互いに影響し合う可能性があります。あるトリガがチケットを更新したときに、その更新によって前回一致しなかった別のトリガの条件が真となることで、他のトリガが起動することがあります。そのため、トリガの順序は非常に重要です。
特定の条件の重要性
チケットトリガを作成する場合、条件をできるだけ具体的にすることが重要です。「チケット｜= 」条件は、チケットトリガの範囲を狭め、チケットが作成された時か更新された時のいずれか一方でのみ実行され、両方で実行されないようにするための良い方法です。この条件がないと、チケットが作成または更新されるたびにチケットトリガが実行されます。これによって、トリガサイクルの処理時間が不必要に長くなったり、意図しない自動アクションが発生したりする可能性があります。
通常、「チケット｜=｜作成された」条件は、初期条件に基づいて新規作成されたチケットをルーティングするために使用し、「チケット｜=｜更新された」条件は通知を送信するために使用します。「タグ｜含む」条件や「優先度｜≠」条件など、他の無効化条件と組み合わせて使用すれば、「チケット｜＝」条件を使用して、チケットトリガが必要な時だけ実行され、起動するようにできます。
また、他のチケットトリガに含まれるアクションを取り消したり変更したりするチケットトリガに注意することも重要です。そのようなトリガは、競合を発生させ、予測でできない動作を引き起こす可能性があります。たとえば、あるトリガがチケットを受信したチャネルに基づいてチケットを割り当て、別のトリガがタグの有無に基づいてチケットを割り当てたとします。チケットが両方のトリガの基準を満たす場合、サイクルの最後に起動したトリガが、最終的にチケットを割り当てます。ただし、あるチケットトリガのアクションが別のトリガ条件に影響を与えることがあるため、チケットに対してトリガが起動する順序を予測するのは必ずしも容易ではありません。そのため、トリガが競合しないように定義し、タグを追加してからそのタグが存在する場合の条件を作成するなどの無効化アクションや条件を使用して、競合を最小限に抑えることが重要です。
チケットトリガを作成する
チケットトリガは、チケットが作成または更新された直後に実行され、指定された条件が満たされた場合に自動的にアクションを実行するビジネスルールです。チケットトリガには標準で提供されているものがあり、編集することができます。また追加のトリガを作成することもできます。
トリガを作成するには、管理者またはトリガの作成権限を持つカスタムロールのエージェントである必要があります。
次のビデオでは、トリガを追加する方法の概要について説明します。
チケットトリガを使って通知を自動化する（2:02）
- 管理センターで、サイドバーの「
オブジェクトとルール」をクリックし、「ビジネスルール」>「トリガ」を選択します。 - 「トリガ」ページで、「チケット」タブをクリックします。
- 「トリガの作成」をクリックします。
または、オプションメニューアイコン（
）を使って、選択したトリガの下にトリガを作成したり、既存のトリガのコピーを複製して修正することもできます。 - 「名前」にトリガの名前を入力します。
似たようなタイプのトリガを識別しやすくするために、一貫した命名規則を使用します。
- （オプション）「説明」にトリガの説明を入力します。
そのトリガを使って何ができるかを詳しく説明します。説明を手がかりにトリガを検索できるようになります。
- 既存のトリガカテゴリを選択するか、新しいカテゴリを作成します。
- 「条件を追加」をクリックし、「すべて」または「いずれか」の条件を満たすようにトリガを設定します。
条件とは、トリガが起動されるために必須となる要件のことです。
- 追加する各条件について、「カテゴリ」、「フィールド演算子」、および「値」を選択します。
フィールド演算子は、条件とその値との関係を決定します。たとえば、フィールド演算子「Is」を選択した場合、条件と値は等しくなければなりません。異なる条件には、それぞれ異なるフィールド演算子が含まれます。
「トリガの条件文を作成する」を参照してください。
メモ：トリガの文はシンプルに保つことをお勧めします。トリガが複雑になるほど、トラブルシューティングと維持管理が難しくなります。 - 「アクションを追加」をクリックして、トリガの条件が満たされたときに実行するアクションを設定します。
- 追加する各カテゴリについて、「カテゴリ」と「値」を選択します。
「トリガのアクション文を作成する」を参照してください。
- アクション情報を入力します。
入力する情報は、選択したアクションに応じて異なります。たとえば、「タイプ」アクションを選択した場合は、チケットタイプを選択する必要があります。
メール通知アクションを設定する場合は、「メール通知の書式設定」を参照してください。 - 「トリガの作成」をクリックします。
新しいトリガは自動的にアクティブに設定されます。非アクティブなトリガを作成したい場合は、「トリガを作成」の隣にある矢印をクリックし、「非アクティブ」を選択します。
新しく作成したトリガが、トリガのリストの最後に追加されます。
メモ：各ビジネスルールは、65KB未満でなければなりません。
53件のコメント
Gab
I created a ticket on your behalf and will send it to you via email so we can discuss your concern there.
Thank you!
0
Wolf Hilbl
Hi Gab,
this option is not available, neither in triggers nor automation.
We can only add Agent Accounts within the trigger or automation creation menus.
Kind regards
0
Gab
You can definitely add a non-agent as a requester as this will prompt you to add the user's name and email address and will be added as an end-user. In CC, a non-agent can also be added. However, if you are referring to adding a non-agent as a follower, I'm afraid this is not possible as followers can only be internal users (e.g. your agents and other support staff are your internal users, also called team members).
More information can be found here: About CCs and followers
I hope this helps.
0
Wolf Hilbl
Hi, is there a way to add a non Agent as Requester or in CC?
We would like to add additional requesters to Tickets.
Kind regards Wolf
0
Arianne Batiles
Hi PAUL STRAUSS,
I created a ticket on your behalf, and I’ll continue to assist you from there. Kindly check your email for updates. Thank you!
0
Paul Strauss
I'm attempting to create a trigger that will set a custom checkbox field on the requester based on the existence of a ticket tag. However, when I test this with existing tickets, it is not triggering. Any suggestions as to what might be wrong with my logic? See below:
0
Hiedi Kysther
Hi D.Fitz,
This would require deeper investigation. I've created a ticket on your behalf so we investigate this issue together. Kindly check your email for more information. Thanks!
0
D.Fitz
We're going crazy trying to figure this one out.
Aiming to run a trigger when a macro is applied. The macro adds an Internal Comment, two tags and assigns the ticket to a group. This should then send a templated email to the customer (currently cut off, but it's just an 'email user' action).
For some reason, this just doesn't work. All of the criteria are matched and Zendesk 'counts' the trigger as having run, but the email just doesn't send.
What are we doing wrong?
0
Noly Maron Unson
Hi Cory,
This should work as long as the trigger updates the custom field directly, meaning it contains the said action in the trigger itself. Multiple triggers can run on a single event/cycle. If the trigger that updates the custom field value is above in the trigger order than the one that notifies the webhook, then they should be able to run in the same event (creation event).
The only reason why this will not work is if the trigger that changes the field value is not the one directly changing the custom field value but is using a Webhook to update the ticket via API. The changes in the custom field value using this method will not occur in the same event where the trigger fired but will create another event that will fall under the "Ticket is Updated" condition.
This is also not a workflow that we recommend/support since it usually causes race conditions.
0
Cory Waddingham
I want to have a trigger that sends a notification to a webhook on certain conditions, but only when the ticket is created, not updated. But there's another trigger that has to run first that updates some fields on the ticket, and that field is part of the first trigger's conditions. I want to make sure the notification trigger runs only when the ticket is first created.
For more context, we have different tiers of customers, and we want to call PagerDuty when a sev1 ticket is opened by one of those tiers but not others. But the customer tiers are updated by a different trigger, which calls a webhook to a cloud service to get their tier information and updates a custom field with that. The trigger that updates the plan tier information runs before any others, but then the ticket shows as Open, not New. Will any tickets that depend on the ticket being Created, not Updated, still run in this case?
0
サインインしてコメントを残してください。