プロセス管理では特定のステータス(や、作業者)にレコードが集まるという事がありがちです。そのため通知が溢れて気づくのが遅れ、より一層溜まっていくという悪循環に・・・。

 

そこで、処理待ちが最大数を超えないように、定時実行でステータスを変更するようにしてみます。

 

今回は「作業依頼」というアプリを作成し、ステータスは、

・作成時=未処理

・処理前=処理待機中

・処理待ち=出荷確認中

とします。



今回のカスタマイズで出来ること

  • 出荷確認中の上限を超えないように、定期実行で処理待機中から出荷確認中へステータスを変更します




「作業依頼」アプリには以下のフィールドを作成しました

フィールド名

フィールドコード

フィールドタイプ

タイトル

タイトル

文字列1行

担当者

担当者

ユーザー選択

詳細

詳細

文字列複数行


プロセス管理はこのように設定しました。



Job Runnerの設定

定時実行で、次のような流れで作成します。


実行予定時刻になった時」に「kintone 接続設定を行う」で処理を開始します。

その次に「キーを指定してレコードを取得する」で、ステータスが出荷確認中のレコードを全取得します。



次の「条件」がポイントで、「レコード全行が準備できた時」に「レコード行数をカウントする」でレコード数を数えます。「他のアクションの実行が完了した時」では無いことにご注意ください。

基本的に、レコードを取得した結果を使う場合は、「レコード全行が準備できた時」か「レコード1行が準備できた時」を使うようにしてください。




最後に、「レコード1行が準備できた時」に「ステータスを変更する」でレコードのステータスを変更します。

レコード1行が準備できた時」は、指定したレコードが複数レコードの場合はレコード数だけ実行されます。なので、5番で取得したレコードを個別にステータス変更するような動きになります。



アクショングラフはこのようになります。

アクショングラフに「やること」の名称を追加




全体の設定は次のようになります。


まとめ

例えば毎時実行にしておくと、1時間に1回、処理待ちが5件未満になると最大5件追加されます。もし処理前のステータスに溜まっている場合は、処理待ちの担当者を増やすなどの対応に気づきやすくなると思います。

 

また、今回は作成していませんが、処理待ちの件数が一定数以上ならslackに通知なども可能です。

 

色々な方法で可視化する事で早めに問題を把握しましょう。