トリガ(または他のビジネスルール)の作成で、最も重視すべきことの1つに、可能な限り具体的な条件を作成することが挙げられます。トリガは、関係のあるチケットにのみ適用されるべきものです。これを実現するための手段として、「チケットが...」条件を使ってトリガの適用範囲を設定する方法がありますが、この条件を設定し忘れるのもありがちな失敗です。この条件は、2つの値をとります。「作成された」と「更新された」です。
この条件の使い方により、トリガが実行されるたびに、処理されるチケット件数に大幅な違いが生じます。
たとえば、Zendeskでチケットを受け取ったときに、いくつかの基準に基づいてチケットを転送するトリガを作成していて、「チケットが... 作成された」条件をトリガに含めたいとします。そのようにすることで、このトリガが、チケットが最初に作成されたときのみに適用され、同じチケットが後で更新されたときには適用されないようにできます。当然ですが、チケットが作成されるのは1回のみです。
以下に、「チケットが... 作成された」条件を使用して、新しく作成されたチケットで特定のタグが含まれているものを「レベル2サポート」グループに割り当てるトリガの例を示します。
このトリガは、新しく作成されたすべてのチケットのうち、この2つのタグのいずれかを含むチケットに対して実行されます。
「チケットが... 作成された」条件を設定しなかったとしたら、どうなるでしょうか。これらのタグのいずれかを含むチケットが作成または更新されるたびに、「レベル2サポート」グループに割り当てられることになります(チケットが更新または作成されるたびにトリガが実行され、グループの割り当てが繰り返し行われるのを防ぐ条件が指定されていないため)。もちろん、最初はその処理でよかったのですが、後からチケットを別のグループに割り当て直した場合はどうなるでしょうか。チケットが更新されるたびに、「レベル2サポート」グループに再割り当てされてしまうかもしれません。
チケットが更新されるたびに、いくつかの基準に基づいてチケットにアクションを割り当てたい場合は、「チケットが...更新された」条件を使用します。
この条件を使用する状況として、もっともよくある例は、リクエスタに通知を送りたい場合です。例として、Zendeskアカウント内のデフォルトのトリガ通知を見てみましょう。たとえば、「リクエスタへの通知 - コメント更新」トリガがあります。新しいパブリックコメントが追加されるたびに、これらのアクションを実行したいとします。
「チケットが...更新された」条件を含むトリガのデフォルトの動作では、トリガの条件が「真」であり続ける限り、チケットが更新されるたびにそのトリガのアクションが繰り返されます。
つまり、「チケットが...更新された」条件を使用して、そのトリガのアクションを「1回限り」でチケットに適用することもできるのです。たとえば、銀行のお客様のチケットの優先度を高くしたいとします。このアクションは1回しか必要ありません。これを実現するには、「チケットが...更新された」条件に加えて、チケットの優先度がすでに「高」に設定されているかどうかをチェックする条件を追加します。つまり、条件に定義されている基準をチケットが満たしていない場合、トリガはそのチケットには適用されません。
このトリガでは、銀行のお客様のチケット(銀行のお客様かどうかは、追加しておいたタグによって判別)が初めて更新されたときに、そのチケットの優先度を「高」に設定します。ただしその前に、チケットの優先度がすでに「高」に設定されているかどうかを調べます。「高」になっている場合、チケットに対してトリガがすでに実行されたことを示しています。その場合は、チケットは更新されません。