- 01
実行履歴を調査
失敗した処理を特定
- 02
配列として渡す
空の入力も扱う
- 03
再処理・受信確認
重複通知にも注意
入力なし・1人・複数人を分けて検証する。
Conclusion
この記事の結論
実行履歴から失敗箇所を確認し、配列が文字列として評価される入力を見直しました。対象が未入力の場合は空の配列として扱う式に修正し、フローを有効化して失敗した実行を再処理しました。
記事の位置づけ:解決記録あり
企業・個人・内部構成が特定されないよう、内容を一般化して紹介しています。
背景と課題
依頼相手への通知フローが失敗を繰り返し、停止していました。繰り返し処理に渡す値が、配列として扱われているかが調査の焦点でした。
対応・整理した内容
実行履歴から失敗箇所を確認し、配列が文字列として評価される入力を見直しました。対象が未入力の場合は空の配列として扱う式に修正し、フローを有効化して失敗した実行を再処理しました。
記録で確認できる結果
対応履歴には、再実行の成功と通知先へのTeams通知の確認が記録されています。今回の原稿作成時に本番フローを再実行したものではありません。
同じ課題に取り組む際の確認事項
入力なし・1人・複数人のケースを分けて検証します。再実行で重複通知や二重登録が起きないかも確認し、実行成功の表示と受信結果を照合します。
参考情報
対応手順と図解
同じ課題に対応するときの確認手順です。対象環境と権限を確認してから進めてください。
- 01失敗した実行履歴で繰り返し処理の入力を確認する
- 02配列・単一値・空値の違いを調べ、入力の扱いを修正する
- 03空件・一件・複数件で通知先と通知件数を確認する
確認結果で判断期待どおり → 結果を記録して完了期待と異なる → 止まった手順と結果を整理し、担当者へ確認
手順 1
失敗した実行履歴で繰り返し処理の入力を確認する。
手順 2
配列・単一値・空値の違いを調べ、入力の扱いを修正する。
手順 3
空件・一件・複数件で通知先と通知件数を確認する。
完了の判断
最後の手順で期待する結果が得られたことを記録します。設定変更や処理の受付だけで完了とせず、利用者の操作と実際の結果を確認してください。うまく進まない場合は、停止した手順・発生時刻・対象・確認済みの結果を担当者に伝えます。
