Workday

Oktaでは、標準のAPIを通じてWorkdayからユーザーやグループをインポートできます。

Workdayからのインポート

WorkdayからOktaへのインポートにはユーザーとグループが含まれます。OktaはWorkdayプロビジョニンググループのみをインポートします。Workdayセキュリティグループはインポートされません。

インポートされたWorkdayユーザーからOktaユーザーが作成されます。Workdayでは、Oktaにインポートされたユーザーは管理されません。Workdayでユーザーを更新しても、関連付けられているOktaユーザーには影響しません。

インポートされたWorkdayプロビジョニンググループからOktaグループが作成され、これを使ってアプリを割り当てることができます。

インポートタイプ

Oktaは3種類のインポートに対応しています。

フルインポート
増分インポート
リアルタイム同期インポート

WorkdayからOktaに手動でインポートを実行できます。さらに、増分インポートおよびフルインポートを毎週実行するか1時間ごとに実行するかを選択できます。OktaのWorkdayインスタンスにあるプロビジョニング（Provisioning）タブに移動します。Oktaへ（To Okta）（Edit）セクションにある一般（General）領域で編集（Edit）（To Okta）をクリックし、増分インポートスケジュール（Incremental Import Schedule）とフルインポートスケジュール（Full Import Schedule）］のドロップダウンリストでインポートの頻度を設定します。

フルインポート

フルインポートでは、すべてのワーカー、すべての基本属性とカスタム属性がインポートされます。このインポートは時間がかかりますが、2つのシステム間の調整を実行するために必要です。フルインポートを使用すると、他のインポートタイプでサポートされない属性を取り込むことも可能です。フルインポートには、基本属性、未来（または非未来）の有効な日付のカスタム属性が含まれています。また、増分インポートやリアルタイム同期インポートでは省略される変更も含まれています。このインポートは毎週実行するのが一般的です。

増分インポート

増分インポートは、Workdayが最後の増分インポート以降に更新されたと識別するワーカーのデータをインポートします。これには、Workdayで基本属性値またはカスタム属性値が変更されたワーカーが含まれます。有効な日付のカスタム属性を変更しただけでは、増分インポートはトリガーされません。増分インポートに含まれるのは、基本属性、非未来および未来の有効な日付のカスタム属性です。増分インポートの頻度は、通常の業務プロセスに対応した間隔に設定します。通常、これは少なくとも1日に1回であり、1時間に1回の頻度でスケジュールできます。「増分インポート」を参照してください。

リアルタイム同期インポート

リアルタイム同期（RTS）はWorkdayからOktaへの更新をリアルタイムにトリガーするために使用されます。従業員の突然の退職など、タイムリーな変更が重要な場合に使用します。Oktaにこのプロセスを開始するようトリガーを送るために、Workdayで業務プロセスを構成します。RTSインポートには、基本属性、未来（または非未来）の有効期限付きカスタム属性が含まれています。「Workday Real Time Sync」を参照してください。

これらのインポートタイプを最適に設定することで、WorkdayからOktaへ移行するデータの精度とタイムリーさを最適に保つことができます。インポートを構成するときは、各インポートタイプの機能と制限を考慮してください。

Oktaは、WorkdayからのインポートとWorkday主導のITプロビジョニングという2つの一般的なシナリオをサポートしています。

Workday主導のITプロビジョニング

ITプロビジョニングを推進するために、OktaはWorkdayと統合します。WorkdayユーザーをOktaにインポートすると、それらのユーザーは引き続きWorkdayによって管理されます。Workdayで行われた更新と終了は、Oktaとダウンストリームのアプリに反映されます。この設定により、Workdayはアプリに対する従業員と契約社員のアクセス権を管理できます。Workday主導のITプロビジョニングは、Workdayからのインポートによって提供される機能のスーパーセットです。そのため、Workday主導のITプロビジョニングの構成手順は、Workdayからのインポートのシナリオにも関連しています。

注:

Oktaは、［First Day Of Work（最初の勤務日）］および［Hire Date（雇用日）］の属性がWorkdayに入力されているユーザーのみをインポートします。
Active Directoryを使用していて、プロファイルプッシュが有効なときは、「Active Directoryのプロビジョニング設定を構成する」を参照してください。
Oktaでは、自宅（Home）と勤務先（Work）の電話タイプのみをサポートしています。Workdayインスタンスでサポートされていない電話タイプを使用する場合、インポート中に問題が発生する可能性があります。

Workday主導のITプロビジョニングにより、Oktaでは次のワーカーライフサイクルイベントがサポートされます。

新規採用
- Workdayで新しいWorkerが雇用されました
- Oktaは新しいWorkerをインポートし、Oktaユーザープロファイルを作成します。
- Oktaはダウンストリームアプリにアカウントを作成します（Active Directory（AD）を含む）。
更新内容
- Workdayユーザーの属性がWorkdayで変更される
- Oktaが属性の変更をインポートする
- Oktaがダウンストリームアプリの属性を更新する（ADを含む）
退職
- Workdayで終了したWorker
- Oktaがステータスの変更をインポートする
- OktaがダウンストリームアプリのOktaユーザーとアカウントを非アクティブ化する（ADを含む）
再雇用
- 退職したWorkerがWorkdayで再雇用される
- Oktaが再雇用されたWorkerを再アクティブ化されたOktaユーザーにインポートしてリンクする

前提条件

Oktaでプロビジョニングを構成する際は、事前に次の要件が満たされていることを確認してください。

Workdayアプリのインスタンスを追加し、SSOを設定する
Workdayで統合システムユーザーを作成する
統合システムユーザーに権限を付与する

Workdayアプリのインスタンスを追加し、SSOを設定する

WorkdayアプリインスタンスをOktaに追加して、それとWorkdayインスタンスをSSO用に構成する必要があります。「既存のアプリ統合を追加する」と「WorkdayのSAML 2.0を構成する」を参照してください。

Workdayで統合システムユーザーを作成する

Oktaは、Oktaという特別なタイプのWorkdayユーザーを使用してWorkday APIにアクセスします。このユーザーを作成するには、検索ボックスにcreate integration system userと入力し、検索結果の統合システムユーザーを作成する（Create Integration System User）をクリックします。指示に従ってユーザー名とパスワードを作成します。

統合システムパスワードを使ったWorkdayへのサインインを許可しないときは、UIセッションを許可しない（Do Not Allow UI Sessions）を選択します。

注:

WorkdayへのAPI呼び出しに使用されるアカウントはこれだけです。

統合システムユーザーに権限を付与する

Workdayセキュリティグループを通じてOkta Workday統合に必要なWebサービスにアクセスするには、統合システムユーザーに必要な権限を付与します。

管理者としてWorkdayアカウントにサインインします。すでにセキュリティグループを作成している場合は、ステップ9に進みます。まだの場合は、次のステップに進みます。
検索ボックスにcreate security group（セキュリティグループを作成する）」と入力し、検索結果のセキュリティグループを作成する（Create Security Group）をクリックします。
テナントセキュリティグループのタイプ（Type of Tenanted Security Group）（Integration System Security Group (Constrained)）ドロップダウンからIntegration System Security Group (Constrained)（統合システムセキュリティグループ（制約付き））（Integration System Security Group (Unconstrained)）またはIntegration System Security Group (Unconstrained)（統合システムセキュリティグループ（制約なし））（Type of Tenanted Security Group）を選択します。
グループの名前を入力してOKをクリックします。
統合システムユーザー（Integration System Users）のリストに統合システムユーザーを追加します。
注:
後でこのグループを編集するには、検索ボックスにこのグループの名前を入力します。
制限付きセキュリティグループを使用している場合は、そのグループに適用する必要がある組織を選択します。
アクセス権を現在の組織のみに適用するか、現在の組織とそのすべての下部組織に適用するかを選択します。
OKをクリックしてから完了（Done）をクリックします。
検索ボックスにview security groupと入力し、検索結果のセキュリティグループを表示する（View Security Group）レポートをクリックします。
セキュリティグループを検索して選択し、OKをクリックします。
アクション（Actions）（...）メニューからSecurity Group（セキュリティグループ） > セキュリティグループのドメイン権限を管理（Maintain Domain Permissions for Security Group）を選択します。
Putアクセスを許可するドメインセキュリティポリシー（Domain Security Policies permitting Put access）（Domain Security Policy permitting Put access）に次の権限を追加します。
- External Account Provisioning
- Person Data: Work Contact Information
- Worker Data: Public Worker Reports
Getアクセスを許可するドメインセキュリティポリシー（Domain Security Policies permitting Get access）（Domain Security Policy permitting Get access）に次の権限を追加します。
- External Account Provisioning
- Person Data: Work Contact Information
- Worker Data: Public Worker Reports
- Worker Data: Current Staffing Information
- Worker Data: All Positions
- Worker Data: Business Title on Worker Profile
- Manage: Location（使用不可の場合は、Worker Data: Manage Locationsを使用します）
制限付きセキュリティグループを作成する場合は、Getアクセスを許可するドメインセキュリティポリシー（Domain Security Policy permitting Get access）に以下の権限を追加します。

Worker Data: Workers
OKをクリックしてセキュリティグループのドメイン権限を更新し、完了（Done）をクリックします。

注:
Workdayで確認して、セキュリティグループに必要なすべての権限が構成されていることを確認してください。
制限なしセキュリティグループを作成する場合は、Worker Data: Workers.からすべてのユーザーを削除する必要があります。
Workdayは、セキュリティポリシーの変更をアクティブ化するように警告する場合があります。変更をアクティブ化しない場合、統合ユーザーアカウントに必要な権限が付与されません。次を実行して変更をアクティブ化します。
1. Activate Pending Security Policy Changesを検索し、結果のタスクをクリックします。
2. コメント（必須）を入力し、OKをクリックします。
3. アクティブ化する変更を確認します。

手順

Workdayプロビジョニングを設定する
Okta でWorkdayプロビジョニング機能を有効にする
Workdayプロビジョニンググループを管理する
属性をマッピング（Map Attributes）
カスタム式
Workdayのカスタム属性
Workdayフィールドの上書きサービス

Workdayプロビジョニングを設定する

Oktaで、OktaとWorkday間のAPI統合を有効化し、統合を構成します。

Admin Consoleで、アプリケーション（Applications） > アプリケーション（Applications）に移動します。
検索（Search）フィールドにWorkday統合名を入力します。それをリストから選択します。
プロビジョニング（Provisioning）タブをクリックします。
API統合の構成（Confiure API Integration）（Configure API Integration）をクリックします。
API統合を有効化（Enable API integration）を選択します。
APIユーザー名（API Username）を入力します。形式は[integration system username]@[tenant]にします。例：wd_integration@oktademo。テナント名はWorkdayのURLにあります。
APIパスワード（API Password）を入力します。これは統合システムユーザーのパスワードです。
WebServicesエンドポイント（WebServices Endpoint）を入力します。この値は以下の手順に沿ってWorkdayインスタンスから取得します。
1. Workdayで、public web services（パブリックWebサービス）」を検索します。
2. パブリックWebサービス（Public Web Services）レポートを選択します。
3. Webサービスのリストから任意のサービスのドロップダウンメニューを開き、Webサービス（Web Service） > WSDLの表示（View WSDL）を選択します。別のウィンドウでWSDLが開きます。
4. WSDLページでsoapbind:addressを検索し、選択したサービスのWebサービスエンドポイントを確認します。
5. Oktaでインスタンスを構成するには、テナント名までのURLが必要です。たとえば、WSDLウィンドウの値がis https://implcc.workday.com/ccx/service/okta_pt1/Human_Resources/v19の場合は、https://impl-cc.workday.com/ccx/service/okta_pt1の部分をコピーしてWebServicesエンドポイント（WebServices Endpoint）に貼り付けます。
任意。統合システムID（Integration System Id）を入力します。Workdayのカスタム属性を参照してください。
任意。部門フィールド（Department Field）を入力します。この値は、Oktaのユーザーの部門属性に使用するWorker属性を決定します。デフォルト値はBusiness Unitです。
任意。雇用前インターバル（Pre-Start Interval）を入力します。この値は、ワーカーの雇用日の何日前にユーザーをOktaにインポートしてアクティブ化するかを決定します。雇用前インターバル（Pre-Start Interval）を参照してください。
任意。仕事用の電話番号を使用できない場合に、OktaがWorkdayの個人用電話番号を使用できるようにするには、個人用電話番号を同期（Sync Personal Phones）を選択します。
任意。Workdayアカウントのあるワーカーのみをインポートして、持っていないワーカーを除外したい場合には、Workdayアカウントのあるワーカーのみをインポートする（Only Import Workers with Workday Accounts）を選択します。このオプションを選択すると、次回のインポートには有効なWorkdayワーカーのみが含まれます。
任意。即時終了理由（Immediate Termination Reasons）を定義する式を入力します。リアルタイム同期機能を使用している場合は、これを使用して、Workday統合IDで識別される各終了理由のTermination_Subcategory_IDを照合します。この入力値は正規表現でなければなりません。「Workday Real Time Sync」を参照してください。
任意。退職日ではなく勤務終了日にユーザーを非アクティブ化するには、勤務終了日に非アクティブ化する（Deactivate on Last Day of Work）を選択します。ユーザーの非アクティブ化は、ユーザーの勤務終了日の翌日に実行されます。
任意。ユーザーのタイムゾーンまたはロケーションの現在の時間に基づいてユーザーを非アクティブ化する場合は、タイムゾーン対応の退職（Timezone aware terminations）を選択します。「タイムゾーンに応じた非アクティブ化」を参照してください。
任意。WorkdayプロビジョニンググループをOktaにインポートするには、グループをインポートする（Import Groups）を選択します。このオプションはデフォルトで選択されています。
API資格情報をテスト（Test API Credentials）をクリックしてAPI資格情報をテストします。エラーが発生した場合は、認証情報を確認してやり直してください。
保存（Save）をクリックします。

OktaでWorkdayプロビジョニング機能を有効にする

OktaのWorkdayアプリ統合でOkta へ（To Okta）セクションを選び、Workdayをプロファイルソースとして有効にしたら、インポートルールをセットアップします。

スケジュールされたインポート
プロファイルソースとしてのWorkday
雇用前インターバル（Pre-Start Interval）

スケジュールされたインポート

プロビジョニングが有効になると、ユーザーインポートのプロビジョニングが自動的に有効になります。必要に応じてこの機能の他の設定を編集してください。

Workday主導のITプロビジョニングのシナリオでは、Workdayのワーカーライフサイクルイベントが手動介入なしで定期的にOktaへ反映されるように、スケジュールされたインポートと自動確認を設定することをお勧めします。OktaWorkdayのワーカー数によってはインポートが遅くなる可能性があります。そのため、あまり頻繁にインポートをスケジュールしないでください。

注:

Workdayとの統合では、スケジュールされたインポートの一部として増分インポートがサポートされています。詳細については、「増分インポート」を参照してください。

推奨されるベストプラクティスは、最初にユーザーを手動でインポートすることです。アプリからユーザーをインポートするを参照してください。これを行った後、手動インポートの結果に基づいてインポートをスケジュールします。インポートに時間がかかりすぎる場合は、スケジュールを調整してください。

プロファイルソースとしてのWorkday

Workday主導のITプロビジョニングのシナリオでは、WorkdayがOktaユーザーを管理できるように、Workdayをプロファイルソースとして有効にすることができます。

Oktaで、以下の手順に沿ってプロファイルソースとしてWorkdayを有効にしてください。

Workdayインスタンスのプロビジョニング（Provisioning）タブに移動して、設定（Settings）（To Okta）でOktaへ（Settings）を選択します。
プロファイルおよびライフサイクルのソーシング（Profile & Lifecycle Sourcing）セクションにある［編集（Edit）］をクリックします。
WorkdayがOktaユーザーをソースにすることを許可する（Allow Workday to source Okta users）を選択します。
保存（Save）をクリックします。
Admin Consoleでディレクトリ（Directory） > プロファイルソース（ Profile Editor）に進みます。
矢印を使って、Workdayを最も優先度の高いプロファイルソースにします。Workdayが、ユーザーが作成されているディレクトリの上位になる必要があります。たとえば、組織がActive Directory（AD）インスタンスにユーザーを作成した場合、Workdayの優先順位をADよりも高くしなければなりません。

雇用前インターバル

雇用前インターバル（Pre-Start Interval）は、Workdayユーザーを早期にプロビジョニングするための任意のフィールドです。これにより、正式な［Worker/Employee Date（ワーカー/従業員日）従業員の実際の開始日（］）よりも前にユーザーアカウントをOktaにオンボーディングできます。この間隔は、Workdayユーザーの［Worker/Employee Date（ワーカー／従業員日）］までにOktaによってユーザーの早期インポートが評価される日数を示します。この機能が有効になっている場合、OktaはWorkdayの雇用前日を評価します。雇用前日が設定された期間内にあれば、ユーザーをインポートします。Okta

Workdayインスタンスのプロビジョニング（Provisioning）（Pre-Start Interval）タブに移動して、設定（Settings）（Provisioning）の統合（Integration）で雇用前インターバル（Pre-Start Interval）（Settings）を表示します。この値を変更するには、統合（Edit）セクションの編集（Edit）（Integration）をクリックし、値を入力してから、保存（Save）をクリックします。

次の例で考えてみましょう。たとえば、Oktaで雇用前インターバルを7日に設定し、Workdayアカウントの雇用前日（PreHire Date）が［Worker/Employee Date（ワーカー/従業員日）］の7日前に設定されている場合、Oktaはアカウントをインポートします。この同じシナリオで、雇用前日（PreHire Date）がOktaで構成された7日間よりも大きい場合、Oktaは雇用前インターバルで定義された期間が開始されるまでインポート対象とは見なしません。

次の点に注意してください。

雇用前インターバル（Pre-Start Interval）をゼロ以外に設定すると、指定した日数分前に、将来の日付のWorkdayユーザー更新がインポートされます。たとえば、Workdayプロビジョニンググループメンバーシップの変更がスケジュールされており、その変更が2日後に有効になるとします。雇用前インターバル（Pre-Start Interval）の値が［3］に設定されている場合、この変更は次回のインポートのすぐ後にOktaに反映されます。
カスタムレポートを介してインポートされた終了日および属性値では、雇用前インターバル（Pre-Start Interval）は無視されます。新規雇用者の雇用前インターバル（Pre-Start Interval）を設定する必要があるものの、他の更新を事前に行いたくない場合があります。これを達成するには、OktaのWorkdayプロファイルの基本属性を使用するのではなく、カスタムレポートから属性を作成してOktaにインポートします。また、Oktaでのグループ割り当てに、カスタムレポート属性に基づくグループメンバーシップルールを使用することもできます。
雇用前インターバル（Pre-Start Interval）オプションを使用するには、［Profile Sourcing（プロファイルソーシング］を有効にする必要があります。
インターバルをオンボーディングに必要な時間に設定します。
インターバルは、ユーザーが実際の開始日の前にインポートの対象になる日時を定義します。ユーザーをインポートする日時は定義しません。

Workdayプロビジョニンググループを管理する

Workdayプロビジョニンググループを使用すると、ワーカーを体系的にOktaにインポートできます。Active Directoryセキュリティグループと同様に、インポートされたWorkdayプロビジョニンググループはディレクトリ（Directory） > グループ（Group）の下に表示されます。これらのグループは、他のOktaグループと同様に、アプリの割り当てや多要素認証（MFA）ポリシーの割り当てに使用します。このグループを使用して、Active Directoryやその他のアプリケーションへのプロビジョニングを推進することもできます。プロビジョニンググループはWorkday内で手動で作成します。作成されると、グループと関連するメンバーシップがOktaへのインポートの一部になります。

Workday管理者にプロビジョニンググループ管理者権限を付与する
プロビジョニンググループにWorkday Workerを割り当てる
プロビジョニンググループを使用してActive Directoryへユーザーをプロビジョニングする
プロビジョニンググループを変更する
考慮事項

Workday管理者にプロビジョニンググループ管理者権限を付与する

Workday管理者がプロビジョニンググループを管理する前に、適切な権限があることを確認する必要があります。プロビジョニンググループを検索したときに、プロビジョニンググループを作成、削除、または編集するオプションが表示されない場合は、管理者に必要な権限がありません。

プロビジョニンググループへのアクセスを追加するには、次の手順を実行します。

管理者としてWorkdayアカウントにサインインします。
検索（Search）バーにdomain securityと入力し、職務領域のドメインセキュリティポリシー（Domain Security Policies for Functional Area）を選択します。
Systemと入力してOKをクリックします。
左ペインで、下にスクロールしてセキュリティ管理（Security Administration）フォルダを展開します。プロビジョニンググループ管理（Provisioning Group Acministration）（Provisioning Group Administration）をクリックします。
右ペインのプロビジョニングニンググループ管理（［Provisioning Group Administration）］の横にある省略記号をクリックしてドロップダウンを表示し、ドメインセキュリティポリシー（Domain Security Policy）を選択します。
- 2番目の項目に有効化（Enable）と表示されている場合は、ポリシーが無効になっていることを意味します。これを有効にするには、有効化（Enable）をクリックして選択内容を確認します。
- 2番目の項目に無効化（Disable）と表示されている場合は、ポリシーが有効になっていることを意味します。次の手順に進みます。
レポート/タスク権限（Report/Task Permissions）リストで、管理者が表示および変更権限を持つセキュリティグループのメンバーであることを確認します。そうでない場合は、ドメインセキュリティポリシー（Domain Security Policy）の横のドロップダウンメニューをクリックします。ドメインセキュリティポリシー（Domain Security Policy） > 権限の編集（Edit Permissions）を選択してから、正しいセキュリティグループをリストに追加します。表示権限と変更権限の両方が設定されていることを確認してください。

プロビジョニンググループにWorkday Workerを割り当てる

Workdayの従業員は、Workday内のプロビジョニンググループに手動で割り当てることができます。ただし、プロビジョニンググループは、Workday内のビジネスプロセスで定義された条件付きルールに基づいて自動割り当てを行うように構成されている場合に最も効果的です。Workday内のビジネスプロセスを変更する必要があるため、WorkdayのHR管理者がこの手順を実行する必要があります。詳細については、Workdayサポートにお問い合わせください。

プロビジョニンググループを使用してActive Directoryへユーザーをプロビジョニングする

Oktaを使用すると、WorkdayからActive Directory（AD）へのユーザーの作成、更新、非アクティブ化を自動化できます。Oktaは、Workdayプロビジョニンググループを介してプロビジョニングを推進します。つまり、WorkdayプロビジョニンググループはOkta内の1つ（または複数）のAD Organization単位（OU）に関連付けられています。Workdayでユーザーが作成され、適切に構成されたプロビジョニンググループに割り当てられると、OktaによってWorkdayからそのユーザーがインポートされ、対応するOUの下にADにユーザーが作成されます。

注:

ユーザーは、ロケーションのタイムゾーンに基づいて非アクティブ化されることもあります。詳細については、「タイムゾーンに応じた非アクティブ化」を参照してください。

プロビジョニンググループを使用してユーザーをADにプロビジョニングするには：

Oktaにサインインします。
ディレクトリ（Directory） > グループ（Groups）で目的のWorkdayプロビジョニンググループを探します。
グループをクリックします。
ディレクトリを管理（Manage Directories）をクリックします。
Workdayプロビジョニンググループに関連付けるADドメインを選択します。
アカウントをプロビジョニングするAD OUを選択します。
完了（Done）をクリックします。
Okta AD設定タブで、Oktaを有効にします。

プロビジョニンググループを変更する

既存のWorkerがWorkdayの別のプロビジョニンググループに追加されると、Oktaの関連グループのメンバーシップが変更されます。ただし、関連付けられたADユーザーのOUの場所は変更されません。これは、ADユーザーの作成時にのみADユーザーが追加され、更新は適用されないためです。Okta

考慮事項

グループの追加：新しく作成されたWorkdayのグループは、次のシナリオでのみOktaに同期されます。

フルインポート：新しいWorkdayプロビジョニンググループを取り込み、Oktaで作成します
増分インポート：新しいWorkdayプロビジョニンググループを取り込み、Oktaで作成します
RTS：Workdayプロビジョニンググループを作成しただけでは、Oktaでグループを作成するためのRTSイベントはトリガーされません。ただし、WorkdayプロビジョニンググループがWorkdayで作成されると、トリガーされる他のRTSイベントにもグループ情報が含まれ、Oktaで新しいグループが作成されます。

グループの削除：Workdayから削除されたグループは、フルインポートによってのみOktaから削除されます。

フルインポート：これにより、存在しないWorkdayグループにリンクされているグループがOktaから削除されます。
増分インポートとRTSは、削除されたWorkdayグループをOktaから削除しません。

グループ名の変更：Workday内でグループ名が変更されると、Oktaで次の動作が発生します。

RTSイベントはWorkdayグループ名の変更を取得し、この新しい名前をOkta内の新しい別のグループとしてOktaに書き込みます。
RTSでは、グループのメンバーが更新されると、そのユーザーはOktaの元のグループから削除され、新しいグループに追加されます。ユーザーは元のグループで割り当てられていたアプリをすべて失います。
（新しい名前の）Workdayプロビジョニンググループに新規ユーザーを追加すると、そのグループがOktaに書き込まれます。このユーザーにアプリが割り当てられたり、このユーザーのアプリが削除されたりすることはありません。これは、Oktaの（新しい名前の）グループにアプリが割り当てられていないためです。
増分インポートを実行した場合、結果は上記のRTSのシナリオと同じになります。（古い名前の）グループは削除されません。前回のインポートから更新されたユーザーは、元のグループから新しい名前のグループに移動します。その結果、アプリの割り当てまたはプロビジョニングが解除されます。
フルインポートが実行されると、（古い名前の）グループは削除されます。そして、グループのすべてのメンバーについて、関連するアプリの割り当てまたはプロビジョニングが解除されます。（新しい名前の）グループがインポートされ、関連するユーザーがそのグループに追加されます。新しいグループに関連付けられているアプリはありません。

注:

Workdayでグループの名前を変更する必要がある場合は、代わりに新しい名前を使用する別のグループを作成してください。

Workdayグループの名前を変更すると、Oktaのダウンストリームで望ましくない動作が発生する可能性があります。この問題を回避するには、Workdayで目的の名前のグループを作成し、ユーザーをそのグループに割り当てます。インポートまたはRTSジョブがOktaにグループを作成するのを待ちます。

新しく作成したグループがOktaに取り込まれたら、名前を変更したいグループと同じように構成します。両方のグループのユーザーメンバーシップ、グループルール、およびアプリ割り当てが同じであることを確認します。これにより、フルインポートを実行して（元の名前の）古いグループをWorkdayから安全に削除し、Oktaを更新することができます。

すべてのユーザー、ルール、およびアプリケーションの割り当てが新しいグループに複製されているため、アプリケーションまたは割り当てへのアクセスを失うことはありません。

属性をマッピング

WorkdayからOktaユーザープロファイルに属性をマッピングする
ADユーザープロファイルへの属性のマッピング

WorkdayからOktaユーザープロファイルに属性をマッピングする

Okta Universal Directory（UD）Profile Editorに示されているように、OktaがWorkdayからインポートする基本プロファイルは20個の属性で構成されています。WorkdayユーザーからOktaユーザーへの属性マッピングにはデフォルトで存在するものもありますが、手動で作成する必要があるものもあります。

注:

WorkdayがADに書き込むように構成されている（およびUDが有効の）場合、Okta管理者はいくつかの属性を手動でマップする必要があります。これには、WorkdayアプリのユーザープロファイルとOktaのユーザープロファイル間、そしてOktaのユーザープロファイルとADのユーザープロファイル間のマッピングが含まれます。これらのマッピングにより、属性がWorkdayからOkta、さらにADに送られるようになります。

以下の表は、一般的なユースケースで推奨されるマッピングを示しています。

Workday	Okta
`appuser.accountType`	`userType`
`appuser.businessTitle`	`title`
`appuser.businessUnit`	`department`
`appuser.city`	`city`
`appuser.countryCode`	`countryCode`
`appuser.email`	`email`
`appuser.employeeID`	`employeeNumber`
`appuser.firstName`	`firstName`ǂ
`appuser.lastName`	`lastName`ǂ
`appuser.location`	`locale`
`appuser.managerId`	`managerId`
`appuser.managerUserName`	`manager`
`appuser.mobilePhone`	`mobilePhone`
`appuser.postalCode`	`zipCode`
`appuser.secondEmail`	`secondEmail`ϕ
`appuser.state`	`state`
`appuser.streetAddress`	`streetAddress`
`appuser.supervisoryOrg`	`organization`
`appuser.workPhone`	`primaryPhone`

ǂappuser.firstNameとappuser.lastNameの値は、Workdayのユーザーの希望呼称から取得されます。希望呼称が使用できない場合は、ユーザーの正式名称データが使用されます。希望呼称も正式名称も使用できない場合は、フィールドに合わせてFirstNameまたはLastNameに設定されます。

ϕ Oktaでは、secondEmailの値をインポートまたは設定しません。カスタム属性を使用して、Workdayからこの値を取得できます。Workdayのカスタム属性を参照してください。

ADユーザープロファイルへの属性のマッピング

Workday-as-a-Sourceには通常、ADユーザーの作成が含まれます。OktaユーザーからADユーザーへの属性マッピングには、デフォルトで存在するものもありますが、手動で作成する必要があるものもあります。以下の表は、一般的なユースケースで推奨されるマッピングを示しています。

Okta	Active Directory
`user.email`	`email`
`user.firstName`	`firstName`
`user.lastName`	`lastName`
`hasWorkdayUser() ? (findWorkdayUser().managerUserName + "@" + target_app.namingContext) : null`	`managerUpn`
`substringBefore(user.login, "@")`	`samAccountName`
`user.streetAddress`	`streetAddress`
`user.middleName`	`middleName`
`hasWorkdayUser() ? findWorkdayUser().employeeID : user.employeeNumber`	`employeeID`
`hasWorkdayUser() ? findWorkdayUser().supervisoryOrg : user.department`	`department`
`user.honorificPrefix`	`honorificPrefix`
`user.state`	`state`
`user.countryCode`	`countryCode`
`user.preferredLanguage`	`preferredLanguage`
`user.city`	`city`
`hasWorkdayUser() ? findWorkdayUser().businessTitle : user.title`	`title`
`user.zipCode`	`postalCode`
`user.division`	`division`
`user.mobilePhone`	`mobilePhone`
`hasWorkdayUser() ? findWorkdayUser().businessUnit : user.costCenter`	`departmentNumber`
`hasWorkdayUser() ? findWorkdayUser().location : null`	`deliveryOffice`
`user.primaryPhone`	`telephoneNumber`
`hasWorkdayUser() ? findWorkdayUser().employeeID : user.employeeNumber`	`employeeNumber`
`user.honorificSuffix`	`honorificSuffix`

カスタム式

UDは、上の表のように、属性を変換するためのプロファイルマッピングでのカスタム式の使用をサポートしています。

ADのマネージャーのリンクに重要なManager（UPN）属性のカスタム式を検討してください。

hasWorkdayUser()?(findWorkdayUser().managerUserName + "@" + target_app.namingContext):null

この式は、このOktaユーザーにWorkdayプロファイルが存在するかどうかを確認します。存在する場合は、OktaにインポートされたWorkdayプロファイルのmanagerUserName属性を見つけ、@[AD domain]を追加して、Manager（UPN）属性が入力されます。

Oktaはマネージャー（Manager） (UPN)（Manager (UPN)）属性を使用してADでOktaユーザーのマネージャーを見つけ、2つのADユーザーをリンクします。このカスタム式は、特殊なAD環境に合わせて変更できます。

他の2つの状況では、プロビジョニングからADへのプロファイルマッピングに追加のカスタム式が表示される可能性があります。1つ目は、既存のWorkday-as-a-SourceデプロイでUDが有効になっている場合です。2つ目は、Workday統合がADの前にOktaに追加されたときです。どちらの場合も、役職、場所、監督組織、事業単位、従業員IDのWorkday属性は、カスタム式を介して対応するAD属性に直接マッピングされます。

Workdayのカスタム属性

カスタム属性は、フィールドの上書きを使用してインポートできます。WorkdayからOktaにカスタム属性をインポートするにはフィールドの上書き統合システムが必要です。これについてはWorkdayフィールドの上書きサービスで説明されています。

古いインスタンスでは、カスタムレポートエンドポイントを使用して属性をインポートできます。この機能は廃止されました。既存のカスタムレポート構成は影響を受けませんが、新しいアプリインスタンスではフィールドの上書きを使用する必要があります。カスタムレポートを使用してWorkdayから属性をインポートするインスタンスがある場合は、カスタムレポートを使用したインポートを参照してください。

注:

Oktaは、受信するAPIペイロード（XMLやJSONなど）を一切保管しません。

Workdayフィールドの上書きサービス

Workdayのフィールドの上書きサービスは、Workdayからカスタム属性情報を取得する方法の1つです。

フィールドの上書きサービスを使用すると、インポートプロセスが簡素化され、カスタムレポートの使用などの以前の方法と比べてパフォーマンスが向上します。

構成（Configuration）
フィールドの上書きのプロパティタイプ
Okta でフィールドの上書きを使用するようにWorkdayを構成する

構成

フィールドの上書きを使用するには、Workdayの管理者がWorkday内にフィールドオーバーライド統合システムを作成する必要があります。そして、目的のカスタム属性をシステムに追加し、ワーカーデータを取得する際にフィールドの上書きを使用するようOktaを構成します。

以下の手順でフィールドオーバーライド統合を作成します。

管理者としてWorkdayアカウントにサインインし、検索バーでIntegration Systemを検索して、統合システムの作成（Create Integration System）をクリックします。
以下を入力します。
- システム名（System Name）：システム統合の名前を入力します。
- コメント（Comment）：オプションでコメントを追加します。
- テンプレート（Template）：テンプレートを使用して新規作成（New using template）（Core Connector: Worker）ドロップダウンメニューからコアコネクター：ワーカー（Core Connector: Worker）（New using template）を選択します。
OKをクリックします。
結果の一覧からコアコネクター：ワーカー（［Core Connector:Worker）（Core Connector: Worker）を選び、OK（OK.）をクリックします。
統合サービスを構成（Configure Integration Services）ページで、下にスクロールしてカスタム統合サービス（Custom Integration Services）セクションに移動し、+（プラス）記号をクリックします。
作成（Create）をクリックします。
サービスのリストから統合フィールドの上書きサービスを作成（「Create Integration Field Override Service）」を選択します。
フィールドの上書きサービスの名前（Name）を入力し、ビジネスオブジェクト（Business Object）としてWorker（ワーカー）を選択します。
注:
プロパティタイプはプロパティ名に基づきます。プレフィックスを使用してフィールドのタイプを指定しない限り、すべてのフィールドが文字列として扱われます。プロパティタイプと命名規則の詳細については、フィールドの上書きのプロパティタイプを参照してください。
OKをクリックして統合システムを作成を完了します。
OKをクリックして統合システムを表示（View Integration System）ページに戻ります。
システムのフィールドマッピングを構成します。アクション（Actions） > 統合システム（Integration System） > 統合フィールドの上書きを設定（Configure Integration Field Overrides）に移動します。
左側のリストから統合サービス（Integration Service）を選択し、フィールドのマッピングを構成します。目的のフィールドを検索し、プロパティタイプが一致することを確認します。
プロパティをマッピングしたら、OKをクリックして完了（Done）（Done.）をクリックします。
Workdayで統合システムを検索し、アクション（Actions） > 統合ID（Integration IDs） > IDを表示（View IDs）に移動します。
Integration_System_IDの値をコピーして保存します。この値はプロビジョニング設定のセットアップおよび更新に必要です。

フィールドの上書きのプロパティタイプ

フィールドの上書きでは、統合システムのセットアップから属性タイプを取得できません。これは、すべてのカスタムプロパティが文字列として扱われることを意味します。そこで、Oktaがカスタムプロパティを別のタイプ（たとえば、ブール値や数値）として扱うように設定することをお勧めします。これには、統合システムでマッピングを構成する際に、プロパティ名にプレフィックスを追加する必要があります。Oktaはこのプレフィックスを検出し、プロパティタイプに変換してからプレフィックスを削除します（つまり、このプレフィックスはOktaプロファイルエディターには表示されません）。

Oktaがフィールドの上書きのタイプを優先するように設定するには、次のようにプロパティタイプとプロパティ名をコロンで区切って名前を付けます：

<property_type>:<property_name>

たとえば、homePhoneNumberを文字列として扱うようにするには、フィールドの上書き名をstring:homePhoneNumberに設定します。

サポートされているタイプは、文字列、ブール値、整数、数値、および10進数です。

次の表は、プロパティ名がどのように変換されるかを示しています。

Workdayフィールド上書き名	Oktaのプロパティタイプ	Oktaの変換されたプロパティ名	コメント（Comment）
`string:my_awesome_string_property`	文字列（string）	`my_awesome_string_property`	Oktaはこのプロパティを文字列としてインポートします。Oktaは、プロファイルエディターで`my_awesome_string_property`という文字列タイプのカスタムプロパティを作成します。
`boolean:boolean_property`	ブール値	`boolean_property`	Oktaはこのプロパティをブール値としてインポートします。Oktaは、プロファイルエディターで`boolean_property`というブール値タイプのカスタムプロパティを作成します。
`string_by_default`	文字列（string）	`string_by_default`	タイプが指定されていないため、Oktaはこのプロパティを文字列としてインポートします。つまり、デフォルトでは文字列です。Oktaは、プロファイルエディターで`string_by_default`という文字列タイプのカスタムプロパティを作成します。
`not_a_type:property_name`	文字列（string）	`property_name`	デフォルトでは、タイプが既知のタイプと一致しないため、Oktaはこのプロパティを文字列としてインポートします。Oktaは、プロファイルエディターで`property_name`という文字列タイプのカスタムプロパティを作成します。
`integer:integer_property`	整数	`integer_property`	Oktaはこのプロパティを整数としてインポートします。Oktaは、プロファイルエディターで`integer_property`という整数タイプのカスタムプロパティを作成します。
`decimal:decimal_property`	10進数	`decimal_property`	Oktaはこのプロパティを10進数としてインポートします。Oktaは、プロファイルエディターで`decimal_property`という10進数タイプのカスタムプロパティを作成します。
`number:number_property`	数値	`number_property`	Oktaはこのプロパティを数値としてインポートします。Oktaは、プロファイルエディターで`number_property`という数値タイプのカスタムプロパティを作成します。

Oktaでフィールドの上書きを使用するようにWorkdayを構成する

Admin Consoleで、アプリケーション（Applications） > アプリケーション（Applications）に移動します。
Workdayアプリインスタンスを検索して選択します。
プロビジョニング（Provisioning） > 統合（Integration）に進みます。
統合（Edit）セクションの編集（Edit）（Integration）をクリックします。先ほどコピーしたIntegration_System_IDの値を統合システムID（Integration System Id）に貼り付けます。保存（Save）をクリックします。
Admin Consoleでディレクトリ（Directory） > プロファイルソース（ Profile Editor）に進みます。
Workdayアプリインスタンスを見つけて選択します。
属性を追加（Add Attribute）をクリックします。統合システムの新しいプロパティが属性のリストに表示されているかどうかを確認します。表示されていない場合は、属性リストを更新（Refresh Attribute List）をクリックして、追加したい属性を選択します。保存（Save）をクリックします。
プロファイルエディター（Profile Editor）で、マッピング（Mappings）をクリックして属性をマッピングします。

既知の制限

Oktaで、Workdayからインポートしたアラビア文字が正しく表示されない。
カスタム属性をWorkdayで削除してからOktaにインポートしても、以前にインポートしたカスタム属性の値が消去されない。

Workdayへのプロファイル（電話デバイスの値）の更新中に次のエラーメッセージが表示される場合：

これは、WorkdayテナントがカスタムのPhone_Device_Type_Id値で構成されていることを意味します。Workdayで構成された工場出荷時のデフォルト値を使用するように、次のようにリセットしてください。

名前（Name）	値
携帯電話番号（MOBILE）	Mobile
ファクス（FAX）	Fax
電話（Telephone）	Telephone
ページャー（PAGER）	Pager

機能

契約社員から正社員への変換

Workdayの契約社員から正社員への変換サポートを使用するには、Workdayテナントの設定を変更して、ワーカーのユニバーサルIDを構成する必要があります。構成が完了すると、ユニバーサルIDがテナントの新しく作成されたワーカーにのみ適用されます。ユニバーサルIDを既存のワーカーに適用するには、WorkdayのAPIを使用して手動でワーカーのWorkdayプロファイルを更新します。ユニバーサルIDがないと、Oktaは契約社員が正社員に変わったことを検出できません。これにより、ワーカーの重複が発生する可能性があります。
WorkdayからOktaへのユニバーサルIDのマッピングは任意であり、この機能を動作させる上で必須ではありません。

ユニバーサルID

Workday側では、契約社員ワーカーと正社員ワーカーは別個のエンティティであり、別個のWorkday IDを持ちます。これらのIDは、Workdayで両方に同じセカンダリIDを設定することでリンクできます。このセカンダリIDがユニバーサルIDです。

注:

Workdayプロビジョニング統合で雇用前インターバルが構成されていて、ユニバーサルIDが構成されていない場合、Oktaは契約社員ワーカーと将来の正社員ユーザー（雇用前）の両方を取り込みます。その結果、Oktaのインポート（Import）タブに重複したエントリが作成されます。これは、Workdayの2人のワーカーが異なるWorkday IDを持っており、それらが同じユーザーであることをOktaが検出できないために発生します。

WorkdayでユニバーサルIDを構成すると、Oktaの契約社員から正社員への変換機能が重複するワーカーの作成を防ぎます。この機能は、受信する雇用前ワーカーに、既存のアクティブなワーカーと同じユニバーサルIDがないかどうかを検出します。既存のワーカーと一致する雇用前ワーカーは除外され、重複するエントリが作成されることを防ぎます。

契約社員ワーカーが非アクティブ化され、Workdayからのインポートが実行されると、契約社員はもう使用できないため、ユニバーサルIDが一致する正社員ユーザーが選択されます。変換後、Oktaユーザーは一度非アクティブ化されてから再びアクティブ化されます。これによりOktaでは、実質的に、契約社員ワーカーが退職し、正社員ワーカーが雇用された形になります。

この変換を自動で実行するためには、以下の手順でWorkdayアプリ統合を構成します。

Admin Consoleで、アプリケーション（Applications） > アプリケーション（Applications）に移動します。
Workdayアプリインスタンスを検索して選択します。
プロビジョニング（Provisioning） > Oktaへ（To Okta）に移動します。
ユーザー作成と照合（User Creation & Matching）セクションにある編集（Edit）をクリックします。
一致したユーザーを確認（Confirm matched users）（Auto-confirm exact matches）で完全一致を自動確認（Auto-confirm exact matches）（Confirm matched users）を選択します。
新しいユーザーを確認（Confirm new users）（Auto-confirm new users）で新しいユーザーを自動確認（Auto-confirm new users）（Confirm new users）を選択します。
保存（Save）をクリックします。
プロファイルおよびライフサイクルのソーシング（Profile & Lifecycle Sourcing）セクションにある編集（Edit）をクリックします。
任意。ユーザーがアプリで再アクティブ化されている場合（Reactivate suspended Okta users）で一時停止されたOktaユーザーを再度有効にする（Reactivate suspended Okta users）（When a user is reactivated in the app）を選択します。このオプションを選択するかどうかは設定に応じて決まります。
ユーザーがアプリで再アクティブ化されている場合（Reactivate deactivated Okta users）で非アクティブ化されたOktaユーザーを再度有効にする（Reactivate deactivated Okta users）（When a user is reactivated in the app）を選択します。
保存（Save）をクリックします。

契約社員ユーザーの非アクティブ化と正社員ユーザーの再アクティブ化の間にギャップが生じることがあります。これは、Workdayのユーザーの退職日および雇用日のタイムゾーンと、Workdayテナントが動作しているタイムゾーンが違うことに起因していることがよくあります。現在、Oktaはタイムゾーンに応じた退職のみをサポートしています。新規雇用をインポートするときにタイムゾーンは考慮されません。

この機能性によって、契約社員としてのワーカーの退職日と、正社員としての同ユーザーの雇用日が異なるケースに対応することができます。たとえば、契約社員が正社員に変わり、新しい職位での仕事が始まる前に1週間の休暇を取るような場合です。正社員ワーカーは、実際の勤務開始日までインポートされません。

WorkdayテナントのユニバーサルIDの構成方法は、Workdayのコミュニティアカウントを使って以下の記事にアクセスし、参照してください。

非アクティブ化

Oktaはインポート中に非アクティブ化を実行します。この際、過去24時間に退職したワーカーと今後24時間以内に退職するワーカーがいるかどうかが確認されます。これらに該当するワーカーは、以下の条件のうち最初に一致する条件に基づいて非アクティブ化されます。

即時非アクティブ化：ワーカーの終了理由がOkta内で構成された即時終了理由の1つと一致する場合、そのワーカーは即時に非アクティブ化されます。
タイムゾーンを考慮した非アクティブ化：退職理由が一致しない場合、従業員の退職日／最終勤務日が現在の時刻と比較されます。Oktaでは、非アクティブ化時間が経過したかどうかを判断する際に、Workdayが指定するタイムゾーンの退職日に依拠します。通常、Workdayは終了日を午前0時（PST）として返します。現在の時刻がその日付よりも後の場合、ワーカーは非アクティブ化されます。

退職日が将来であり、即時退職理由が一致するワーカーは、1日早く退職となります。たとえば、退職日が2022/10/22のユーザーが2022/10/21（現在の日付）の時点で即時退職理由に該当した状況を考えてみます。この場合、ユーザーは退職日より1日早い2022/10/21のインポート時に退職となります。
タイムゾーン対応の非アクティブ化が有効になっていない限り、Workerは引き続き午前0時（UTC）にのみ終了します。

回避策については、「タイムゾーンに応じた非アクティブ化」を参照してください。

即時非アクティブ化の理由

Oktaは通常、その日の終わりまで待機して、Workdayで退職したワーカーを処理します。この処理には、Workdayアプリからの割り当て解除や非アクティブ化が含まれます。またOktaは、Workdayからイベントを受信した直後に退職を処理することもできます。これは、ワーカーの退職理由が指定されている即時退職理由に該当し、かつ退職日が現在の日付であるときに発生します。

即時非アクティブ化の理由を構成する

Oktaで、Workdayアプリのプロビジョニング（Provisioning）タブを選択します。
Workdayの説明に従って、即時退職理を必要な退職サブカテゴリとともに入力します。Workdayで、Integration IDsを検索してから、退職サブカテゴリ（Termination Subcategory）ビジネスオブジェクトを検索して選択することで、すべての退職サブカテゴリを列挙できます。退職理由は、その退職サブカテゴリとそれに対応するIDの組み合わせです（Terminate_Employee_Involuntary_RIFなど）。これらの即時非アクティブ化の理由を定義する際には、正規表現を使用して指定することもできます。

OR（|）演算子を使用して複数の非アクティブ化の理由を列挙できます。次の正規表現は、考えられる即時非アクティブ化の理由を複数定義します。ここでは、退職理由が以下のいずれかに該当するすべての非アクティブワーカーが直ちにWorkdayアプリから割り当て解除され、Oktaで非アクティブ化されます。
```
Terminate_Employee_Voluntary_DissatisfiedPay|
Terminate_Employee_Involuntary_Harassment|
Terminate_EmployeeImmediateTerm_ImmediateTerm|
Terminate_Employee_Voluntary_Commute
```
^.*<TerminationReason>$を使用して、指定した式で終了する退職理由に一致させます。たとえば、次の式は、DissatisfiedPayで終わるすべての理由に一致します。
```
^.*DissatisfiedPay$
```
^<TerminationReason>.*を使用して、指定した式で始まる退職理由に一致させます。たとえば、次の式は、Terminate_Employee_Voluntaryで始まるすべての理由に一致します。
```
^Terminate_Employee_Voluntary.*
```
次の例に示すように、これらの方法を組み合わせて使用します。
```
^.*DissatisfiedPay$|^.*Involuntary_Harassment$|
^.*ImmediateTerm$|^Terminate_Employee_Voluntary.*
```
これらの式を作成するときは注意し、適切なワーカーにのみ適用され、それ以外のワーカーには適用されないようにしてください。

注：

このテキストボックスにデフォルト値を設定することはできません。
Workdayの理由（Reason）および2つ目の理由（Secondary Reasons）で退職理由を選択します。

以下のチャートは、終了変数に基づくさまざまな結果を示しています。

即時退職理由が一致しますか？	雇用終了日を使用しますか？	結果
		ワーカーは退職日の後に非アクティブ化される
	●	ワーカーは雇用終了日の後に非アクティブ化される
●		ワーカーは退職日の開始時に実行されるインポート中に非アクティブ化される
●	●	ワーカーは雇用終了日の開始時に実行されるインポート中に非アクティブ化される

タイムゾーン対応の退職

ワーカーの退職日が、アカウントを非アクティブ化する標準的な時刻と合致するとは限りません。Workday統合は、Workdayに定義されているタイムゾーンに基づくワーカーの非アクティブ化に対応しています。

この機能を有効にするには、プロビジョニング（Provisioning）（Timezone aware terminations）タブでタイムゾーン対応の退職（Timezone aware terminations）（Provisioning）を選択します。セキュリティグループにロケーションを管理する権限が必要です。統合システムユーザーに権限を付与するを参照してください。

注:

タイムゾーンに基づくワーカーの再アクティブ化には対応していません。

ワーカーの退職予定日は、ワーカーの退職日（Termination Date）または勤務終了日（Last Day of Work）によって決まります。Oktaはワーカーの位置を検出し、その位置に関連するタイムゾーンに基づいて、予定された退職手続きを処理します。このワーカーは、ワーカーのタイムゾーンで午前0時以降に予定されているインポート時に非アクティブ化されます。

ワーカーがWorkdayで優先タイムゾーンを設定している場合、検出された場所のタイムゾーンよりも設定されたタイムゾーンが優先されます。ワーカーのタイムゾーンを決定する際の優先順位は次のとおりです。

ワーカーの優先タイムゾーン
ワーカーのロケーションのタイムゾーン
太平洋標準時（PST）

たとえば、オーストラリアのシドニーに拠点を置くキャシーにとって、WorkdayでのタイムゾーンはGMT+10となります。

キャシーの退職日は7月4日です。タイムゾーン対応の退職（Timezone aware terminations）が無効になっている場合、キャシーの退職は、UTC午前0時以降の最初のインポートで処理されます。これは、すべての非アクティブ化がUTCタイムゾーン（GMT+0）で固定されているためです。逆に、タイムゾーン対応の退職（Timezone aware terminations）が有効になっている場合には、シドニー時間（GMT+10）で午前0時以降の最初のインポートでOktaで非アクティブ化されます。実質的には、キャシーは、この機能の有効化前に非アクティブ化されるはずだった時刻の10時間前に非アクティブ化されます。