はじめに こんにちは、 ネクストモード株式会社 のSaaSおじさん久住です...
はじめに
こんにちは、ネクストモード株式会社テクニカルサポート担当です。
SmartHRなどのHRシステムを起点にOktaユーザーを作成したいというニーズは多くあります。その際、メールアドレスを決める必要があります。
今回は特定の命名規則に従い、既存ユーザーと重複する場合はメールアドレスに数字を付加するロジックをOkta Workflowsで実装しましたので紹介します。
この仕組みの作成にあたり、以下のドキュメントを参考にしました。
想定するシナリオ
HRシステムの情報を元にメールアドレスを生成するには、命名規則と重複チェックの仕組みが必要です。今回は以下の要件に基づき、Okta Workflowsで実装します。
命名規則
- ローカルパートはHRシステムに登録された姓名のアルファベット表記を使用し、firstname.lastname形式とする
- ドメインパートはグループ会社ごとに指定する（例：example-hd.com、example-tech.com）
- 重複が発生した場合は、firstname.lastname.2のようにローカルパート末尾に「.」と数字を付加する
重複チェック
- Slackで退職者を含む既存ユーザーとの重複を確認する
- 生成したメールアドレスを格納するテーブルでも重複を確認する
メールアドレスの生成と発行のタイミング
HRシステムに入社情報が登録された時点でメールアドレスを生成します。一方、Oktaアカウントの有効化は入社日当日または数日前に行います。
このタイミングを分ける理由は2つあります。1つ目は、発行予定のメールアドレスを事前に把握したいという現場のニーズに応えるためです。2つ目は、ライセンスコストとセキュリティの観点から、アカウント発行を直前まで控えるためです。
このタイムラグに対応するため、生成したメールアドレスをテーブルに保管し、確保しておきます。
全体像
HRシステムから取得した姓名のアルファベット表記とドメインパートを指定し、Helper flowを呼び出します。
Helper flowは再帰処理により重複のないメールアドレスを生成し、生成が完了すると呼び出し元のflowに値を返します。
Okta Workflowsの作成
まずテーブルと、呼び出されるHelper flowから紹介します。その後、Helper flowを呼び出す部分を説明します。
テーブル名：Joiner Email Registry
生成したメールアドレスを格納するテーブルです。NameとEmailのみのシンプルな構成です。
flow名：02.Generate Unique Email
- 呼び出し元flowからlocalpart、domain、countを取得します。
- If/Elseカードでcountが1（初期値）の場合、localpartとdomainを連結して候補メールアドレスを生成します。
- countが1以外の場合、localpartに「.」とcountとdomainを連結して候補メールアドレスを生成します。
- 生成した候補メールアドレスは、念のためすべて小文字に変換します。
- Search UserカードでSlackユーザーを小文字化した候補メールアドレスで検索します。
- Compareカードで検索結果としてSlack IDがある場合はTrueを、ない場合はFalseを返します。
- Search Rowsカードでテーブル名：Joiner Email Registryを小文字化した候補メールアドレスで検索します。
- Compareカードで検索結果としてRow IDがある場合はTrueを、ない場合はFalseを返します。
- All False?カードで両方の検索結果がFalseの場合はTrueを、それ以外の場合はFalseを返します。
- All False?カードの結果がTrueの場合、If/Elseカードは候補メールアドレスを変数generatedUniqueEmailにアサインします。Returnカードで呼び出し元にgeneratedUniqueEmailを返します。
- All False?カードの結果がFalseの場合、Addカードでcountに1を加算します。Call Flowカードで自分自身を呼び出し、localpartとdomainは元の値を、countは加算後の値を指定します。処理はflowの最初に戻ります。
この自分自身を呼び出す仕組みが再帰処理です。
flow名：01.Main flow
このflowは、02.Generate Unique EmailをCall Flowカードで呼び出し、Create Rowカードで戻り値をテーブルに記録するシンプルな構成です。実行時にはRunボタンを押してlocalpartとdomainを指定します。
実際の運用では、HRシステムの情報をもとにlocalpartとdomainを事前に加工して指定することを想定しています。
実際の動作
再帰処理の動作を確認するため、Slackに既に存在するメールアドレスを意図的に候補として使用します。
01.Main flow
01.Main flowのRunボタンを押し、localpartとdomainを手動で指定しました。localpartには意図的に大文字を含めています。
この場合、候補メールアドレスは super.admin@example.com になります。
02.Generate Unique Email（1回目）
ここからは、ログの重要な部分を抜粋して動作を説明します。
以下のログから、候補メールアドレスがすでにSlack上に存在することがわかります。そのため、All False?カードの結果はfalseとなります。
If/Elseカードはfalseの場合の処理を実行し、countに1を加算して自分自身を新しい変数で呼び出します。この時の戻り値とその後の流れについては後述します。
02.Generate Unique Email（2回目）
2回目の実行では、候補メールアドレスは super.admin.2@example.com になります。このアドレスはSlack上に存在しません。
テーブルを検索した結果も存在しないため、All False?カードの結果はtrueになります。
If/Elseカードはtrueの場合の処理を実行し、候補メールアドレスを変数generatedUniqueEmailにアサインします。そして、Returnカードで呼び出し元にgeneratedUniqueEmailを返します。この呼び出し元は、02.Generate Unique Email（1回目）を指します。
02.Generate Unique Email（1回目）
02.Generate Unique Email（2回目）から返された値を02.Generate Unique Email（1回目）が受け取ります。そして、Returnカードで呼び出し元にgeneratedUniqueEmailを返します。ここでの呼び出し元は01.Main flowです。
01.Main flowの結果
戻り値として候補メールアドレス super.admin.2@example.com を取得し、テーブルに保存しています。
テーブルに保存された結果は以下の通りです。
再帰処理の動作をより詳しく確認したい場合
以下のように、再帰処理の中心となるIf/Elseカードの前後にWait Forカードを設置し10秒ほどの待機時間を追加すると、ログの経過がスローになり、呼び出し元と戻り値の関係を観測しやすくなります。
まとめ
今回ご紹介したflowでは、ルールに沿って重複のないメールアドレスを生成できました。自分自身を呼び出す再帰処理は概念的に少し難しく、このブログの文章だけでは伝わりづらい部分があると思います。ぜひ実際にflowを作成し、挙動を確認してみてください。
また、今回は重複のないメールアドレスの生成に焦点を当てましたが、実際にOktaアカウントの作成タイミングを考慮すると、全体の仕組みはもっと広がりを持つはずです。
例えば、HRシステムからの情報取得、入社日に基づいたトリガー設定、Oktaユーザー作成後の通知など、様々な要素を組み合わせることで、より実用的な自動化を実現できるでしょう。このブログが、皆さんのOkta Workflows活用の一助となれば幸いです。
