はじめに
こんにちは、ネクストモード株式会社 テクニカルサポート担当です。
Okta Workflowsを活用していると毎日起動したいflowや月に1度だけ起動したいflowが出てきます。さまざまなflowを構築していく中でこれらのトリガーをひとまとめにすることができないかと思い試行錯誤した結果をご紹介します。
この記事では抽象化したScheduled flowの仕組みをJob管理テーブルとMain flowとHelper flowで実現します。
Scheduled flowの課題
例えば、毎月1日に起動する設定のflowがある場合、1日以外もそのflowがActiveのままとなります。
また、以下のように毎日起動する設定でも、ストリーミングによってすぐにHelper flowへ遷移するflowがあります。
Okta WorkflowsのそれぞれのプランではActiveなflow数に制限があるため、極力flow数を減らしたくなります。
解決策
以下の構成で抽象化することで最小限のflow数でさまざまなタイプのScheduled flowをまとめることができます。
- Table：スケジュールやJob名を定義したテーブル
- Main flow：テーブルを読み込みHelper flowへJobを渡すflow
- Helper flow：Main flowから受け取ったJobが実行すべきタイミングかを判定し、実行する場合はJob名で条件分岐を実施
以下のような流れとなります。
具体的なTableとflowは以下です。
Job管理Tableの作成
以下のカラムを設定します。
- enabled：Jobの有効/無効を指定(True/False型)
- job_name：処理の名称
- schedule_type：どのようなスケジュールでJobを実行するか(hourly,daily_at_hour,weekly_at_hour,monthly_at_hourの4タイプ)
- hour：何時に実行するか
- weekday：何曜日に実行するか(Mon,Tueのように3文字レターで表現)
- day_of_month：何日に実行するか
- slack_channel：Slackメッセージを送るチャンネルID(オプション項目)
- slack_bot_name：Slackメッセージを送る際のBot名(オプション項目)
- slack_bot_emoji：Slackメッセージを送る際のBotのアイコン絵文字(オプション項目)
Main flowの作成
テーブルのenabledカラムがTrueのみを取得します。
取得したレコードをHelper flowに渡します。
Helper flowの作成
全体の構成は前半の日時取得部分、実行タイミング判定部分、Job実行部分、Slackメッセージ投稿部分(今回の検証のデバッグ目的)
実行タイミングの判定ロジック（schedule_type別）
Helper flowが実行すべきタイミングを判定するロジックを、まず表で整理します。
| schedule_type | 実行条件（判定式） | 参照するカラム |
|---|---|---|
| hourly | job_name が空でない | job_name |
| daily_at_hour | now_hour == hour | hour |
| weekly_at_hour | now_weekday == weekday AND now_hour == hour | weekday, hour |
| monthly_at_hour | now_day == day_of_month AND now_hour == hour | day_of_month, hour |
前半部分
Main flowから受け取ったレコードを受けとります。
現在時刻を取得し、日本時間で時間(9時、13時など)、曜日(Mon、Tueなど)、日(1日、5日など)をそれぞれ取得します。
実行タイミング判定部分
レコードのschedule_typeがhourlyの場合、レコードのjob_nameがあることをTrue/FalseのCompareカードで判定
hourlyなので毎時間実行されることを想定
レコードのschedule_typeがdaily_at_hourの場合、レコードのhourと現在のHourが一致するかをTrue/FalseのCompareカードで判定
レコードのschedule_typeがweekly_at_hourの場合、レコードのhourと現在のHourが一致するか、レコードのweekdayが現在のWeekdayと一致するかをそれぞれTrue/FalseのCompareカードで判定
両方の条件がTrueであるかをTrue/FalseのAndカードで判定
レコードのschedule_typeがmonthly_at_hourの場合、レコードのhourと現在のHourが一致するか、レコードのmonthly_at_hourが現在のDayと一致するかをそれぞれTrue/FalseのCompareカードで判定
両方の条件がTrueであるかをTrue/FalseのAndカードで判定
Continue Ifカードで実行タイミング判定の結果がTrueの場合のみ処理を継続
Job実行部分
レコードのjob_name毎に条件分岐を作成します。
今回の検証ではすべての条件分岐それぞれでTextのComposeカードでレコードのJob_nameを引用しメッセージを作成するという簡単な処理としました。
共通処理部分
今回は共通処理としてSlackチャンネルへメッセージを送信します。
レコードからslack_channelやslack_bot_name、slack_bot_emojiを反映し、メッセージ部分をJob実行部分のアウトプットを指定します。
実行結果
以下のようにそれぞれのJobの時間にそれぞれのjob_nameを反映したメッセージがSlackチャンネルに投稿されています。
2026/03/17(Thu)のため、テーブルに設定したすべてのパターンに一致する状態です。
まとめ
本記事では、Okta WorkflowsのScheduled flowをジョブごとに増やす際に生じやすい「常時Activeになってしまう」「起動してもすぐにHelper flowへ遷移するだけ」といった無駄を、Job管理Tableに集約して解消する方法を紹介しました。
スケジュール定義をテーブルに寄せ、Main flowが有効なジョブを読み込んでHelper flowへ渡すことで、フロー数を最小限に保ちながら、毎時・毎日指定時刻・毎週指定曜日/時刻・毎月指定日/時刻といった実行タイミングを共通ロジックで判定できます。
一方で、Job実行部分がIf/ElseIf内に集約されるため、処理が複雑になると可読性や相関関係が分かりにくくなる可能性があります。この課題にはDescriptionの整備や別途ドキュメント化することである程度は軽減が可能です。
この方法は、スケジュール種別が複数あり、今後もJobが増え続けるような運用に特に向いています。反対に、Jobごとの処理が重く、分岐内の実装が複雑になりがちなケースでは、Helper flow内の条件分岐が肥大化しやすいため、適用範囲を見極めるとよいでしょう。
