Workday

Oktaでは、標準のAPIを通じてWorkdayからユーザーやグループをインポートできます。OktaはWorkdayプロビジョニンググループのみをインポートします。Workdayセキュリティグループはインポートされません。

Oktaは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プロビジョニンググループからOktaグループが作成されます。

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

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

Oktaは、［最初の勤務日］および［雇用日］の属性またはフィールドが入力されているユーザーのみをWorkdayにインポートします。
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を含む）
再雇用
- 退職したWorkerがWorkdayで再雇用される
- 非アクティブ化されたOktaユーザーをOktaで手動で再アクティブ化する
- Oktaが再雇用されたWorkerを再アクティブ化されたOktaユーザーにインポートしてリンクする

前提条件

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

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

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

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

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

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

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

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

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

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

セキュリティグループを作成するには、「セキュリティグループを作成」と入力し、検索結果の［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（セキュリティグループのドメイン権限を管理）］を選択します。
セキュリティグループに次のビジネスドメインセキュリティポリシー権限を付与します。
- External Account Provisioning（権限：Get and Put）
- Person Data: Work Contact Information（権限：Get and Put）
- Worker Data: Public Worker Reports（権限：Get and Put）
- Worker Data: Current Staffing Information（権限：Get）
- Worker Data: All Positions（権限：Get）
- Worker Data: Business Title on Worker Profile（権限：Get）
- Manage: Location（権限：Get）（利用できない場合は代わりにWorker Data: Manage Locationsを使用します）
制限付きセキュリティグループを作成するときは、グループに次のビジネスドメインセキュリティポリシー権限を付与します。
- Worker Data: Workers（権限：Get）
［OK］をクリックしてセキュリティグループのドメイン権限を更新し、［Done（完了）］をクリックします。

Workdayで確認して、セキュリティグループに必要なすべての権限が構成されていることを確認してください。
制限なしセキュリティグループを作成する場合は、Worker Data: Workersからすべてのユーザーを削除する必要があります。
Workdayは、セキュリティポリシーの変更をアクティブ化するように警告する場合があります。変更をアクティブ化しない場合、統合ユーザーアカウントに必要な権限が付与されません。次を実行して変更をアクティブ化します。

「保留中のセキュリティポリシーの変更をアクティブ化」を検索し、結果のタスクをクリックします。
コメント（必須）を入力し、［OK］をクリックします。
アクティブ化が必要な変更を確認します。

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のリアルタイム同期」を参照してください。
［Deactivate on Last Day of Work（最終勤務日に非アクティブ化）］（オプション）：このオプションを使用すると、終了日ではなく最終勤務日に基づいてユーザーを非アクティブ化できます。ユーザーの非アクティブ化は、最終勤務日が現在の日付と一致すると実行されます。
［Timezone aware terminatons（タイムゾーン対応の退職）］（オプション）：このオプションを使用すると、タイムゾーンまたは場所での現在の時刻に基づいてユーザーを非アクティブ化できます。「タイムゾーン対応の退職」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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の元のグループから削除され、新しく作成された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	Okta
appuser.accountType	userType
appuser.businessTitle	役職
appuser.businessUnit	department
appuser.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

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

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

ソースとしてのWorkdayには通常、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	市区町村
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環境に合わせてマネージャー（UPN）属性を異なる方法で構築できます。

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

Workdayのカスタム属性

カスタム属性は、次のセクションで説明するフィールドの上書きを利用してインポートできます。

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

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］をクリックします。
［統合サービスを構成］ページで、下にスクロールして［Custom Integration Services（カスタム統合サービス）］セクションに移動し、+（プラス）記号をクリックします。
［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>」のように、プロパティタイプとプロパティ名をコロンで区切って名前を付けます。例： 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（統合）］に進みます。Integration System Idという新しい構成プロパティが表示されます。
［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がテナントの新しく作成されたワーカーにのみ適用されます。既存のワーカーにバックポートするには、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で退職したワーカーを処理します。このようなアクションには、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時間前に非アクティブ化されます。