Workday

Oktaでは、標準のAPIを通じてWorkdayからユーザーやグループをインポートできます。3種類のインポートに対応しています。

フルインポート

フルインポートでは、すべてのワーカー、すべての基本属性とカスタム属性がインポートされます。フルインポートは時間がかかるものの、2つのシステム間の調整を行うため、また他のインポートタイプではサポートされていない属性を取り込むためにスケジュール設定する必要があります。通常、このタスクは週に1回実行されます。フルインポートには、基本属性、未来（または非未来）の有効期限付きカスタム属性が含まれています。また、増分インポートやリアルタイム同期インポートでは省略される変更も含まれています。

増分インポート

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

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

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

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

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

Workdayからのインポート

WorkdayからOktaへのインポートにはユーザーとグループが含まれます。インポートされたWorkdayユーザーはOktaユーザーの作成に使用され、インポートされたWorkdayグループはアプリの割り当てに使用できます。Workdayでは、Oktaにインポートされたユーザーはもう管理されません。Workdayでユーザーを更新しても、関連付けられているOktaユーザーは変更されません。

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

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

  • OktaはWorkdayに［First Day Of Work（最初の勤務日）］および［Hire Date（雇用日）］の属性またはフィールドが入力されているユーザーのみをインポートします。

  • Active Directoryを使用していて、プロファイルプッシュが有効になっている場合は、「Active Directoryのプロビジョニング設定を構成する」を参照してください。

Workday主導のITプロビジョニングにより、Oktaは以下のワーカーライフサイクルイベントをサポートします。

  • 新規採用

    • Workdayで新しいWorkerが雇用されました
    • Oktaは新しいWorkerをインポートし、Oktaユーザープロファイルを作成します。
    • Oktaがダウンストリームのアプリでアカウントを作成（ADを含む）

  • アップデート

    • Workdayユーザーの属性がWorkdayで変更される
    • Oktaが属性の変更をインポートする
    • Oktaがダウンストリームアプリの属性を更新する（ADを含む）

  • 退職

    • Workdayで終了したWorker
    • Oktaによってステータスの変更がインポートされる
    • OktaがダウンストリームアプリのOktaユーザーとアカウントを非アクティブ化する（ADを含む）

  • 再雇用

    • 退職したWorkdayがWorkdayで再雇用される
    • 非アクティブ化されたOktaユーザーはOktaで手動で再アクティブ化する必要があります
    • Oktaが再雇用されたWorkerを再アクティブ化されたOktaユーザーにインポートして再リンクします

前提条件

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

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

OktaへのWorkdayアプリインスタンスの追加とSSOの構成はすでに済んでいます。「WorkdayでのSAML 2.0の構成方法」を参照してください。

アプリケーションの追加に関する一般的な情報については、「既存のアプリ統合の追加」を参照してください。

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

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

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

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

  1. セキュリティグループを作成するには、検索ボックスに「create security group（セキュリティグループの作成）」と入力します。
  2. 検索結果で［Create Security Group（セキュリティグループを作成）］をクリックします。
  3. ［In the Type of Tenanted Security Group（テナントセキュリティグループのタイプ）］ドロップダウンから［Integration System Security Group (Unconstrained)（統合システムセキュリティグループ（制約なし））］を選択します。
  4. グループの名前を入力します。
  5. 次のページで、［Integration System Users（統合システムユーザー）］のリストに統合システムのユーザーを追加します。後で編集するためにこのグループに戻るには、検索ボックスにセキュリティグループ名を入力します。
  6. Oktaと統合するには、セキュリティグループに以下のビジネスドメインへの適切なアクセス権が必要です。
    • External Account Provisioning（権限：Get and Put）
    • Worker Data: Public Worker Reports（権限：Get and Put）
    • Worker Data: Work Contact Information（権限：Get and Put）
    • Worker Data: Current Staffing Information（権限：Get）
    • Worker Data: All Positions（権限：Get）
    • Worker Data: Business Title on Worker Profile（権限：Get）
  7. 各ビジネスドメインに正しい統合権限を設定します。
    1. 検索ボックスに「Domain Security Configuration（ドメインセキュリティ構成）」と入力します。
    2. 結果のレポートをクリックします。
    3. 検索フィールドにビジネスドメイン名を入力し、［OK］をクリックします。
    4. ドメイン名の横にあるドロップダウンメニューから［Domain（ドメイン）］>［Edit Security Policy Permissions（セキュリティポリシー権限を編集）］を選択します。
    5. ［Integrated Permissions（統合権限）］の該当するセクションにセキュリティグループを追加します。ビジネスドメインに必要な権限（GetまたはGet and Put）を使用して、グループを配置する場所を決定します。

      6. Workdayで確認して、セキュリティグループに必要なすべての権限が構成されていることを確認してください。

  8. Workdayは、セキュリティポリシーの変更をアクティブ化するように警告する場合があります。変更がアクティブ化されない場合、統合ユーザーアカウントに必要な権限はありません。
  9. 次の手順を実行して、変更をアクティブ化します。
    1. 「Activate Pending Security Policy Changes（保留中のセキュリティポリシーの変更のアクティブ化）」を検索します。
    2. 結果のタスクをクリックします。
    3. コメント（必須）を入力し、［OK］をクリックします。
    4. アクティブ化が必要な変更を確認します。

手順

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

API統合をセットアップするには、WorkdayインスタンスのOkta の［Provisioning（プロビジョニング）］タブに移動します。

［Enable API Integration（API統合を有効にする）］を選択し、必要に応じてその他のフィールドを構成します。

注： ［API Username（APIユーザー名）］、［API Password（APIパスワード）］、および［WebServices Endpoint（WebServicesエンドポイント）］の値を構成する必要があります。残りの設定は任意です。

  • ［API Username（APIユーザー名）］：フォーマットは「［統合システムのユーザー名］@［テナント］」です。例：wd_integration@oktademo。テナント名はWorkdayのURLにあります。
  • ［API Password（APIパスワード）］：上記で使用した統合システムユーザーのパスワード。
  • ［WebServices Endpoint（WebServicesエンドポイント）］：テナント名はWorkdayのURLにあります。Webサービスのエンドポイントを取得するには、org内の任意のWebサービスのWSDLを次のように検索します。
    1. 「public web services（パブリックWebサービス）」を検索します。
    2. ［Reports（レポート）］で、［Public Web Services（パブリックWebサービス）］を選択します。
    3. ［Public Web Services（パブリックWebサービス）］リストで、サービスを選択してそのドロップダウンメニューを開き、［Web Services（Webサービス）］>［View WSDL（WSDLを表示）］を選択します。別のウィンドウに完全なWSDLが表示されます。
    4. WSDLページで「soapbind:address」を検索し、選択したWebサービスに対応する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」と入力します。
  • ［Integration System Id（統合システムID）］（オプション）：「Workdayのカスタム属性」を参照してください。
  • ［Department Field（部門フィールド）］（オプション）：この値は、Oktaのユーザーの部門属性に使用するWorker属性を決定します。デフォルトの値は「Business Unit（事業単位）」です。
  • ［Pre-Start Interval（雇用前インターバル）］（オプション）：この値は、雇用日の何日前にユーザーをインポートしてOktaでアクティブ化する必要があるかを決定します。詳細については、「雇用前インターバルの詳細」を参照してください。
  • ［Sync Personal Phones（私用電話を同期）］（オプション）：このオプションを使用すると、別の方法で勤務先の電話番号を使用できない場合に、Workdayからアクセスされる個人用電話番号を使用できます。
  • ［Only Import Workers with Workday（Workdayのワーカーのみをインポート）］（オプション）：このオプションを使用すると、Workdayアカウントを持つWorkdayワーカーのみをインポートし、持っていないワーカーを自動的に除外できます。このオプションをクリックすると、次回のインポートには有効なWorkdayワーカーのみが含まれます。
  • ［Immediate Termination Reasons（即時終了理由）］（オプション）：リアルタイム同期機能を使用している場合は、このテキストボックスを使用して、Workday統合IDで識別される各終了理由のTermination_Subcategory_IDを照合します。このフィールドは正規表現でなければなりません。「Workday Real Time Sync」を参照してください。
  • ［Deactivate on Last Day of Work（最終勤務日に非アクティブ化）］（オプション）：このオプションを使用すると、終了日ではなく最終勤務日に基づいてユーザーを非アクティブ化できます。ユーザーの非アクティブ化は、最終勤務日が現在の日付と一致すると実行されます。
  • ［Timezone aware terminatons（タイム・ゾーンに対応した終了）］（オプション）：このオプションを使用すると、タイム・ゾーンまたは場所での現在の時刻に基づいてユーザーを非アクティブ化できます。詳細については、「タイムゾーンに応じた非アクティブ化」を参照してください。

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

左側のパネルで［To Okta（Oktaへ）］を選択し、プロファイルソースを有効にして、インポートルールを設定します。

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

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

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

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

最初にユーザーを手動でインポートすることをお勧めします。次に、インポート結果に従ってインポートをスケジュールします。インポートに時間がかかりすぎる場合は、スケジュールを調整してください。

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

プロファイルソースとしてのWorkdayでも、WorkdayがOktaユーザーを管理できるように、Workday主導のITプロビジョニングシナリオを有効にする必要があります。特にWorkdayは、ユーザーを作成するActive Directory（AD）インスタンスの上に、最も優先度の高いプロファイルソースとしてリストされている必要があります。

雇用前インターバルの詳細

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

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

以下に留意してください。

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

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

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

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

Workday管理者がプロビジョニンググループを管理する前に、適切な権限があることを確認する必要があります。検索バーに「provisioning groups（プロビジョニンググループ）」と入力したときに、［Create Provisioning Groups（プロビジョニンググループを作成）］、［Delete Provisioning Groups（プロビジョニンググループを削除）］、または［Edit Provisioning Groups（プロビジョニンググループを編集）］のオプションが表示されない場合は、管理者に必要な権限がないことを示しています。

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

  1. 検索バーに「domain security」（ドメインセキュリティ）と入力し、［Domain Security Policies for Functional Area（職務領域のドメインセキュリティポリシー）］を選択します。
  2. 「System」と入力し、［OK］をクリックします。
  3. 左ペインで、下にスクロールして［Security Administration（セキュリティ管理）］フォルダを展開します。［Provisioning Group Acministration（プロビジョニンググループ管理）］をクリックします。
  4. 右ペインの［Provisioning Group Administration（プロビジョニンググループ管理）］の横にある省略記号をクリックしてドロップダウンメニューを表示し、［Domain Security Policy（ドメインセキュリティポリシー）］を選択します。
    • 2番目の項目に［Enable（有効化）］と表示されている場合は、ポリシーが現在無効になっていることを意味します。有効にするには、［Enable（有効化）］をクリックします。選択すると確認ボックスが表示されます。
    • 2番目の項目に［Disable（無効化）］と表示されている場合は、ポリシーが現在有効になっていることを意味します。次の手順に進みます。
  5. ［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にプロビジョニングするには：

  1. Oktaにサインインします。
  2. ［People（ユーザー）］>［Groups（グループ）］で目的のWorkdayプロビジョニンググループを探します。
  3. グループをクリックします。
  4. ［Manage Directories（ディレクトリを管理）］をクリックします。
  5. Workdayプロビジョニンググループに関連付けるADドメインを選択します。
  6. アカウントをプロビジョニングするAD OUを選択します。
  7. ［Done（完了）］をクリックします。
  8. 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の元のグループ（古い名前）から削除され、新しく作成されたOktaグループ（新しい名前）に追加されます。そのユーザーが元のグループ（古い名前）からアプリケーションの割り当てを取得していた場合、それらは失われます。
  • RTSでは、Workdayプロビジョニンググループ（新しい名前）に新規ユーザーを追加すると、グループ（新しい名前）がOktaに書き込まれますが、この新しいユーザーがアプリケーションに割り当てられたり、1つ目は、Oktaの（新しい名前の）グループにアプリケーションが関連付けられていないためです。
  • 増分インポートを実行した場合、結果は上記のRTSのシナリオと同じになります。（古い名前の）グループは削除されませんが、最後のインポート以降に更新されたユーザーは（古い名前の）グループから（新しい名前の）グループに移動されるため、アプリケーションの割り当てが解除されるか、プロビジョニングします。
  • フルインポートを実行すると、（古い名前の）グループが削除され、それに応じてそのグループの全員が関連付けられているアプリからデプロビジョニングされます。（新しい名前の）グループがインポートされ、関連するユーザーがすべて（新しい名前の）グループに追加され、アプリは関連付けられません。

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

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

新しく作成したグループがOktaに取り込まれたら、名前を変更したいグループとまったく同じように設定します。すべてのユーザーメンバーシップ、グループルール、および/またはアプリケーションの割り当てが、目的の名前の新しいグループと古いグループの間で同じになったら、Workdayから元のグループを削除し、フルインポートを実行してOktaを更新することで、古いグループを削除できます。

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

属性をマッピング

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

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

Workday

Okta
appuser.accountType userType
appuser.businessTitle 役職
appuser.businessUnit 部門
appuser.city 市町村
appuser.countryCode countryCode
appuser.email メール
appuser.employeeID employeeNumber
appuser.firstName firstName
appuser.lastName lastName
appuser.location ロケール
appuser.managerId managerId
appuser.managerUserName マネージャー
appuser.mobilePhone mobilePhone
appuser.postalCode zipCode
appuser.secondEmail secondEmail
appuser.state 都道府県
appuser.streetAddress streetAddress
appuser.supervisoryOrg Organization
appuser.workPhone primaryPhone

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

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

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

Okta

Active Directory
user.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 部門
user.honorificPrefix honorificPrefix

user.state

都道府県

user.countryCode

countryCode

user.preferredLanguage

preferredLanguage

user.city

市町村
hasWorkdayUser() ? findWorkdayUser().businessTitle : user.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は、属性を変換するためのプロファイルマッピングでのカスタム式の使用をサポートしています。上の表のように、カスタム式を使用してSAMアカウント名とマネージャー（UPN）を入力します。

マネージャー（UPN）属性は、ADでマネージャーをリンクするために重要です。Manager（UPN）の完全なカスタム式は次のとおりです。

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

カスタム式は、次のアクションでトリガーされます。このOktaユーザーにWorkdayプロファイルが存在する場合、OktaにインポートされたWorkdayプロファイルのmanagerUserName属性を見つけ、@［AD domain（ADドメイン）］を追加してマネージャー（UPN）属性を入力します。

Oktaはマネージャー（UPN）属性を使用して、このOktaユーザーのマネージャーであるAD内のActive Directoryユーザーを見つけ、2人のADユーザーを結び付けます。このカスタム式を変更して、特別なAD環境に合わせてManager（UPN）属性を異なる方法で構築できます。

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

Workdayのカスタム属性

カスタム属性は、以下で説明するフィールドの上書き機能を利用してインポートできます。

個別のカスタムレポートエンドポイントを介して属性をインポートする機能は廃止されています。既存のカスタムレポート構成は機能しますが、新しいアプリインスタンスにはこれらの構成オプションがありません。

Workdayフィールドの上書き

フィールドの上書きは、既存のカスタムレポート機能に代わる、Workdayからカスタム属性情報をプルする方法です。

カスタム属性は現在、上記のカスタムレポートとともにインポートされるカスタム属性に関するで説明されているように、個別のカスタムレポートエンドポイントを介してインポートされます。コネクターは、ユーザーの完全なプロファイルを作成するために、2つの別々のエンドポイントを処理し、両方からのデータをマージする必要があるため、これによりインポートが複雑になります。カスタムレポートは、特に大量のデータを扱う場合には、Workdayでは推奨されません。カスタムレポートの制限に対応するため、WorkdayはField Overridesを介してこれらのカスタム属性を取得するためのサポートをプライマリAPIに導入しました。

フィールドの上書きを使用すると、インポートプロセスが簡素化され、パフォーマンスが向上します。

構成

フィールドの上書きを使用するには、Workdayの管理者がWorkday内で新しいフィールドの上書き統合システムを作成し、必要なカスタム属性を追加して、ワーカーデータを取得するときにこの統合システムを使用するように構成する必要があります。これらの手順について以下に説明します。

フィールド上書き統合を作成

  1. 管理者としてWorkdayアカウントにログインし、検索バーでIntegration System（統合システム）を検索して、［Create Integration System（統合システムの作成）］をクリックします。
  2. 以下を入力します。
    • ［System Name（システム名）］：システム統合の名前を入力します。
    • ［Comment（コメント）］：オプションでコメントを追加します。
    • ［Template（テンプレート）］：［New using template（テンプレートを使用して新規作成）］ドロップダウンメニューからワーカーを選択します。
  3. Enterキーを押します。
  4. 結果のリストから［Core Connector：Worker（コアコネクター：ワーカー）］を選択し、［OK］をクリックします。
  5. 新しく作成した統合システムのページにリダイレクトされます。
  6. 下にスクロールして［Custom Integration Services（カスタム統合サービス）］セクションに移動し、+（プラス）記号をクリックします。
  7. ［Create（作成）］をクリックします。
  8. サービスのリストから「統合フィールドの上書きサービスを作成」 を選択します。
  9. フィールド上書きサービスの名前を入力し、ビジネスオブジェクトとして［Worker］を選択します。
  10. +（プラス）記号をクリックして、Field Override Serviceにフィールドを追加します。プロパティーのタイプはプロパティー名に基づいています。異なるタイプのプロパティーが必要な場合は、「フィールドの上書き」プロパティーのタイプと命名規則の詳細を参照してください。続けて、［OK］をクリックします。
  11. 統合サービスが作成されたので、フィールドのマッピングを構成する必要があります。［Actions（アクション）］>［Integration System（統合システム）］>［Configure Integration Field Overrides（統合フィールドの上書きを設定）］に移動します。
  12. 左側のリストから統合サービスを選択し、フィールドのマッピングを構成します。目的のフィールドを入力して検索します。プロパティーのタイプが一致していることを確認してください。
  13. すべてのプロパティーをマッピングした後、［OK］を選択してから、［Done（完了）］をクリックします。
  14. Workdayで統合システムを検索し、［Actions（アクション）］>［Integration IDs（統合ID）］>［View IDs（IDビュー）］に移動します。
  15. プロビジョニング設定のセットアップ/更新に必要なIntegration_System_IDの値をコピーして保存します。

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

カスタムレポートを使用するのとは異なり、フィールドの上書きでは統合システムの設定から属性タイプを取得することはできません。これは、すべてのカスタムプロパティーが文字列として扱われることを意味します。Oktaでカスタムプロパティーを別のタイプ（ブール値または数値）として扱う場合は、追加の手順でプロパティー名にプレフィックスを追加する必要があります（手順9）。このプレフィックスはOktaによって検出され、Profile Editorに変換され、後で削除されます（つまり、OktaのProfile Editorには表示されません）。

［Field Override（フィールドの上書き）］でタイプを優先させるには、プロパティータイプとプロパティー名をコロンで区切って、「<property_type>:<property_name>」のように名前を付けます。例：string:homePhoneNumber

サポートされているタイプは次のとおりです。

  • 文字列
  • ブール値
  • 整数
  • 数値
  • 10進数

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

Workdayフィールド上書き名 Oktaのプロパティタイプ Okta変換されたプロパティ名 コメント
string:my_awesome_string_property 文字列 my_awesome_string_property Oktaはこのプロパティを文字列としてインポートし、名前my_awesome_string_propertyおよびstringタイプでProfile Editorにカスタムプロパティを作成します
boolean:boolean_property ブール値 boolean_property Oktaはこのプロパティをブール値としてインポートし、Profile Editorに名前boolean_property、タイプbooleanのカスタムプロパティを作成します。
string_by_default 文字列 string_by_default Oktaでは、タイプが指定されていないため、このプロパティはstringとしてインポートされます。つまり、デフォルトではstringです。Oktaは、Profile Editorでname string_by_defaultを使用してカスタムプロパティおよびタイプstringを作成します。
not_a_type:property_name 文字列 not_a_type:property_name タイプは既知のタイプと一致しないため、Oktaはこのプロパティーをstringとしてインポートします。これは、デフォルトでstringであることを意味します。Oktaによって、Profile Editorに名前がnot_a_type:property_name、タイプがstringのカスタムプロパティが作成されます。プロパティーの接頭辞は既知の型ではないため、削除されません
integer:integer_property 整数 integer_property Oktaではこのプロパティーをintegerとしてインポートし、Profile Editorに名前integer_property、タイプintegerのカスタムプロパティーを作成します。
decimal:decimal_property 10進数 decimal_property Oktaでは、このプロパティをdecimalとしてインポートし、Profile Editorに名前decimal_propertyおよびタイプdecimalのカスタムプロパティーを作成します。
number:number_property 数値 number_property Oktaはこのプロパティを数値としてインポートし、名前number_propertyとタイプnumberのカスタムプロパティをProfile Editorに作成します

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

  1. Oktaで［Applications（アプリケーション）］を選択し、Workdayアプリインスタンスを探して選択してから、［Provisioning（プロビジョニング）］>［Integration（統合）］をクリックします。新しい構成プロパティーIntegration System Idが表示されます。
  2. ［Edit（編集）］をクリックし、上記の手順15で取得した統合システムのIDを貼り付けて、［Save（保存）］をクリックします。
  3. Profile Editorに移動し、Workdayアプリケーションを選択して、統合システムの新しいプロパティーが属性のリストに表示されているかどうかを確認します。

カスタムレポートとともにインポートされたカスタム属性

この機能は廃止されました。既存のカスタムレポート構成は機能しますが、新しいアプリインスタンスにはこれらの構成オプションがありません。

属性のリストを含むカスタムWorkdayレポートを作成する必要があります。Oktaでこれらの属性をインポートすると、UDによってユーザープロファイルとダウンストリームのアプリのユーザープロファイルにマッピングされます。

Workdayでのカスタムレポートの作成

Workdayへのサインイン

  1. カスタムレポートの作成を検索し、結果のタスクを選択してください。
  2. 以下のフィールドに入力します。
    • ［Report Name（レポート名）］フィールドでレポート名を作成します。
    • ［Report Type（レポートタイプ）］として［Advanced（詳細設定）］を選択すると、［Web Service Enable（Webサービスを有効化）］チェックボックスに表示されます。
    • ［Web Service Enable（Webサービスを有効化）］チェックボックスをオンにします。
    • ［OK］をクリックします。
  3. 必要な属性をカスタムレポートに追加します。
  4. インポートされた属性の名前を変更する場合は、［Column Heading Override XML Alias（列見出しXMLエイリアスの上書き）］列を変更します。

    • カスタムレポートにWorkday ID属性を追加します。

      ［Column Heading Override XML Alias（列見出しXMLエイリアスの上書き）］をWorkday_IDに変更します。

      Workday_IDがないと、Oktaでカスタム属性が正常にインポートされません。

  5. 新しいカスタムレポートを作成した後、レポート名の後の省略記号をクリックして［Web Service（Webサービス）］>［View Urls（Urlの表示）］に移動します。
  6. リンクを右クリックし、［Copy URL（URLをコピー）］を選択して次のURLを取得します。
    1. XSD（Simple XMLの見出しの下）
    2. JSON（JSONの見出しの下）
  7. カスタムレポートを統合ユーザーと共有します。
    1. カスタムレポートを編集を検索します。
    2. カスタムレポートを見つけます。
    3. ［Share（共有）］タブ>［Share（共有）］を選択し、特定の認可されたグループおよびユーザーと共有します。
    4. 統合ユーザーを選択します。

カスタムレポートのインポート時間の最適化

多数のユーザーが多数のカスタム属性（特に計算フィールド）を持つ場合、Oktaへのインポートに時間がかかる可能性があります。数時間かかることもあります。また、カスタムレポートが正しくフォーマットされていることを検証するためにOktaがインポートするため、プロビジョニング設定の保存に時間がかかる場合があります。

Oktaで完全な統合を設定せずにインポートを実行するのにかかるおおよその時間を知るには、Webブラウザーで、またはPostmanなどのツールを使用してWorkdayカスタムレポートJSON URLを開きます。ここで、workday管理者の認証情報を入力するように求められます。

まれに、インポートの実行に2時間以上かかる場合がありますが、Oktaサービスによって開いている接続がタイムアウトになります。この場合は、Oktaサポートに連絡して、接続タイムアウト期間を2時間以上に延長するように要求してください。

ページ分割されたカスタムレポートの使用（推奨）

まれに、ページ番号の付いたカスタムレポートの設定が役立つ場合があります。ページネーションとは、すべてのユーザーに対して1回の呼び出しを行うのではなく、ユーザーごとの呼び出しを行って特定のユーザーのカスタムレポートをプルすることを意味します。

2時間以上かかるインポートに対応するために2時間の接続タイムアウト制限を延長できない場合は、ページネーションはユーザーごとに個別に呼び出しを行います。ただし、全体のインポート時間は大幅に増加します。

ページネーションされたカスタムレポートを使用すると、検証で1人のユーザーのカスタムレポートをチェックするだけなので、プロビジョニング設定を保存した後の遅延時間を短縮できます。ただし、これはインポート時間が長くなるため、設定を頻繁に変更しない場合にのみ役立ちます。

Oktaは、ほとんどのユースケースでページ分割されていないレポートを使用することをお勧めします。

ページネーションされたWorkdayカスタムレポートの作成

orgのユーザーが5000人未満の場合は適用されません。

カスタムレポートを使用したWorkdayからのインポートは、ユーザーが5000人を超えるとタイムアウトする可能性があります。これを解決するには、Oktaがタイムアウトすることなく一連のWorkerデータをインポートできるように、ページ番号が付けられたカスタムレポートを作成します。このオプションを使用するには、次の手順を実行します。

  1. ［Filter（フィルター）］タブで、フィルターを設定します。

    2. workday7-1.png

  2. ［Prompts（プロンプト）］タブで、プロンプトのデフォルト値を指定します。

    3. workday_new_1.png

  3. 統合ユーザー（推奨）またはレポートの所有者である管理者のWorkday IDを検索します。なお、レポートの所有者が統合ユーザー以外の場合は、統合ユーザーと共有する必要があります。
  4. ［Actions（アクション）］>［Web Service（Webサービス）］>［View URLs（URLを表示）］をクリックして、生成されたURLを表示します。
  5. Employee_ID_Promptフィールドに、上記のステップ3で確認したWorkday IDを入力します。

    6. アクティブな管理者をデプロビジョニングしたり削除したりしないでください。この場合、新しい管理者のWorkday IDを入力してURLを再生成する必要があります。

  6. リンクを右クリックして［Copy URL（URLをコピー）］を選択し、新しくページ番号が付けられたURLを取得します。
    1. XSD（Simple XMLの見出しの下）
    2. JSON（JSONの見出しの下）
  7. 新しいURLを追加して、以前と同じようにレポートを生成します。
  8. Oktaで、Workdayアプリを開き、［Provisioning（プロビジョニング）］タブに移動します。
  9. 手順6a（上記）のURLを［Custom Report Simple XML XSD URL（カスタムレポートシンプルXML XSD URL）］フィールド（オプション）に貼り付けます。OktaはXSD URLを使用してカスタムレポートのスキーマを取得します。
  10. 手順6b（上記）のURLを［Custom Report JSON URL（カスタムレポートJSON URL）］フィールド（オプション）に貼り付けます。OktaはJSON URLを使用してカスタムレポートのデータを取得します。

    11. Oktaでは、カスタムレポートWebサービスエンドポイントを介してWorkdayから任意の属性をインポートできるようになりました。最後の手順では、Workdayアプリのユーザープロファイル、Oktaアプリのユーザープロファイル、およびオプションでADユーザープロファイルを新しい属性で拡張し、必要に応じてプロファイル間で属性をマッピングすることで変換を適用します。

    「プロファイルを管理する」を参照してください。

既知の制限

  • Oktaで、Workdayからインポートしたアラビア文字が正しく表示されません。
  • Workdayでカスタム属性を削除してからOktaにインポートしても、以前にインポートしたカスタム属性の値は消去されません。
  • Workdayへのプロファイルの更新（電話デバイスの値）中に次のエラーメッセージが表示される場合：

workday_prov_1.png

その後、WorkdayテナントはカスタムPhone_Device_Type_Id値で構成されます。Workdayで構成された工場出荷時のデフォルト値を使用するには、次のようにリセットする必要があります。

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

機能

請負業者から正社員への変換

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

ユニバーサルID

ユニバーサルIDとは？

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

ユニバーサルIDが必要な理由

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

仕組み

契約社員から正社員への変換機能の一部として、WorkdayでユニバーサルIDが構成されている場合、Oktaは、現在アクティブな既存のワーカーと同じユニバーサルIDを持つ、雇用前として取り込まれるワーカーがいるかどうかを検出します。そのような雇用前がある場合、それらは、同じユニバーサルIDを持つ既存のワーカーが存在する間、除外されます。

契約社員ワーカーが非アクティブ化され、Workdayからのインポートが実行されている場合、契約社員はもう選択肢ではないため、正社員ユーザーが選択されます。

変換時に、Oktaユーザーは非アクティブ化されてから再度アクティブ化されます。これは予想される動作であり、Oktaの観点からすれば、契約社員ワーカーが退職し、新しい正社員ワーカーが雇用されたということになります。

これは、契約社員ワーカーが退職し、正社員ユーザーの雇用日が同じ日ではないというケースをサポートするために実装されました。

例：契約社員が正社員に変更されましたが、正社員ワーカーとしての開始日の前に1週間休みたいと考えていました。正社員ワーカーは、実際の開始日までインポートされません。

変換が自動的に機能するようにするには、次のように、［ProvisioningTo Okta（Oktaへのプロビジョニング）］タブで構成オプションの最小セットを有効にする必要があります。

［User Creation & Matching（ユーザーの作成・照合）］：

完全一致を自動確認

新しいユーザーを自動確認

［Profile & Lifecycle Sourcing（プロファイルおよびライフサイクルのソーシング）］：

［Reactivate suspended Okta users（一時停止しているOktaユーザーを再アクティブ化）］（オプション。設定によって異なります）

［Reactivate deactivated Okta user（非アクティブ化されているOktaユーザーを再アクティブ化）］

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

WorkdayテナントのユニバーサルIDの構成方法に関する詳細については、以下を参照してください（これらの記事にアクセスするにはWorkdayコミュニティアカウントが必要です）。

非アクティブ化

インポート中（スケジュール済み・RTS・増分）、Oktaはクエリを実行して、過去24時間に終了したワーカー、または今後24時間以内に終了するワーカーがいないかどうかを判断します。このカテゴリーに該当するワーカーには、以下のルールが適用されます。

  • 即時非アクティブ化の理由：ワーカーの終了理由がOkta内で構成された即時終了理由の1つと一致する場合、そのワーカーは即時に非アクティブ化されます。

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

  • 退職日が将来であり、即時退職理由が一致するワーカーは、1日早く解雇されます。たとえば、退職日が2022年10月22日、現在の日付が2022年10月21日で、即時退職理由が一致する場合、油は退職日の1日前である2022年10月21日のインポートの一部として解雇されます。

  • タイムゾーン対応の非アクティブ化が有効になっていない限り、Workerは引き続き午前0時にのみ終了します。

即時非アクティブ化

デフォルトでは、Oktaはその日の終わりまで待機して、Workdayで終了したWorkerに対してアクションを実行します。このようなアクションには、Workdayアプリからの割り当て解除や非アクティブ化が含まれます。ただし、Workerの終了理由が即時退職理由で指定されたものと一致し、退職日が現在の日付に設定されている場合、OktaはWorkdayからのイベントを受信した直後にアクションを実行します。

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

  1. Oktaで、Workdayアプリの［Provisioning（プロビジョニング）］タブを選択します。

  2. Workdayの説明に従って、［Immediate Termination Reasons（即時退職理由）］を必要な退職サブカテゴリーとともに入力します。

    正規表現を使用して非アクティブ化の理由を指定することもできます。

    正規表現の例：

    複数の非アクティブ化理由を一覧表示するには、パイプ（|）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つ目の理由）］で選択されています：

  • 各退職理由を識別するTermination_Subcategory_IDsは、Workday：Integration IDで以下を検索し、ビジネスオブジェクトを選択することで見つけることができます：Terminationsubcategory：

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

採用前の間隔を設定しますか？

即時退職理由が一致しますか？

雇用終了日を使用しますか？

結果

退職日が経過すると、ワーカーは非アクティブ化されます

●

雇用終了日が過ぎた後、ワーカーは非アクティブ化されます

●

ワーカーは、退職日の1日前が経過すると非アクティブ化されます

●

●

ワーカーは、退職日の1日前が経過すると非アクティブ化されます

●

退職日が経過すると、ワーカーは非アクティブ化されます

●

●

雇用終了日が過ぎた後、ワーカーは非アクティブ化されます

●

●

退職日が経過すると、ワーカーは非アクティブ化されます

●

●

●

雇用終了日が過ぎた後、ワーカーは非アクティブ化されます

タイムゾーンに応じた非アクティブ化

Workdayの統合では、Workdayの勤務地のタイムゾーンに基づいて従業員の退職が処理されるタイムゾーンに応じた非アクティブ化がサポートされるようになりました。

この機能はすべてのWorkdayアプリケーションで使用でき、［Provisioning（プロビジョニング）］タブの［Timezone aware terminations（タイムゾーン対応の終了）］をチェックすることで有効にできます。

制限：タイムゾーンに応じた再アクティブ化は現在サポートされていません。

タイムゾーンに応じた非アクティブ化機能を正常に動作させるには、以下に記載されているシステムユーザーまたはシステムグループの統合に必要な追加権限を付与し、以下の説明に従ってそれらの権限をアクティブ化する必要があります。

ドメインセキュリティポリシーのアクセス許可。

  • 次のドメインについては、「統合システムユーザーに権限を付与する」手順のa～e（手順7の一部）に従います。
    • 「ワーカーデータ：ロケーションの管理」
    • ［Worker Data：Manage Location（ワーカーデータ：ロケーションの管理）］が利用できない場合は、［Manage: Location（管理：ロケーション）］を使用してください。

Oktaはワーカーの位置を検出し、その位置に関連するタイムゾーンに基づいて（終了日または雇用終了日）、予定された退職手続きを処理します。このワーカーは、ワーカーのタイムゾーンで深夜0時が過ぎた後に予定されているインポート時に非アクティブ化されます。

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

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

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

キャシーは7月4日に退職する予定です。タイムゾーン対応の非アクティブ化機能が有効化されていない場合、すべての非アクティブ化はUTCタイムゾーン（GMT）で固定されているため、UTC時で深夜0時が過ぎた後のインポートでキャシーの退職手続きが実行されます。タイムゾーン対応の雇用前／退職機能が有効化されている場合、シドニー時間（GMT+10）で深夜0時が過ぎた後のインポートでキャシーはOktaから非アクティブ化されます。キャシーは、以前に非アクティブ化されていたはずの10時間前に、実際に非アクティブ化されます。