ワークフローの実行履歴と改訂履歴
このページの内容
ワークフローの実行と改訂履歴について
ワークフローを設定したら、そのステータスをチェックし、変更点を評価したいと思うだろう。ワークフローの実行履歴および改訂履歴セクションでは、ワークフローの過去の実行履歴、実行履歴の詳細、およびワークフローに加えられた変更を確認することができます。このセクションは、ワークフローが失敗した理由を評価する際に特に役立ちます。レポートには、ワークフローが失敗した理由や変更が行われた場合の情報が含まれ、問題の特定と修正に役立ちます。
特定のワークフローの実行履歴や改訂履歴は、ワークフローをクリックし、目的のセクションに移動することで見ることができます。
また、プロジェクトのワークフロータブから直接実行履歴にアクセスすることで、プロジェクト内の全ワークフローの実行履歴を確認することができます。
警告: ワークフローの実行および改訂履歴データは、ワークフローがトリガーされてから 30 日間のみ保持されます。この期間を過ぎると、そのワークフローに関するレポートは削除されます。
実行履歴
実行履歴ページでは、トリガーしたワークフロー実行の追加情報を見ることができます。このページは、ワークフローの監視、問題の診断、正常に完了したワークフローと失敗したワークフローの概要の把握に役立ちます。
ワークフローの実行履歴を表示する際、ページ上部のドロップダウンメニューを使用することで、2つの異なるレポートビューを切り替えることができます：
ワークフローがトリガーされるたびに、ワークフロー実行履歴ページに新しいエ ントリとして追加されます。このページには、ワークフローの実行に関する以下の情報を表示する表があります：
- 開始日：ワークフローの実行を開始した日時。
- ワークフロー名: ワークフローの名前です。 Qtip：「削除されたワークフロー」というワークフローのステータスが表示されている場合、添付されたワークフローを削除している可能性があります。記録は残っているが、ワークフロー自体は復元不可能である。
Qtip:特定のワークフローの実行履歴にアクセスする場合、この列は除外されます。 - 所有者：ワークフローを作成したユーザーのユーザー名。
- ステータス：ワークフローのステータス。
各ワークフローの実行に関する詳細情報を表示することができます。ワークフローをクリックするとワークフローが展開され、ワークフローの各コンポーネントの情報が表示されます。
ワークフローを開始するイベントは “トリガー “とラベル付けされ、ワークフロー内の異なるタスクは、最初のタスクは “T-ID 1″、2番目のタスクは “T-ID 2 “とラベル付けされる。タスクの順序とラベルの詳細については、ワークフロー内のタスクの順序を参照してください。
ワークフローの各コンポーネントをクリックして、詳細を見ることができます。利用可能な情報やアクションは、ワークフローコンポーネントのタイプや、 ワークフローが成功したか否かによって異なります。詳細は以下のセクションを参照：
- 正常にトリガーされたワークフロー実行の表示：正常にトリガーされたワークフロー。タスクは成功することも失敗することもある。
- 失敗したワークフロー実行の表示：イベントトリガーの問題や誤ったワークフロー条件により、正常にトリガーされなかったワークフロー。トリガーされなかったため、タスクが実行されなかった。
実行履歴の検索
実行履歴にはあらかじめフィルターが設定されており、興味のあるワークフローを簡単に見つけることができます。検索バーを使ってタスク出力値を検索することもできる。
Qtip:フィルターの選択を元に戻すには「すべて」を選択してください。
Qtip:このフィルターは、アンケートプロジェクトで実行履歴を見る場合は除外されます。
Qtip:特定のワークフローの実行履歴を表示する場合、このフィルターは除外されます。
Qtip:このフィルターは含まれるタスクドロップダウンから特定のタスクを選択した時のみ利用可能です。
注意: このフィルターは現在すべてのタスクタイプで利用できるわけではありません。
Qtip:IDで検索すると、最新の10,000件の結果のみが返されます。ワークフローの実行が表示されない場合は、代わりに開始日と終了日のフィルタを使用してみてください。
Qtip:ページ下部のRecords per pageオプションで結果数を調整できます。
成功したトリガーによるワークフロー実行の表示
正常に開始されたタスクの実行ページには、正常にトリガーされたワークフローが表示されます。これらのワークフローには、成功したタスクも失敗したタスクもある。これらのワークフローを表示する際、タスクのいずれかをクリックすると、タスクの詳細情報を含む並列パネルを開くことができる：
- ステータス：タスクのステータス。
- ワークフロー実行 ID：ワークフローが実行されるたびに、ワークフローの各アスペクトには一意の実行 ID が割り当てられます。このIDを使用してワークフローをフィルタリングしたり、ワークフローが失敗した理由のトラブルシューティングが必要な場合にクアルトリクスサポートに提供することができます。
- スケジュール対象：ワークフローの実行予定日時。これはスケジュールされたワークフローにのみ表示されます。
- 開始時間：ワークフローの実行開始日時。
- 終了時間：ワークフローの実行終了日時。
- 期間：ワークフローの総実行時間。
- 設定：設定： ワークフロー実行時の再実行と失敗の設定。
- ファイル：タスクが何らかのファイルを処理した場合、このセクションでファイルをダウンロードできる。詳しくはデータファイルのダウンロードをご覧ください。 Qtip:選択したタスクがファイルを処理しない場合、このフィールドは非表示になります。
上記の情報に加え、ワークフロー実行時に個々のタスクがどのように設定されたかを見ることができます：
- タスクエディターでタスクを見るには、タスクを見るをクリックする。このウィンドウには、ワークフロー実行時にタスクが持っていたコンフィギュレーションが含まれます。ここで行った編集は保存されません。
QTip:メールタスク、XM DIRECTORYタスク、チケットタスク、Salesforceタスク、古い設定のTANGO Cardタスクでは、このビューは利用できません。 - タスクの JSON ペイロードを表示するには、[JSON を表示]をクリックします。JSONペイロードは、ワークフロー、特にETLワークフローのトラブルシューティングに役立ちます。入力タブにはタスクが受け取った情報とデータが表示され、出力タブにはタスクの結果が表示される。
視聴条件
ワークフローの条件がどのように評価されたかを確認することもできます。これには、ワークフ ロートリガー後の条件や、個々のタスク間の条件が含まれます。条件をクリックすると、その条件の詳細が表示されます。
各条件がこのウィンドウに表示される。その条件が何であったか、その条件を評価するために使われた値、その条件がどのように評価されたかを見ることができる。
条件は以下のいずれかとして評価される：
- 真と評価された：条件が満たされ、真と評価された。
- 偽と評価された：条件が満たされず、偽と評価された。
- 評価されなかった：any “ロジックで区切られた条件の場合）ロジックがワークフロー内の別の条件によって既に渡されたため、条件は評価されませんでした。
Qtip:このウィンドウには、ワークフローの実行IDも表示されます。これは、サ ポートとワークフローのトラブルシューティングを行う際や、後でワークフ ローを検索する際に役立ちます。
失敗したワークフローの表示
Failed to start after triggered］ページには、トリガーに失敗したワークフローが表示されます。イベントトリガーは成功したが、条件が満たされずワークフローが失敗したワークフローも含まれます。
Qtip:失敗したワークフロー タスクのトラブルシューティングについては、「正常にトリガーされたワークフロー実行の表示」を参照してください。
失敗したトリガー条件
ワークフローの条件ロジックがどのように評価されたかを見ることができます。実行履歴ページには、真の条件も偽の条件も表示される。すべてのワークフローで、コンディション不良情報を利用できます。
トリガーは成功したが、トリガー後の条件が満たされていないために実行されなかったワークフローについては、ワークフローの条件をクリックして、各条件を評価するために使用された値を正確に確認することができます。
Qtip:この条件には、イベントトリガーの後、タスクの前にある条件のみが含まれます。タスク間の条件は含まれない。
条件ロジックと、条件の評価に使用される実際の値が表示されるウィンドウが開きます：
例: 上のスクリーンショットでは、”Medium “という答えが選択されていないので、条件は真です。
例: 上のスクリーンショットでは、”Bad “という答えが選択されていないので、条件は偽です。
Qtip:“Actual value unavailable “と表示された場合は、評価対象のフィールドが完全に存在しなかったことを意味します。よくあるシナリオの1つは、条件がJSONイベントプロパティに基づいていて、そのプロパティが指定されたイベントのJSONペイロードから除外されている場合です。
例: 上記のスクリーンショットでは、条件は “All “を使用してリンクされています。つまり、ワークフロー・タスクがトリガーするためには、すべての条件が真でなければなりません。条件2が偽であったため、ワークフロー・タスクはトリガーされなかった。
Qtip:このウィンドウには、ワークフローの実行IDも 表示されます。これは、サ ポートとワークフローのトラブルシューティングを行う際や、後でワークフ ローを検索する際に役立ちます。
ワークフローステータス
ワークフロータスクには、ワークフローの進捗状況を知らせる様々なステータスを設定することができます：
- キューに入っている：タスクは次へ実行するようにスケジュールされている。
- 進行中：タスクは現在実行中です。 例: ワークフローで2つのタスクが連続して実行されます。実行前に、最初のタスクは “Queued” に設定される。実行中、最初のタスクのステータスは「進行中」となり、2番目のタスクは表示されない。最初のタスクが完了すると、2番目のタスクは “キュー中 “と表示される。
- 成功した：タスクは実行された。メールタスクの場合、これはクアルトリクスサーバーを離れたことを意味します。
- 失敗した：タスクはトリガーしなかった。これは通常、タスクのセットアップにおけるエラーが原因である。例えば、メールタスクに無効なメールを入力した場合。 Qtip:非ETLワークフローには60秒のタイムアウトがあります。つまり、ワークフローの実行に60秒以上かかると、ワークフローは失敗する。Qtip:ワークフロー内の1つ以上のタスクが失敗した場合、ワークフローを再試行することができます。詳細については、ワークフローの再試行のセクションを参照してください。
- 自動再試行： ワークフロー内の1つ以上のタスクが失敗し、再試行されている。詳しくはワークフローとタスクの失敗をご覧ください。
- 遅延開始：ワークフローに遅延開始設定が適用されているため、ワークフローが実行されませんでした。ワークフローがトリガーされたはずの1つ以上のインスタンスが、タイムインターバルが終了するまでキューに保持されています。
- 未実行：ワークフローはトリガーされたが、ワークフローの条件を満たさなかったため、実行されなかった。
- ブロックされました：このステータスは、ブランドが1日に実行できるワークフローの上限を超えたことを意味します。クアルトリクスでは、各顧客の1ブランドあたりのワークフロー実行数を1日あたり300,000件に制限しています。ワークフローがトリガーされるたびに、ワークフローの実行が1回カウントされます。(ワークフローのタスク数は関係ありません）失敗したワークフローも、ワークフローの実行としてカウントされます。ワークフローの制限は、データセンターのタイムゾーンに基づき、24時間ごとの深夜にリセットされます。リミットに達した後にトリガーされたワークフローは「ブロック」ステータスを報告し、リミットがリセットされる翌日に手動で再試行することができます。ブロックされたワークフローを減らすためのアドバイス（1日の制限を変更するオプションなど）については、トラブルシューティングのヒントを参照してください。 Qtip：（最初のステップとして）決定から始まるワークフローは、決定基準が満たされていない場合、カウントされません。例えば、チケットのステータスが “クローズ “である場合にのみ実行されるワークフローを設定した場合、オープンチケットや進行中のチケットはワークフローを実行しないため、制限数にカウントされません。Qtip:2025年9月10日より、1日あたり30万件のワークフロー実行制限を実施する予定です。クアルトリクスは、自らの裁量により責任を負うことなく、あらゆる製品機能のロールアウトのタイミングの変更、プレビュー段階または開発段階の製品機能の変更、何らかの理由により、または理由なく製品の機能をリリースしないことを選択する場合があります。
改訂履歴
改訂 履歴では、アクセシビリティのあるワークフローで行われた変更を確認することができます。つまり、ワークフローがいつ無効化／有効化されたのか、いつ条件変更が行われたのか、誰がワークフローを編集したのかを正確に確認することができます。
改訂履歴は、特定のワークフローでも、プロジェクト内のすべてのワークフローでも利用できます。以下は、1 つのアンケートの改訂履歴のスクリーンショットで、すべてのワークフロー編集が順番に表示されています。
改訂履歴には、ワークフローに関する以下の情報が含まれています：
- ワークフロー名：編集されたワークフロー名。プロジェクト全体の改訂履歴を見ている場合のみ表示されます。
- ユーザー名：編集を行ったユーザーのユーザー名。
- 何が変更されたか：ワークフローに加えられた編集の説明。
- 最終改訂日：ワークフローが編集された日時。
変更前と変更後のタスク構成を見るための追加オプションがある：
- 詳細を見る変更前と変更後のタスクのJSON入力ペイロードを表示します。JSONペイロードは、ワークフロー、特にETLワークフローのトラブルシューティングに役立ちます。
- タスクのバージョンを見る：タスクエディターウィンドウでタスクの設定を見る。ウィンドウ上部のタブを使って、タスクの新しいバージョンと前のバージョンを切り替える。
QTip:メールタスク、XM DIRECTORYタスク、チケットタスク、Salesforceタスク、古い設定のTANGO Cardタスクでは、このビューは使用できません。
改訂履歴の検索
実行履歴にはあらかじめフィルターが設定されており、ワークフローの特定の変更を簡単に見つけることができます。
- ユーザー名ドロップダウンを使用して、変更を行ったユーザーでフィルターをかけます。
- 変更内容」ドロップダウンを使用して、ワークフローに加えられた編集のタ イプでフィルターをかけます。
- 最終修正日（範囲）フィルタを使用して、編集が行われた日付範囲を選択します。カレンダーアイコンをクリックしてカレンダーを表示し、日付を選択します。
ワークフローの再実行
Qtip: ワークフローを再実行するには、ワークフロー設定で「ワークフローの手動再試行を許可する」設定を有効にする必要があります。
実行履歴ページからワークフローを再実行し、再度完了させることができます。再実行するワークフローを選択し、［ワークフローの再実行］をクリックします。
失敗したワークフローを再実行する場合、最初に失敗したタスクから開始するか、ワークフローの最初から開始するかを尋ねられます。
ワークフローは、以下のシナリオでは実行できません：
- ワークフローとタスクの失敗設定で、ワークフローを再試行できない、または一定期間外にワークフローを再試行できない。
- 再実行するワークフローは、現在進行中、キュー中、または既に再実行中です。
- ワークフローは当初、スタートが遅れた状態だった。
- 選択したワークフローを再実行すると、実行可能なワークフローの上限を超えます。
ワークフローのリトライ
ワークフロー内のタスクが失敗し、ワークフロー全体を再試行する場合は、［再試行］をクリックします。再試行ボタンはタスクが失敗した場合にのみ表示されることに注意。リトライボタンをクリックすると、ワークフロー全体が再実行されます。
Qtip:成功したワークフローを再実行したい場合は、ワークフローの再実行を参照してください。
ワークフローのリトライは、最初の実行と全く同じ設定でタスクを再実行します。ワークフローを再試行する必要があるのは、以下のような場合です：
- クアルトリクス内部エラーによりタスクがタイムアウトしました。
- サードパーティシステムに起因する問題によりタスクが失敗した。 例:SuccessFactorsから従業員をインポートしたいのですが、SuccessFactorsアカウントに正しい権限を設定していません。クアルトリクスでワークフローを実行すると、SuccessFactorsアカウントに従業員データを表示する権限がないため、失敗します。しかし、SuccessFactorsの権限を更新すれば、クアルトリクスでタスクを再試行でき、タスクは成功します。
コンフィギュレーション・エラーにより失敗したタスクを再試行すると、再試行は再度失敗する。代わりに、コンフィギュレーションエラーを修正した後に、新しいワークフローの実行を開始する必要があります。
例: XM DIRECTORYタスクで、作成したアンケート調査に基づいて新しい連絡先をディレクトリに追加します。タスクでは、回答者の回答をXM DIRECTORYのフィールドにマッピングします。フィールドをマッピングする際、誤って間違ったフィールドを “email “にマッピングしてしまいました。マッピングが正しくないため、新しく作成された連絡先には検証メールアドレスがなく、タスクは失敗します。タスクを編集してマッピングを修正し、タスクを再試行しても失敗する。その代わりに、最初の回答をやり直して、更新されたフィールドマッピングを使用する新しいワークフローを生成することができます。
トリガーIDの検索
ワークフローが実行される度に、そのワークフローの各タスクコンポーネントには、一意のトリガーIDが割り当てられます。このIDを使用してワークフローの特定の実行を検索したり、ワークフローが失敗した理由のトラブルシューティングが必要な場合にクアルトリクスサポートに提供することができます。
トリガーIDは、レポート内の特定のワークフロー実行を検索するために使用することができます。
データファイルのダウンロード
注意: データファイルのダウンロードはワークフローオーナーのみ可能です。
一部のワークフロータスクでは、そのタスクで処理されたデータのファイルをダウンロードすることができます。これはトラブルシューティングや、クアルトリクスと他のサードパーティシステムの間でどのようなデータをやり取りしているかを理解するのに役立ちます。
データファイルをダウンロードするには、特定のタスクを表示しているときに、ファイル セクションのダウンロードボタンをクリックします。これでデータがCSVファイルとしてパソコンにダウンロードされ、表計算ソフトで開くことができます。
ETLタスクの中には、以下のようなデータファイルをダウンロードできるものがある：
- SFTPファイルからのデータ抽出タスク
- SFTPタスクへのデータロード
- Google Driveタスクからのデータ抽出
- アンケート調査タスクからの回答の抽出
- XMDタスクへの連絡先とトランザクションの追加 Qtip:タスクによっては、処理されたファイルを使って正常に実行されたとしても、”There was no files available when this task was run “というメッセージが表示されることがある。
注意: タスクが100以上のファイルを生成した場合、ダウンロードできるのは最初の100ファイルだけです。
ワークフローのブロックと実行制限のトラブルシューティング
Qtip:2025年9月10日より、1日あたり30万件のワークフロー実行制限を実施する予定です。クアルトリクスは、自らの裁量により責任を負うことなく、あらゆる製品機能のロールアウトのタイミングの変更、プレビュー段階または開発段階の製品機能の変更、何らかの理由により、または理由なく製品の機能をリリースしないことを選択する場合があります。
ワークフローがブロックされるということは、お客様のブランド（つまりクアルトリクス組織）が、24時間以内に30万回のワークフロー実行という制限を超えたことを意味します。これは、組織内のすべてのユーザーによって共有される制限です。
あなたの組織が実行の限界に達することが多い場合、ブランド管理者としてできること、またワークフローを作成する際にユーザーに奨励できることがいくつかあります。
Qtip:ワークフロー制限に対するブランドの進捗状況は、管理者レポートで確認できます。
- 実行制限を理解する：1日の実行制限はワークフローの実行に適用されます。ワークフローがトリガーされるたびに、ワークフローの実行が1回カウントされます。ワークフロー内のタスク数は関係ない。失敗したワークフローは、ワークフローの実行としてカウントされます。 Qtip：（最初のステップとして）決定から始まるワークフローは、決定基準が満たされていない場合、カウントされません。例えば、チケットのステータスが “クローズ “である場合にのみ実行されるワークフローを設定した場合、オープンチケットや進行中のチケットはワークフローを実行しないため、制限数にカウントされません。
- 古いワークフローや失敗したワークフローを削除します：管理者レポートのワークフロー実行セクションには、組織内の全ユーザーの頻繁に実行されるワークフローが表示されます。ここでは、実行頻度が高すぎたり、実行するたびに失敗しているワークフローを見つけることができます。レポートにはワークフローのオーナーが表示されるため、連絡先や代理でオーナーアカウントにログインし、ワークフローを変更することができます。
- ワークフローが失敗した場合のデフォルト動作を決定します：失敗したワークフローも総エグゼクティブ数にカウントされます。ワークフローやタスクの失敗時の動作を設定するようユーザーを促しましょう。これらの設定により、失敗したワークフローが再試行される頻度を減らすことができます。
- ワークフローの頻度を減らす：ワークフローを作成する際は、スケジュールを慎重に検討すること。ワークフローが頻繁にトリガーされる傾向がある場合は、遅延の追加を検討してください。このオプションは、イベントベースやスケジュール型など、あらゆるタイプのワークフローで利用できます。
- ETLワークフローを使用してバッチでトリガーします：新しいワークフローを作成する際には、ETLワークフローの使用を検討してください。ETLワークフローは、ファイルごとにトリガーするのではなく、複数のファイルを一括して処理するため、ワークフローのエグゼクティブ数を大幅に減らすことができます。 例: アンケート調査で連絡先情報を収集し、XM DIRECTORYにアップロードします。アンケートを送信するたびに新しい連絡先を作成するのではなく、新しい連絡先をチェックし、定期的なスケジュールで一括アップロードするワークフローを作成できます。連絡先インポートワークフローとアンケート調査からのデータ抽出をご覧ください。
- ブロックされたワークフローを手動で再試行：ワークフローの制限は、データセンターのタイムゾーンに基づき、24時間ごとの深夜にリセットされます。リミットに達した後にトリガーされたワークフローは「ブロック」ステータスを報告し、リミットがリセットされる翌日に手動で再試行することができます。
- しきい値通知の設定：ワークフロー消費に対するアラートを設定します。組織が限界に近づくと、あなたや他の主要なチームメンバーが警告を受けることができます。ワークフロー実行レポートの「ワークフロー制限のエグゼクティブアラート」を参照してください。
- 限度額の増額を申請する：1日に許可されるワークフローの増加を申請する前に、上記のアドバイスに従ってワークフローをクリーンアップしてください。それでもなお免除が必要だと思われる場合は、ブランド管理者がテクニカルサクセスマネージャーに連絡することができます。この担当者が、貴組織の限度額増額のリクエストを提出します。
FAQs
How quickly can I expect workflows to run?
How quickly can I expect workflows to run?
Is there a maximum size workflows can be?
Is there a maximum size workflows can be?
素晴らしい！ フィードバックありがとうございます！
フィードバックありがとうございます！