プレースホルダは、メール通知の件名や本文に含められる、チケット、ユーザー、およびカスタムデータへの参照です。プレースホルダを使わなければ、自動メッセージを作成することは不可能です。プレースホルダを指定する際には、大文字と小文字が区別されるので注意が必要です。プレースホルダの一覧については、「ビジネスルールのプレースホルダのリファレンス」を参照してください。
Supportには、特定の状況でチケットトリガ内のプレースホルダを非表示にするシステムチケットルールが組み込まれています。システムチケットルールは、変更、修正、または上書きすることができないプリセットのルールで、Suiteの標準的な動作を決定します。これらのルールによって、チケットトリガのプレースホルダが機能しなかったように見えることがありますが、これは誤動作ではありません。これらのルールは、スパム送信者がアカウントを使用してスパムメッセージを配信することを防止するため、ユーザーを保護しています。詳しくは「プレースホルダの非表示ルールについて」を参照してください。
関連記事
ビジネスルール内でプレースホルダを使用する
プレースホルダは、ビジネスルールの一部のアクションで使用できますが、すべてのアクションで使用できるわけではありません。プレースホルダを使用できる場合、フィールドの下に「使用可能なプレースホルダを表示」ボタンが表示されます。プレースホルダは二重の中括弧で囲まれます。主に通知メッセージで使用され、チケットのプロパティを参照します。プレースホルダが値を持たないフィールドを参照している場合、自動化、トリガ、またはマクロではそのプレースホルダは空白になります。
メール通知におけるプレースホルダの使用例を以下に示します。
プレースホルダの一覧と、プレースホルダを利用できるケースについては、「Zendesk Supportプレースホルダリファレンス」を参照してください。プレースホルダのデータの選択や表示を詳細にコントロールしたい場合は、「リキッドマークアップとZendesk Supportについて」を参照してください。
マクロ内でプレースホルダを使用する
プレースホルダを含むマクロをチケットに適用した場合、プレースホルダはチケットについて現在真である要素に応じて評価されます。評価の出力が情報を返した場合、その情報はチケットのコメントとして追加されます。たとえば、チケットIDを返すマクロを、まだ保存していない（それゆえチケットIDを持たない）チケット上で実行すると、チケットのコメントは更新されません。また、チケットを保存しても、マクロは再度評価されません。{{ticket.id}}のプレースホルダを手作業でチケットに追加します。これにより、チケットを提出したときにチケットが評価され、プレースホルダが返す値がチケットのコメントに追加されます。
問題チケットと事象チケットでマクロを使用する場合、関連する事象チケット内で適切な値が設定されるように、スラッシュ（\）を使用してプレースホルダをエスケープする必要があります。例：Hello
\{{ticket.requester.first_name}}
カスタムフィールドのプレースホルダを使用する
プレースホルダは、チケット、現在のユーザー、およびカスタムオブジェクトのプロパティに基づいて自動生成されます。これらを「システムプレースホルダ」と呼びます。
チケット、ユーザー、組織、およびカスタムオブジェクトのカスタムフィールドを追加した場合、追加したフィールドをプレースホルダとして使用することもできます。カスタムフィールドのプレースホルダの使い方は、他のあらゆるシステムプレースホルダと同じです。すべてのカスタムフィールドには一意のIDまたはキーがあります。通常はカスタムチケットフィールドを作成すると、このIDが自動的に生成されます。カスタムユーザー、カスタム組織、またはカスタムオブジェクトのフィールドを作成する場合は、IDは作成者が入力します。いったん設定したIDは変更できません。
カスタムフィールドは利用可能なプレースホルダのリストには含まれませんが、ドロップダウンを除くすべてのカスタムフィールドは、一意のIDまたはキーを参照する次のようなシンプルな命名パターンに従って名前が付けられます。
| チケットのカスタムフィールド | {{ticket.ticket_field_<フィールドID番号>}} |
| ユーザーのカスタムフィールド | {{ticket.requester.custom_fields.<フィールドキー>}} |
| 組織のカスタムフィールド | {{ticket.organization.custom_fields.<フィールドキー>}} |
| カスタムオブジェクトフィールド | {{custom_object.<オブジェクトキー>.custom_fields.<フィールドキー>}} |
たとえば、次のようなカスタムチケットフィールドのプレースホルダは、以下のようになります。
{{ticket.ticket_field_505156}}
カスタムドロップダウンフィールドのプレースホルダを使用する
カスタムドロップダウンリスト内のオプションのプレースホルダ名は、別のパターンに従います。これは選択されたオプションへの参照であり、1つのプレースホルダで4つのドロップダウンリストのオプションすべてを表しています。個々のオプションにはIDがないため、このIDはカスタムドロップダウンリスト全体を表します。繰り返しになりますが、これは選択された1つのオプションへの参照です。
| チケットのカスタムドロップダウンフィールド チケットのカスタムマルチセレクトフィールド |
|
| ユーザーのカスタムドロップダウンフィールド | {{ticket.requester.custom_fields.<フィールドキー>.title}} |
| 組織のカスタムドロップダウンフィールド | {{ticket.organization.custom_fields.<フィールドキー>.title}} |
| カスタムオブジェクトのドロップダウンフィールド | {{custom_object.<オブジェクトキー>.custom_fields.<フィールドキー>.title}} |
たとえば、カスタムチケットフィールドのドロップダウンリストのプレースホルダは以下のようになります。
{{ticket.ticket_field_option_title_515416}}
カスタムフィールドのIDまたはキーを確認するには、「カスタムフィールドのフィールドキーまたはフィールドIDを見つける方法」を参照してください。
カスタムルックアップリレーションシップフィールドにプレースホルダを使用する
ルックアップリレーションシップフィールドは、オブジェクト間のリレーションシップを定義するために使用されるカスタムフィールドの一種です。このフィールドは、Zendeskの標準オブジェクト（チケット、ユーザー、組織）とカスタムオブジェクトでサポートされています。
プレースホルダを使用して、チケットリクエスタの名前などのプライマリオブジェクトに関連するデータを表示するだけでなく、関連レコードのデータを表示することもできます。たとえば、ユーザーを指すルックアップリレーションシップフィールドを持つチケットがある場合、プレースホルダを使用してそのユーザーに関するデータを参照できます。同様に、プレースホルダを使用して、カスタムオブジェクトのルックアップリレーションシップフィールドを介してチケットデータを参照したり、その逆も可能です。これらのプレースホルダのために、標準のチケットリクエスタフィールドと組織フィールドは、ルックアップリレーションシップフィールドとして扱われます。
関連レコードのデータを参照するには、ルックアップリレーションシップフィールドのフィールドキーを使用します。これはカスタムフィールドのパターンに従います。例を参照してください。
ルックアップリレーションシップフィールドのターゲットオブジェクトでサポートされているプレースホルダを使用することもできます。たとえば、ユーザーを参照するルックアップリレーションシップフィールドでは、ユーザーデータのプレースホルダを利用できます。
チケットルックアップリレーションフィールドを介してデータを参照するプレースホルダは、チケットトリガとマクロで使用できます。カスタムオブジェクトルックアップリレーションフィールドを介してデータを参照するプレースホルダは、オブジェクトトリガで使用できます。
プレースホルダを使用して関連レコードからデータを取得する例
チケットの「リクエスタ」フィールドを使用する
たとえば、チケットの「リクエスタ」フィールドは、機能的にはユーザーを参照するルックアップリレーションシップフィールドです。別のユーザーを参照するmanagerをフィールドキーとするユーザールックアップリレーションフィールドを定義した場合、次のプレースホルダを使用してアセットリクエスタのマネージャー名を表示できます。
ticket.requester.custom_fields.manager
また、チケットリクエスタフィールドを使用しているため、もう一歩踏み込んで、以下のプレースホルダを使用して、チケットリクエスタのマネージャーにサイドカンバセーションのメールを作成することもできます。
ticket.requester.custom_fields.manager.email
これは、マネージャーに通知したり、マネージャーの承認を得たりする必要がある承認ワークフローに最適です。
カスタム組織のルックアップリレーションシップフィールドを使用する
「組織」フィールドは、組織を参照するルックアップリレーションフィールドとして機能するもう1つの標準チケットフィールドです。組織ルックアップリレーションシップフィールドを使用して、組織をcontractというカスタムオブジェクトに関連付けることができます。次に、チケットの組織フィールドを利用して、それ自身（組織）自体がチケットに関連付けられている組織に関連付けられた契約レコードからデータを取得し、次のプレースホルダを使用して契約の終了日を通知することができます。
{{ticket.organization.custom_fields.contract.custom_fields.end_date}}
リクエスタチケットフィールドと組織チケットフィールドは、どちらもルックアップリレーションフィールドとして機能する標準チケットフィールドであるため、特殊なケースです。したがって、リレーションシップフィールドのプレースホルダを使って、プライマリオブジェクトに関連する最初のレコードを取得し、そのレコードに関連付けられた次のレベルのレコードからもデータを引き出すことができます。上記の例では、チケットがプライマリオブジェクト、チケットの組織が関連する最初のレコード、組織に関連する契約レコードが次のレベルのレコードとなります。
カスタムのルックアップリレーションシップフィールドを処理する場合、プライマリオブジェクトに直接関連するレコードである、最初のレコードのみからデータを引き出すことができます。
カスタムルックアップリレーションシップフィールドを使用する
カスタムルックアップリレーションシップフィールドを使用する例として、Orderというカスタムオブジェクトを指す2698798899085というフィールドキーを持つチケットルックアップリレーションシップフィールドを考えてみましょう。Orderオブジェクトには、フィールドキーorder_statusを持つカスタムドロップダウンフィールドがあります。チケットに関連付けられているOrderレコードのステータスを参照するには、以下のプレースホルダを使用します。
{{ticket.ticket_field_2698798899085.custom_fields.order_status.title}}
ドロップダウンフィールドを使用する場合、選択された値を返すプレースホルダに.titleを含める必要があります。
カスタムチェックボックスフィールドのプレースホルダを使用する
プレースホルダをリキッドマークアップと組み合わせると、チケットのチェックボックス（カスタムフィールド）が選択されているかどうかを確認でき、チェックボックスの状態（選択または未選択）に応じてカスタムの出力を行うことが可能です。
チェックボックスのカスタムチケットフィールドでリキッドマークアップ、「if/else/case」文を使用する場合、チェックボックスフィールドの値は、「0」または「1」とし、「false」や「true」は使用しないようにします。以下はその例です。
{% if ticket.ticket_field_<insert field_id here> contains 1 %}
checkbox is checked
{% else %}
checkbox is unchecked (or null)
{% endif %}