Makeの処理を承認後に実行する｜確認用の表と送信状態を分ける

完成するものと対象範囲

表で確認済みになった依頼だけを外部へ送る構成を作ります。Slackは確認依頼の通知先として使い、承認そのものはアクセスを制限した管理表で記録します。メッセージへのリアクションを無条件の承認として扱わず、誰が何の版を承認したかを残します。

承認の対象には本文だけでなく宛先、添付、実行する処理も含めます。表示上の本文が同じでも、添付が変われば同じ承認ではありません。版を作る規則を先に決め、承認後に変更してよい項目と、変更したら再承認が必要な項目を担当者が理解できるようにします。Slackの通知文には承認欄そのものを埋め込まず、管理表で対象を照合するためのIDと要約を載せます。

項目と保存先を準備する

入力と保存先に用意する項目は、依頼ID、本文版、宛先、確認者、承認版、承認日時、送信状態、送信結果IDです。元の値と担当者が確認した値は区別し、同じ名前の列を別の意味へ使い回さないようにします。実運用の情報を入れる前に、練習用の識別子で一件を作成し、必要な担当者だけが参照・編集できる保存先を選びます。

確認者が承認できる範囲は、管理表の編集権限だけでは表せないことがあります。全社の依頼を同じ表へ入れるなら、部署別の閲覧や承認権限をどう制限するか確認します。列を非表示にしただけでは保護にならないため、利用する表サービスの権限で要件を満たせるかを判断してください。満たせない場合は、認証と承認権限を持つ管理アプリに工程を移します。

設定を順に進める

依頼表に下書き・確認待ち・承認・送信済み・要確認の状態を用意します。宛先と本文を固めて版番号を付け、MakeからSlackへ確認依頼を通知します。通知のリンク先には編集権限のある管理画面を使い、公開表へ承認欄を出しません。

実行側のシナリオは承認状態だけでなく、現在版と承認版の一致も条件にします。宛先や本文が修正された依頼は確認待ちへ戻します。承認者は送信担当と分けられるようにし、表の権限もその運用に合わせます。

外部送信の直前に対象IDを再確認し、同じ依頼版の送信結果を検索します。送信後は結果IDを保存し、二度目は処理を終了します。シートだけでは同時実行を厳密に排除できないため、重要な送信は並列数や保存先の一意性も検討します。

少数のデータで確かめる

例として依頼R-101の版一を承認し、その後に宛先を変更します。現在版が二、承認版が一なら実行を止めるのが正解です。版二を承認した後に一度だけ送信し、同じ行を再取得しても送信件数が増えないことを確かめます。

運用中の変更を扱う

承認後に取消された依頼も履歴へ残します。実行前の取消と、実行後に取り消したい依頼は同じではありません。外部側に取消APIがあるか、送信済みメールを撤回できるかは別に確認が必要です。取り消せない処理は送信済みと明記して人へ渡し、管理表の状態を未送信へ戻して済ませません。練習では承認、改訂、取消、送信失敗の四通りを別IDで確かめます。

費用と利用量を見積もる

承認後実行では、確認待ちを検索する頻度と対象件数、承認通知、実行結果の保存を分けて数えます。未承認の依頼を短い間隔で全件読み直す必要があるかを見直し、要求される待ち時間に合わせます。管理表の編集者数や権限に必要なプランも費用へ含め、Makeの月額だけで承認工程全体の費用を決めないようにします。

不具合が出たときの確認

送信成功後に状態更新が失敗したときは、外部側の結果を照合してから再送を判断します。未送信に見えるだけで送信されていることがあります。送信先、依頼版、外部の結果IDを確認し、不明なものは要確認へ移して自動再送しません。

運用を始める前の確認

公開・運用前の確認では、通常の一件だけでなく、必須項目が欠けた一件、同じ識別子を再利用した一件、確認後に内容を変更した一件を分けて試します。特に「依頼ID」が元の記録へ戻る手掛かりになり、承認した版だけを一回実行し、変更された依頼は再確認へ戻すという条件を満たすか確認してください。結果を担当者と共有し、どの入力をどの状態へ残すかが説明できてから対象を広げます。

複数の依頼を一括で承認する場合も、実行結果は依頼IDごとに残します。十件のうち一件の宛先が不明なら、その一件だけを確認へ止め、他の成功結果まで未処理に戻さない構成にします。まとめ通知を使う場合も、承認された依頼の版と件数を明示してください。練習では三件を承認し、うち一件を実行前に取り消して、二件だけが外部へ渡るかを確認します。承認画面の一覧と実行時の状態が違ったときに、実行直前の再確認が機能するかが重要です。

• 社内承認フローの選び方
• FilterとRouterの使い方
• Makeの重複防止