SAP SuccessFactors Employee Centralデータ プロビジョニングについて

下表はSAP SuccessFactors Employee CentralがOktaと統合したときに特定のデータ型がどのようにプロセスされるかを示します。

データ型 説明
複数のジョブ割り当て

複数のジョブが割り当てられている従業員がいる場合(グルーバル割り当てまたは同時割り当て)、以下のようにOktaでプロセスされます。

グルーバル割り当てには"person___employment_information_GA1___"というプレフィックスが付きます。例:"person___employment_information_GA1___job_information___job_title"

標準割り当てには"person___employment_information_ST1___job_information"というプレフィックスが付きます。例:"person___employment_information_GA1___job_information___job_title"。ST1/ST2でemployment_information.employment_idの値を定義します。例:"employment_information.employment_id=123" が "ST1" としてプロセスされ、"employment_information.employment_id=456" がST2としてプロセスされます。

ユーザー ステータス

ユーザーのステータスはEmployee Centralのジョブ情報エンティティから取得されます。

ユーザーの job_information.emplStatus == "A"の場合、ユーザーはOktaでアクティブとして扱われます。

ユーザーのステータスがジョブ情報エンティティでアクティブでない場合、Oktaはユーザーのjob_information.start_date)を再度確認します。

ユーザーの開始日が preHire Interval(雇用前インターバル)内の場合、ユーザーはOktaでアクティブな雇用前ユーザーとして識別されます。Oktaは各ユーザーに対して最も早い値のjob_informationレコードを選択し、次のようなチェックを実行します: "now > startDate > now + preHireInterval" — この条件に当てはまる場合、ユーザーはアクティブとして扱われます。

ユーザーが非アクティブであり、雇用前確認を通過しない場合、退職後確認が実施されます。Oktaは最も最近の *___job_information___start_date (退職開始日) の値を選択してそれを "inactiveStartDate < (now - postTerminationInterval)"と照合します。

ユーザーがすべての検証に通らなかった場合、非アクティブと識別されOktaにインポートされません。

下図はOktaユーザー ステータス確認のワークフローを示します。

これは早期アクセス機能です。この機能を有効にするには、早期アクセス機能とベータ機能の管理で説明したように、早期アクセス機能マネージャーを使用します。

SuccessFactors統合は複数のアクティブ ユーザー ステータスをサポートし、そこで管理者は様々なユーザーステータスをOktaでアクティブとして扱うよう選択できます。たとえ管理者が何も選択しなくても、デフォルトのステータスは常にActive(アクティブ)です。 例えば、キャシーは現在有給休暇中ですが、それでもOktaでアプリにアクセスしたいと希望しています。この機能を使用すれば、管理者は有給休暇中をアクティブ ユーザー ステータスとして選択し、キャシーはアプリにアクセスすることができます。

SucessFactorsのプロビジョニングを構成する際に([Provisioning(プロビジョニング)]タブ[To Okta(Oktaへ)][General(一般)]セクションの[Active User Statuses(アクティブ ユーザーステータス)]フィールド)、Active(アクティブ)とみなされるユーザー ステータスを選択します。

注:

  • 2020年10月より前に作成されたアプリでは、プロビジョニング設定を再保存したりプロファイル エディターで属性リストを更新する必要はありません。つまり、OktaはSuccessFactorsから利用可能なユーザー ステータスの一覧を取得できます。
  • 統合ユーザーがジョブステータス情報を取得するためにはpicklists_sys_admin権限が必要です。[Provisioning(プロビジョニング)]タブにステータス リストが表示されない場合、APIユーザーがこの権限を持っているか確認してください。
電話およびEメール

電話およびEメールのどちらも、"isPrimary = true"とマークされたエンティティがOktaユーザー プロファイルにマップされます。ライトバック機能が有効化されている場合、Oktaは電話およびEメール フィールドにライトバックし、そのタイプをPrimary(プライマリ)として設定します。

API制限により、Oktaのメールアドレスは、プライマリにマークされた設定済みのメールを持ち、アクティブなEメールタイプ(通常は”Business”タイプ)を持つユーザーに対してのみアップデート可能です。

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

SAP SuccessFactors Employee Centralでは、請負業者から正社員への変換は、派遣労働者の契約終了と正社員の新規採用として扱われます。

派遣労働者がSAP SuccessFactors Employee Centralで退職すると、次回ユーザーデータが同期化されたときに、退職後プロセスが有効化されるまでユーザーはOktaで非アクティブ化されます。ユーザーがSAP SuccessFactors Employee Centralで正社員として追加されると、そのデータがOktaにインポートされ、新規作成されたSAP SuccessFactors Employee Centralの正社員と、非アクティブ化された既存のOktaユーザーを一致させるためにインポート マッチング ルールが使用されます。ただし、ユーザーの再アクティベートは手動で行う必要があります。インポート マッチング ルールを使用した自動再アクティベーションはサポートされていません。

関連記事