向いている業務
- 業種
- 備品を貸し出す事業者
- 部門
- 総務・情報システム
- 実行頻度
- 平日の定期実行で1件ずつ。平日1日1〜5件を想定
- 作業量の試算（未実測）
- （未実測）月300分−承認0分−例外対応50分−運用保守60分＝月190分を想定
PigeonCloud備品管理Slack通知済み管理
PigeonCloudの返却超過になった備品をSlackへ通知する
平日の定期実行で、PigeonCloudの計算項目「通知対象」が真かつ「通知済み」が偽のレコードを1件だけ取得し、Slack送信後に「通知済み」を真へ更新する構成の設計例です。
設計例（未検証）:
この手順は Pigeon Workflow のノードで組める構成として設計したもので、実機での検証記録はまだありません。導入時は下の「検証時に確認する項目」を自社条件で確認してください。
Fit
このレシピが向く条件と対象外
Workflow
ワークフロー図
平日に定期起動
定期実行（自動起動）
通知対象が真かつ通知済みが偽のレコードをlimit 1で取得
PigeonCloud 取得
取得件数が0件か判定
条件で分岐
返却超過を通知
Slack 送信
対象レコードの通知済みを真へ更新
PigeonCloud 保存
例外・確認の分岐
条件で分岐 から分岐
- 取得件数が0件か判定
- 0件なら後段へ進めない
- 処理を終了
通知対象はPigeonCloud側の計算項目で判定する
Slack 送信 から分岐
- API失敗時は実行失敗として停止
- 結果不明時はSlackとPigeonCloudの通知済み項目を照合
- 担当者が再実行
API失敗時は実行失敗として停止し、結果不明時は送信先と台帳を照合してから担当者が再実行する
PigeonCloud 取得 から分岐
- 同時実行では双方が通知済みを偽と判断する可能性を確認
- 定期実行の間隔を空ける
- 1件ずつ処理
同時実行では双方が未送信と判断して重複送信があり得るため、同時実行を避ける運用にする
再実行や重複防止の扱いは、上の『例外・確認の分岐』に記載しています。
Verification checklist
検証時に確認する項目
- データ：個人情報、AIの処理先、保存期間、通知先に表示する項目を確認する。
- 認証：OAuthやAPIキーを最小権限にし、Webhook署名と秘密情報の更新・失効手順を確認する。
- 復旧：順序逆転、同時実行、レート制限、上限付き再試行、結果不明時の手動復旧を確認する。
- 承認：承認期限、代理承認者、却下・期限切れ後の修正先を確認する。人の承認を使わない手順では確認担当と停止条件を決める。
- 運用：運用担当者、停止・再開の判断者、障害時の連絡先を決める。
- 記録：実行結果と例外対応の記録先（台帳）と保存期間を決める。
Integrations & permissions
必要な連携と権限
PigeonCloud
返却期限と返却状態から計算項目「通知対象」を求め、「通知済み」が偽のレコードをlimit 1で取得し、送信後に対象レコードを更新します。
Slack
備品ID、利用者、返却期限、担当者を対象チャンネルへ送ります。
必要な権限・アカウント
- PigeonCloudの計算項目設定・読み取り・保存権限
- 通知対象の算定、未通知レコードの取得、通知済み項目の更新に使います。
- Slackの投稿権限
- 備品情報を共有できる通知先チャンネルだけに限定します。
Exception handling
例外時の挙動
条件で分岐 から分岐
- 1. 取得件数が0件か判定
- 2. 0件なら後段へ進めない
- 3. 処理を終了
通知対象はPigeonCloud側の計算項目で判定する
Slack 送信 から分岐
- 1. API失敗時は実行失敗として停止
- 2. 結果不明時はSlackとPigeonCloudの通知済み項目を照合
- 3. 担当者が再実行
API失敗時は実行失敗として停止し、結果不明時は送信先と台帳を照合してから担当者が再実行する
PigeonCloud 取得 から分岐
- 1. 同時実行では双方が通知済みを偽と判断する可能性を確認
- 2. 定期実行の間隔を空ける
- 3. 1件ずつ処理
同時実行では双方が未送信と判断して重複送信があり得るため、同時実行を避ける運用にする
FAQ
よくあるご質問
この手順は検証済みですか？
設計例です。実機での検証記録はまだありません。検証時に確認する項目は本ページの一覧のとおりです
返却期限を過ぎたかはどこで判定しますか？
PigeonCloud側の計算項目「通知対象」で算定し、ワークフローは真かつ「通知済み」が偽のレコードを取得する想定です。
長期未返却を毎日通知しますか？
Slack送信後に「通知済み」を真へ更新します。再通知する場合は、PigeonCloud側で通知済みを戻す条件と周期を導入前に決める想定です。
Related
親の活用シーンと関連レシピ
関連レシピ検証記録あり
PigeonCloudに申請が作成されたら入力を検査してSlackへ確認依頼を送る
申請の必須項目を検査し、正常時は確認依頼、不備時は不備内容を、未送信の検査版に限って通知する検証記録です。この検証はSlack 送信をメール送信に、Google スプレッドシート台帳を PigeonCloud の台帳テーブルに置き換えた構成で行った部分検証です。
関連レシピ設計例（未検証）
PigeonCloudの在庫数が発注点を下回ったらSlackへ通知する
PigeonCloudの計算項目「発注対象」を使って在庫更新を判定し、未送信の対象だけをSlackへ知らせる構成の設計例です。
関連レシピ設計例（未検証）
PigeonCloudに日報が追加されたら要点を承認後にSlackへ共有する
PigeonCloudに追加された日報から進捗、課題、支援依頼を要約し、人が確認した未送信の内容だけをSlackへ共有する構成の設計例です。