汎用承認フローを作る、の4回目は「更新履歴のテーブルを作る」です。
更新履歴って何に使うの？という疑問が湧きますね。
正直、無くても承認フロー自体は動かせます。
なぜ必要かというと、少々堅苦しい話になりますが、更新履歴の管理が企業統治にかかる重要なテーブルだから、ということになります。
更新履歴テーブルは、汎用承認フローの中で主に2つの大切な役割を担っています。
1. 誰が、いつ、何をしたかの記録
これは「監査証跡」と呼ばれるもので、誰が、いつ、どのような操作（申請、承認、却下など）を行ったかをすべて記録します。
-
不正防止: 誰かが勝手にデータを改ざんしていないか確認できます。
-
トラブル対応: 承認が止まってしまったときに、どこで誰が止めたのかをすぐに把握できます。
2. 間違えた時に元の状態に戻すため
承認フローの中で申請内容を差し戻したり、却下された申請を修正して再申請したりする場面があります。その際、更新履歴に保存された過去のデータを使って、簡単に元の状態に戻したり、変更前後の内容を比較したりできます。
まとめると、更新履歴テーブルは「もしも」の時に備え、何が起こったかを正確に記録し、監査やトラブル解決、データ復旧をスムーズにするための、いわば「タイムマシン」のような役割を果たしています。
堅苦しい話はここまでにして、実際の更新履歴テーブルのイメージはこんなです。
各フィールドの用途を解説します。
| フィールド名 | 用途 |
| Title | 申請内容の件名や要約を把握するためのフィールドです。 |
| RequestID | どの申請に対する履歴かを特定するためのIDです。 |
| TaskID | ワークフロー内のどのステップで処理されたかを示すIDです。 |
| ApproverEmail | 誰がこの処理を行ったかを特定するメールアドレスです。 |
| Result | 承認または却下の結果を示します。 |
| Comment | 承認者や却下者からの補足情報や理由を記録するためのフィールドです。 |
| CompletionDate | その処理がいつ完了したかを記録するタイムスタンプです。 |
申請トランザクションが１つの申請に対し1レコード、データが作られるのに対し、承認履歴テーブルは１つの申請に対し1～ｎレコードが作られる点がポイントです。例えば多段階の承認をするとき、それぞれの承認者と承認理由、承認時刻などを記録するためですね。
次はいよいよ、今まで作ってきたマスタ、テーブルを使って、Power automateのフロー作成に入ります。
