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（プロビジョニング）］タブに移動します。［To Okta（Oktaへ）］セクションにある一般領域で［Edit（編集）］をクリックし、［Incremental Import Schedule（増分インポートスケジュール）］と［Full Import Schedule（フルインポートスケジュール）］のドロップダウンリストでインポートの頻度を設定します。

フルインポート

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

増分インポート

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

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

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

これらのインポートタイプを最適に設定することで、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のプロビジョニング設定を構成する」を参照してください。

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ユーザーをOktaで手動で再アクティブ化する
- Oktaが再雇用されたWorkerを再アクティブ化されたOktaユーザーにインポートしてリンクする

前提条件

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

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

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

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

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

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

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

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 (Unconstrained)（統合システムセキュリティグループ（制約なし））］を選択します。
グループの名前を入力して［OK］をクリックします。
［統合システムユーザー］のリストに統合システムユーザーを追加します。
後でこのグループを編集するには、検索ボックスにこのグループの名前を入力します。
制限付きセキュリティグループを使用している場合は、そのグループに適用する必要がある組織を選択します。
アクセス権を現在の組織のみに適用するか、現在の組織とそのすべての下部組織に適用するかを選択します。
［OK］をクリックしてから［Done（完了）］をクリックします。
検索ボックスに「セキュリティグループを表示する」と入力し、検索結果の［View Security Group（セキュリティグループを表示する）］レポートをクリックします。
セキュリティグループを検索して選択し、［OK］をクリックします。
［Actions（アクション）（...）］メニューから［Security Group（セキュリティグループ）］［Maintain Domain Permissions for Security Group（セキュリティグループのドメイン権限を管理）］を選択します。
［Domain Security Policies permitting Put access（Putアクセスを許可するドメインセキュリティポリシー）］に次の権限を追加します。
- External Account Provisioning（外部アカウントのプロビジョニング）
- Person Data（人物データ）：Work Contact Information（仕事の連絡先情報）
- Worker Data（Workerデータ）：Public Worker Reports（パブリックWorkerレポート）
［Domain Security Policies permitting Get access（Getアクセスを許可するドメインセキュリティポリシー）］に次の権限を追加します。
- External Account Provisioning（外部アカウントのプロビジョニング）
- Person Data（人物データ）：Work Contact Information（仕事の連絡先情報）
- Worker Data（Workerデータ）：Public Worker Reports（パブリックWorkerレポート）
- Worker Data（Workerデータ）：Current Staffing Information（現在の職員配置情報）
- Worker Data（Workerデータ）：All Positions（全職位）
- Worker Data（Workerデータ）：Business Title on Worker Profile（Workerプロファイルの肩書）
- Manage（管理）：Location（ロケーション）（使用不可の場合は、Worker Data（Workerデータ）：Manage Locations（ロケーションの管理）を使用します）
制限付きセキュリティグループを作成する場合は、［Domain Security Policy permitting Get access（Getアクセスを許可するドメインセキュリティポリシー）］に以下の権限を追加します。
- Worker Data（Workerデータ）：Workers（職員）
［OK］をクリックしてセキュリティグループのドメイン権限を更新し、［Done（完了）］をクリックします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

雇用前インターバル

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

Workdayインスタンスの［Provisioning（プロビジョニング）］タブに移動して、［Settings（設定）］の［Integration（統合）］で［Pre-Start Interval（雇用前インターバル）］を表示します。この値を変更するには、統合セクションの［Edit（編集）］をクリックし、値を入力してから、［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（プロビジョニングニンググループ管理）］の横にある省略記号をクリックしてドロップダウンを表示し、［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設定タブで、［Provision new Active Directory accounts from Okta（Oktaから新しいActive Directoryアカウントをプロビジョニング）］を有効にします。

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

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

考慮事項

グループの追加：新しく作成された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に設定されます。

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)属性を使用して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つです。

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

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

構成

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

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

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

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

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

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

<property_type>:<property_name>

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

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

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

Workdayフィールド上書き名	Oktaのプロパティタイプ	Oktaの変換されたプロパティ名	コメント
string:my_awesome_string_property	文字列	my_awesome_string_property	Oktaはこのプロパティを文字列としてインポートします。Oktaは、プロファイルエディターでmy_awesome_string_propertyという文字列タイプのカスタムプロパティを作成します。
boolean:boolean_property	ブール値	boolean_property	Oktaはこのプロパティをブール値としてインポートします。Oktaは、プロファイルエディターでboolean_propertyというブール値タイプのカスタムプロパティを作成します。
string_by_default	文字列	string_by_default	タイプが指定されていないため、Oktaはこのプロパティを文字列としてインポートします。つまり、デフォルトでは文字列です。Oktaは、プロファイルエディターでstring_by_defaultという文字列タイプのカスタムプロパティを作成します。
not_a_type:property_name	文字列	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（編集）］をクリックします。先ほどコピーした［Integration_System_ID］の値を［Integration System Id（統合システムID）］に貼り付けます。［Save（保存）］をクリックします。
Admin Consoleで［Directory（ディレクトリ）］［Profile Editor（プロファイルエディター）］に移動します。
Workdayアプリインスタンスを見つけて選択します。
［Add Attribute（属性を追加）］をクリックします。統合システムの新しいプロパティが属性のリストに表示されているかどうかを確認します。表示されていない場合は、［Refresh Attribute List（属性リストを更新）］をクリックして、追加したい属性を選択します。［Save（保存）］をクリックします。
プロファイルエディターで、［Mappings（マッピング）］をクリックして属性をマッピングします。

既知の制限

Oktaで、Workdayからインポートしたアラビア文字が正しく表示されない。
カスタム属性をWorkdayで削除してからOktaにインポートしても、以前にインポートしたカスタム属性の値が消去されない。
Workdayへのプロファイル（電話デバイスの値）の更新中に次のエラーメッセージが表示される場合：
これは、WorkdayテナントがカスタムのPhone_Device_Type_Id値で構成されていることを意味します。Workdayで構成された工場出荷時のデフォルト値を使用するように、次のようにリセットしてください。
Name（名前） Value (値)
MOBILE（携帯電話番号） Mobile
FAX（ファクス） Fax
Telephone（電話） Telephone
PAGER（ページャー） Pager

Name（名前）	Value (値)
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（プロビジョニング）］［To Okta（Oktaへ）］に移動します。
［User Creation & Matching（ユーザー作成・照合）］の［Edit（編集）］をクリックします。
［Confirm matched users（一致したユーザーを確認）］で［Auto-confirm exact matches（完全一致を自動確認）］を選択します。
［Confirm new users（新しいユーザーを確認）］で［Auto-confirm new users（新しいユーザーを自動確認）］を選択します。
［Save（保存）］をクリックします。
プロファイルおよびライフサイクルのソーシングセクションで［Edit（編集）］をクリックします。
任意。ユーザーがアプリで再アクティブ化されている場合で［Reactivate suspended Okta users（一時停止されたOktaユーザーを再度有効にする）］を選択します。このオプションを選択するかどうかは設定に応じて決まります。
ユーザーがアプリで再アクティブ化されている場合で［Reactivate deactivated Okta users（非アクティブ化されたOktaユーザーを再度有効にする）］を選択します。
［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で、統合IDを検索してから、［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（理由）］および［Secondary Reasons（2つ目の理由）］で退職理由を選択します。

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

採用前の間隔を設定しますか？	即時退職理由が一致しますか？	雇用終了日を使用しますか？	結果
			ワーカーは退職日の後に非アクティブ化される
		●	ワーカーは勤務終了日の後に非アクティブ化される
	●		ワーカーは退職日の1日前に非アクティブ化される
	●	●	ワーカーは退職日の1日前に非アクティブ化される
●			ワーカーは退職日の後に非アクティブ化される
●		●	ワーカーは勤務終了日の後に非アクティブ化される
●	●		ワーカーは退職日の後に非アクティブ化される
●	●	●	ワーカーは勤務終了日の後に非アクティブ化される

タイムゾーン対応の退職

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

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

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

ワーカーの退職予定日は、ワーカーの［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時間前に非アクティブ化されます。