ジョブ・オファー(第10章) 21D

オファー・チームの一員ではないユーザーへのジョブ・オファーへのアクセス権の提供

ユーザーは、ユーザーの権限とデータ・セキュリティに基づいて、候補者のジョブ・オファーを表示、更新、連絡、移動および処理できます。ユーザーがオファー・チームに特に含まれているオファーの特定の部分のみを表示または編集できるように、ユーザーの権限を緊密に構成できます。逆に、特定のユーザーが特定の部署内のオファーに関するすべてを管理したり、個人セキュリティ・プロファイルに基づいて全社的にオファーを管理したりできるように、より幅広い表示を構成することもできます。

ユーザーは、ジョブ・オファーの選択後に他の選択プロセスを介して候補者のジョブ応募を進めるために、特定の職務ロールおよび権限が必要です。

標準ロール「採用マネージャ」は、ジョブ・オファーを表示および開始する単純な機能とともにデフォルトで定義されます。ジョブ・オファーの作成と伝達の主な作業は、採用担当者というシード済ロールを持つユーザー、または採用担当者のすべての処理を実行できる採用マネージャというロールによって処理されます。その後、採用プロセスの最終ステップは、HR担当者の標準ロールを持つユーザーによって実行されます。

ジョブ・オファーの作成または再作成: ユーザーは「ジョブ・オファーの開始」権限が必要です。この権限では、ジョブ・オファーのすべての必須フィールドを完了できません。この権限は、デフォルトでは採用マネージャ・ロールおよび採用担当者ロールに付与されます。
ジョブ・オファーの詳細の表示: ユーザーは、これらのセクションを表示するには、ジョブ・オファーの表示、ジョブ・オファー給与の表示およびジョブ・オファーその他の報酬の表示職務ロールが必要です。これらの職務ロールは、デフォルトで採用マネージャおよび採用担当者ロールに付与されます。
ジョブ・オファーの詳細の編集: これらの各セクションを編集するには、「ジョブ・オファーの更新」、「ジョブ・オファー給与の更新」および「ジョブ・オファーその他の報酬の更新」職務ロールが必要です。これらの職務ロールは、デフォルトで採用担当者ロールに付与されます。
ジョブ・オファーの承認: ジョブ・オファーの承認には特別な権限がありません。ただし、ユーザーは、通知でこれらの各セクションを表示するには、「ジョブ・オファーの表示」、「ジョブ・オファー給与の表示」、「ジョブ・オファーその他の報酬の表示」職務ロールが必要です。ジョブ求人の表示集計権限も必要です。
処理を実行して、オファーの作成、オファーの送信、オファーの受諾、候補者の移動など、候補者のジョブ応募を選択プロセスの新しい状態に移動します。ユーザーは「候補者のジョブ応募の移動」権限が必要です。この権限は、デフォルトでは採用マネージャ・ロールおよび採用担当者ロールに付与されます。
ジョブ・オファーの拡張、候補者のかわりにジョブ・オファーを受け入れ、オファーが提示された後に候補者を否認するなど、候補者へのアラートまたはコミュニケーションをトリガーする処理を実行します。ユーザーは、「ジョブ・オファーの通信」権限が必要です。この権限は、デフォルトでは採用担当者ロールに付与されます。
「マイ・クライアント・グループ」の「オファーの管理」クイック・アクションを使用して、承認されてHRフェーズに進んだジョブ・オファーのリストを確認します。「アドレス・ジョブ・オファー」集計権限が必要です。オファーの特定のセクションを表示するために他の権限は必要ありません。この権限は、デフォルトで人事担当者ロールに付与されます。

候補者のジョブ・オファーにアクセスするには、特定のデータ・セキュリティも必要です。

ユーザーは、候補者のジョブ応募内のジョブ・オファーにアクセスするか、オファーのリスト(「自分のクライアント・グループ」→「採用」→「ジョブ・オファー」または「自分のチーム」→「採用」→「ジョブ・オファー」)からジョブ・オファーにアクセスできます(そのユーザーがそのオファーのリストのオファー・チーム・メンバーの一部である場合)。管理階層内で管理しているユーザーがオファー・チームに含まれている場合、ユーザーはジョブ・オファーにアクセスすることもできます。標準採用マネージャ・ロールと採用担当者ロールに基づくロールを持つすべてのユーザーは、データ・ロール内の個人セキュリティ・プロファイルに関係なく、これらのオファーにアクセスできます。
ユーザーは、候補者のジョブ応募内のジョブ・オファーにアクセスするか、またはオファーのリスト(「自分のクライアント・グループ」→「採用」→「ジョブ・オファー」または「自分のチーム」→「採用」→「ジョブ・オファー」)からジョブ・オファーにアクセスできます(その候補者がそのユーザーの個人セキュリティ・プロファイル内にある場合、そのユーザーがオファー・チームで名前を付けられたり、そのチームの誰かが管理せずに)。この機能は、職務ロール「採用マネージャ別ジョブ・オファーの管理」に基づくロールを持つすべてのユーザーが使用できます。
ユーザーは、候補者のジョブ・オファーを承認または否認するように要求されたときに、ジョブ・オファーを表示できます。この要求の詳細を表示するには、ユーザーをオファー・チームに含める必要はありません。候補者がユーザーのデータ・ロールの個人セキュリティ・プロファイル内にあるかぎり、候補者のオファー値はユーザーに表示されます(これらの権限に基づいて表示されるセクション内)。
- ジョブ・オファーの表示
- ジョブ・オファー給与の表示
- ジョブ・オファーその他の報酬の表示
- 求人の表示
HR担当者は、「自分のクライアント・グループのジョブ・オファーの管理」クイック・アクションを使用して候補者のジョブ・オファーにアクセスできます。候補者がデータ・ロールの個人セキュリティ・プロファイル内にある場合は、候補者のジョブ・オファーにアクセスできます。このHRフェーズ中にオファー・チームに含めることは関係ありません。

ジョブ・オファーの「時期および事由」セクションの構成

ジョブ・オファーの作成または編集時に「時期および事由」セクションが必須であり、非表示に設定できません。

このセクションの4つのフィールドはすべて、ジョブ・オファー・ページの後続のフィールドとリージョンに影響を与えるため、続行する値を持っている必要があります。これらのフィールドのいずれかを非表示にするように構成されている場合でも、オファー・プロセスを続行するには値を受け取る必要があります。「雇用主」および「就業者タイプ」フィールドが関連求人から値を継承しなかった場合(たとえば、ユーザーが手動で入力できない場合は、「処理」フィールドに適切な値を選択することはできません)。

関連項目

トランザクション設計スタジオを使用した採用ページの構成方法

求人ヘッドカウントを考慮したジョブ・オファーの構成

候補者がライフサイクルを進めるにつれて、追加の就業者がまだ必要であることを確認するため、または機会が使用できなくなった場合にその進行を止めるために求人がチェックされます。

募集人数が、採用された候補者の数に提示済オファーまたは受諾済オファーを持つ人員の数を加えた数と同じか小さい場合、求人は候補者数の限度にあるとみなされます。オファー - 提示済ステータス以上の候補者は、この方式でカウントされます。これらの候補者のうち、後に「雇用主により否認済」または「候補者により取下げ済」に移動された候補者は、この数から差し引かれます。

ジョブ・オファーの連絡、求人制限の無視の権限を持つユーザーのみが、求人の空席数よりも多くの候補者を採用できます。これらのユーザーは、オファー・フェーズで必要とする数のジョブ応募を先に進められますが、求人に対する検証は実行されません。

求人に対してオファー検証が実行されるタイミング

ジョブ応募のライフサイクルで求人の残りの空席数がチェックされている場合、次のようになります。

ユーザーがジョブ・オファーの作成または編集中に「発行」ボタンを使用する場合: 制限に関係なく候補者のジョブ応募にジョブ・オファーをドラフトできますが、ユーザーが承認サイクルに送信する準備ができていると検証が行われます。フロー「オファーの作成」または「オファーの編集」で「発行」ボタンをクリックすると、ユーザーにエラー・メッセージが表示される場合があります。この制限を無視する権限がユーザーに付与されていないかぎり、求人に空席がない場合、ジョブ・オファーを送信できません。採用済個人と拡張オファーの両方をカウントします。これにより、求人にこの候補者の領域がない場合に追加オファーを承認するポイントがほとんどないため、承認者の時間が節約されます。
「オファーの延長」処理を使用する場合: ユーザーが下書きジョブ・オファーを候補者に提示する準備ができた時点で、求人またはポジションが更新または充足されたため、この候補者に空きが残らない場合があります。ステータスをオファー - 提示済に移動する前に同じチェックが実行され、もう存在しない空席のジョブ・オファーについて候補者に通知できません。この制限を無視する権限を持つユーザーのみが、必要に応じてオファーを拡張できます。
「オファーの延長」処理が自動的にトリガーされる際の構成可能: 求人の候補者選択プロセスがジョブ・オファーを拡張するように構成されている場合(即時または遅延後)、求人の採用済候補者数はデフォルトでは選択されません。ただし、求人が満杯の場合は、オファーの延長をチェックおよび防止するように自動進行を構成できます。求人に、ドラフト・オファーを最初に発行できる十分な空席がある場合のみ、ジョブ応募を延長できます。
受諾時にはなし: ジョブ・オファーが「提示済」状態であるかぎり、候補者がオファーを受諾できなくなることはありません。これは、候補者のためにオファーを受諾できる採用ユーザーにも当てはまります。一方で、求人が更新されたり、より多くの採用が取得された場合でも、候補者とユーザーにはこれらの制限が通知されません。この時点の後の問題を調整するのは、HR担当者の責任です。
HRへの移動後禁止: 候補がHRフェーズに移動したときは、求人の制限に対して、さらなる検証は行われません。

ポジションを尊重するジョブ・オファーの構成

ポジションを使用して採用を管理する企業には、求人の採用制限をチェックするだけでなく、新しいジョブ・オファーごとに十分な空きがあることを検証する方法がいくつかあります。オファーは、承認済の採用ステータスを持つポジションに基づいていて、その前進の進捗状況を、そのポジションの人員数と常勤換算に対して多くの点でチェックできます。

ポジションによってオファーが様々な制限を超えないようにする方法を構成できます。

ポジション採用ステータスのチェック: このグローバル・プロファイル設定は、オファーおよびその他のアサイメントが、採用ステータスのポジションに基づいて作成できるかどうか、または採用ステータスが「承認済」で、「提示済」または「凍結済」ではないもののみかどうかを制御します。(これは、ポジションのステータス「アクティブ」または「非アクティブ」とは無関係です。)
在職者数の検証: このグローバル・プロファイル設定は、すべてのポジションのヘッドカウントが組織全体で強制されるかどうかを制御します。この設定を有効にすると、多くの就業者関連の処理で、新規アサイメントのポジションに、処理待ち就業者の追加、新規従業員の採用、内部就業者の異動、候補者ジョブ・オファーの管理など、オープン・ヘッドカウントおよび欠員常勤換算が十分にあるかどうかが検証されます。
重複の許可: このオプションは、各ポジションで、ヘッドカウントおよび常勤換算の制限に達したときに、追加で個人を採用できるかどうかを制御するために使用できます。

ポジションの人員数と常勤換算の制限に達すると考えられるのはいつですか?候補者は、ジョブ応募が採用ライフサイクルでオファー - 提示済ステータスに達するとすぐに、提示開始日時点の在職者とみなされます(また、候補者によって取下げ済または雇用主により否認済状態を除くその後の状態)。そのため、これらの現職者候補者は、提示された開始日時点の他のすべての現職者に追加され、追加ジョブ・オファーが採用ライフサイクルを進めるかどうかが計算されます。

「ポジション採用ステータス」の設定を、オファーを含め、すべてのポジション・ベースのアサイメントのポジション採用ステータスをチェックするために提示するには、次のようにします。

「設定および保守」作業領域で、「管理者プロファイル値の管理」タスクを検索します。
プロファイル・オプション・コードORA_POS_HIRING_STATUS_FILTERを検索します。
「処理」メニューで、「加算」アイコンをクリックします。
「プロファイル・レベル」列の下にある分類「サイト」を選択します。
検証を実行するにはYを入力し、NULLのままにするか、各ポジションの採用ステータスを無視するにはNを入力します。

オファーを含め、すべてのポジション・ベースのアサイメントの在職者検証の数設定を表示するには:

「設定および保守」作業領域で、タスク「拡張可能フレックスフィールドの管理」を検索します。
プロファイル・オプション・コードPER_ORGANIZATION_INFORMATION_EFFを検索します。
「処理」メニューで、「編集」をクリックします。
「組織」カテゴリの下の「エンタープライズ」分類を選択します。
「企業詳細」セクションで、「ポジション在職者の追加」ページを追加します。

オファーを含め、すべてのポジション・ベースのアサイメントの在職者検証の数設定を有効にするには:

「設定および保守」作業領域で、「企業HCM情報の管理」タスクを検索します。
「ポジション在職者検証」セクションで、「在職者検証の適用」オプションを選択します。

在職者検証の数設定が公開されていないか、公開および未チェックである場合、ポジション・ベースのオファーおよびそのポジションを含む他のすべてのアサイメントに対して検証は実行されません。設定が公開およびチェックされると、採用およびHR内で直接採用処理を含む、スイート全体で検証が実行されます。

ポジションに対してオファー検証が実行されるタイミング

ジョブ応募のライフサイクルで求人の残りの空席数がチェックされている場合、次のようになります。

ポジションに基づいてジョブ・オファーを作成するとき: このフィールドがチェックされるように構成されている場合、ジョブ・オファーの作成時に検索で、採用ステータスが「承認済」(さらに「提示済」または「凍結」ではない)のポジションのみを検索できます。
ユーザーがジョブ・オファーを作成または編集するときに「発行」ボタンを使用すると、ジョブ・オファーは、そのポジションの在職者の数に関係なく、候補者のジョブ応募に対してドラフトを作成できますが、ユーザーがそのポジションを承認サイクルに送信すると、警告またはエラー・メッセージが表示される場合があります。提示された開始日時点でポジションに十分なオープン・ヘッドカウントがないか、十分な欠員常勤換算がない場合(在職者数検証が無効でない場合)、ドラフト・オファーを送信できません。ただし、重複を許可するようにポジションが構成されている場合、この候補者によってオファー開始日時点でポジションが過剰に充足されることがユーザーに警告されますが、続行して承認のために下書きオファーを送信できます。
「オファーの延長」処理を使用する場合: ユーザーがドラフト・ジョブ・オファーを候補者まで拡張する準備ができた時点で、ポジションが更新されたり、以前よりも追加の在職者を取得した可能性があるため、この候補者には十分なヘッドカウントまたは常勤換算がありません。ステータスをオファー - 提示済に移動する前に同じ検証が実行され、前述の設定とオプションに従って適切なエラーまたは警告メッセージが表示されます。
「オファーの延長」処理が自動的にトリガーされた場合: 求人の候補者選択プロセスがジョブ・オファーを提示するように構成されている場合(即時または遅延後)、ポジションの在職者数がチェックされます。ポジションに十分なオープン・ヘッドカウントと欠員常勤換算がある場合、または重複が許可されている場合、自動処理は成功します。空きがなく、ポジションが重複を許可しない場合、延長は成功せず、候補者のジョブ応募はステータス「オファー - 承認済」のままになります。
受諾時にはなし: ジョブ・オファーが「提示済」状態であるかぎり、候補者がオファーを受諾できなくなることはありません。これは、候補者のためにオファーを受諾できる採用ユーザーにも当てはまります。ポジションが更新されたり、同時に現職者の数が増えたりする可能性が低い場合でも、候補者とユーザーにはこれらの制限が通知されません。この時点の後の問題を調整するのは、HR担当者の責任です。
HRに移動時、手動または自動トリガー: 採用ユーザーがメニューをクリックしたか、候補者選択プロセス内でトリガーしたかにかかわらず、HRフェーズへの移行は常に成功します。ただし、提示された開始日時点でポジションにすでに十分なヘッドカウントまたは常勤換算があり、重複が許可されていない場合、候補者は「処理中にエラーが発生しました」状態のHRフェーズに到着します。この状況に対処するのは人事担当者が責任を負います。ただし、ポジションに十分な空きがない場合でも、ポジションが重複できる場合、候補者は問題なくHRフェーズに移動され、警告は「オファー」ページの「エラー」セクションに表示されたままになります。

給与セクションを使用したジョブ・オファーの構成

ジョブ・オファーを構成して「給与」セクションを表示できます。

デフォルトでは、「給与」セクションは非表示です。顧客によっては、給与ベースの選択肢がまったくなく、個別報酬プランが特定の給与に関連付けられていない場合は、特定のオファーに対する目的の給与を指定する必要がない場合があります。

オファーに対して選択した給与ベースでは、オファーのドラフト中にも給与を選択する必要があります。給与ベースにリンクされたエレメントは、特定の給与またはすべての給与のいずれかで定義されたエレメント適格を使用して構成できます。これは、エレメントの資格を開いたままにしておく一般的な推奨事項に反します。つまり、選択した給与ベースは特定の給与計算でのみ使用でき、このオファーの作成中に給与計算が選択されていない場合、候補者を就業者にする処理中にエラーが発生します。

同様に、個別報酬プランの適格性は、適格プロファイルまたはエレメント適格のいずれかに依存するように構成できます。給与エレメント・レベルの適格ではなく、適格プロファイルを構成することをお薦めします。ただし、給与適格が特定の給与またはすべての給与で定義されている場合は、その候補者のオファーで給与を指定し、それらの報酬プランがその候補者に使用可能なものとして表示されるようにする必要があります。

「給与」セクションが表示されると、オファーの雇用主に関連する国に応じて、複数のフィールドがデフォルトで表示されます。これらのフィールドは、Oracleのローカライゼーション・チームがソリューションの一部として提供する、トランザクション設計スタジオのルールによって表示されます。これらのルールは、各国の法的規制に基づいており、たとえば、カナダ、中国、アイルランド、メキシコ、英国、米国などの国々で税金レポート・ユニットなどの必要な情報が収集および表示されることを確認します。

要件の「給与」セクションを表示するには、トランザクション設計スタジオでルールを作成する必要があります。

ジョブ・オファーを作成または編集する際、これらのルールは必要に応じて給与属性を収集するのに役立ちます。
- 新規オファーの作成時に「給与」セクションを表示するルール。
- 既存のオファーの編集中に「給与」セクションを表示する1つ以上のルール。たとえば、「時期および事由」セクションで「処理待ち就業者の追加」および「処理待ち雇用関係の追加」が指定されているオファーの「給与」セクションを表示するルールを追加できます。
- 内部モビリティなどに関連しない場合に「給与」セクションを非表示にする1つ以上のルール。たとえば、オファーの「給与」セクションを非表示にするルールを追加できます。このルールには、「時期および事由」セクションで「昇格・昇進」処理や「異動」処理、同様の処理を指定します。
「採用」領域でジョブ・オファーを表示しているときに、「給与」セクションを表示または非表示にするルールを外部オファーと内部オファーの処理または他の属性に基づいて構成できます。
「ジョブ・オファーの管理」領域内でジョブ・オファーを表示しているときに、同じ属性に基づいて「給与」セクションを表示または非表示にできます。

オファー - 下書きステータスのオファーを作成または編集中に「給与」セクションを表示するには:

「設定および処理」メニュー→「ページの編集」→「サンドボックスのアクティブ化」の「サイト」レイヤーでサンドボックスおよびページの編集をアクティブ化します。
ホーム・ページで、「自分のクライアント・グループ」→「クイック処理」→「HCMエクスペリエンス設計スタジオ」に移動します。
「トランザクション設計スタジオ」タブをクリックします。
「採用 - ジョブ・オファーの作成および編集」アクションを選択して、ジョブ・オファーのステータスが"オファー - 下書き"のときにジョブ・オファー値の入力に関するルールを設定します。
「追加」をクリックし、「給与」セクションを表示するルールを作成します。
「基本詳細」セクションで、ルールの名前と説明を入力します。必要に応じて他のフィールドに入力します。
- 外部候補者のルールを作成するには、「処理」フィールドで「処理待ち就業者の追加」や「処理待ち雇用関係の追加」などの値を選択します。
- 内部候補者のルールを作成するには、「昇格・昇進」や「異動」などの「処理」フィールドの値を選択します。
「リージョンの表示または非表示」セクションで、「給与情報」リージョンを表示可能にできます。また、ユーザーが質問リスト・ページから非表示を選択せずに、各オファーを作成または編集する際に常にこのセクションが表示されるように、このセクションを必須にすることもできます。
「ページ属性」セクションで「給与情報」リージョンを選択し、表示するフィールドと必須にするフィールドを決定します。特定の国に必要な特定のフィールドをすでに表示している標準のルールがあるため、ビジネスでこれらの国の追加フィールドが必要かどうかを確認する必要があります。提供されているルールがニーズに合った場合、「リージョンの表示」または「リージョンの非表示」セクションでリージョンが上に表示されるように構成されていれば、この「ページ属性」セクションで「給与」をさらに定義する必要はありません。
「保存して閉じる」をクリックします。

ジョブ応募内のオファー・ページを表示して、クイック処理「ジョブ・オファーの管理」から表示しているときに「給与」セクションを表示するには:

ホーム・ページで、「自分のクライアント・グループ」→「クイック処理」→「HCMエクスペリエンス設計スタジオ」に移動します。
「トランザクション設計スタジオ」タブをクリックします。
「採用 - ジョブ応募におけるジョブ・オファーの表示」または「採用 - ジョブ・オファーの表示および管理」の処理を選択します。
「追加」をクリックし、「給与」セクションを表示するルールを作成します。
「基本詳細」セクションで、ルールの名前と説明を入力します。必要に応じて他のフィールドに入力します。「処理待ち就業者の追加」や「処理待ち就業者関係の追加」など、外部候補者オファーに関連するすべての処理を選択します。
「ページ属性」セクションで、「ジョブ応募におけるジョブ・オファーの表示」リージョンまたは「ジョブ・オファーの表示およびマネージャ・ジョブ・オファー」リージョンを選択し、このオファー・セットについてセクションを表示するかどうかを決定します。
「保存して閉じる」をクリックします。

等級ラダーからのジョブ・オファーの給与の移入

ジョブ・オファーの給与の値は、候補アサイメントで指定された等級または等級ラダーに基づいて移入されます。ジョブ・オファーの「ジョブまたはアサイメント」セクションで、ステップ付きまたはなしで等級または等級ラダーを定義すると、関連付けられている給与が、ジョブ・オファーの「給与」セクションでデフォルトで事前入力されます。

「設定および保守」作業領域で、「昇格等級ラダー」タスクを使用します。
昇格等級ラダーを作成する場合:
- 「給与更新を含める」を「はい」に設定します
- 「給与の計算方法」を「等級ステップ・レートの使用」に設定します
この機能は、給与ベース・タイプが「給与額をユーザーにより決定」である給与ベースに割り当てられたオファーに関連しています。
オファー・フローに「給与」セクションを含めます。
オファー・フローの「アサイメント」セクションに、「等級ラダー」、「等級」および「ステップ」属性を含めます。これには、HCMエクスペリエンス設計スタジオのトランザクション設計スタジオを使用して構成する必要があります。
- 例外: 等級にステップがない場合は、ステップ属性を含める必要はありません。

関連項目

レート付きの給与額を等級ラダーから移入する方法

「その他の報酬」セクションを使用したジョブ・オファーの構成

ジョブ・オファーの一部として候補者に付与する個別報酬プランを選択できます。

デフォルトでは、「その他の報酬」リージョンが表示され、適格プランを選択できます。賞与、株式、車両手当、その他の形の報酬などの給与に加えて、報酬を授与できます。

候補者がこのプランまたはオプションの組合せに対して適格でないか、複数の領域の1つの構成が不適切なため、採用担当者がオファーの作成および編集プロセス中に特定のプランを表示できません。不適切な構成を識別するには、次の領域を確認します。

個別報酬プランはアクティブ状態ですか。オファー・チームがオファー・プロセスで選択するプランを可視にすると、プランがアクティブであることを確認するほど簡単になります。
「時期および事由」セクションでオファーの選択処理に対してプラン・アクセスが構成されていますか。「オファーの作成」および「オファーの編集」処理のみにアクセス権を付与する個人報酬プランはオファーに表示されません。これは、候補者が処理待ち就業者に移行し、最終的に就業者に移動した場合は保持されないためです。かわりに、「処理待ち就業者の追加」、「異動」、「昇格・昇進」などの処理へのプラン・アクセスを構成して、関連するオファーの作成中に表示することもできます。
候補者は個別報酬プランの適格プロファイルに適格ですか。この候補者に対してこれまでにドラフトされたオファーに基づき、現在は特定のプランに適格であり、他の人には適格ではない可能性があります。この資格は、オファーのアサイメントに関する情報に基づいて計算されます。たとえば、会社の特定のグループに属している可能性があり、候補者が持っていた他の現在または過去のアサイメントに基づいていません。したがって、個別報酬プランから適格プロファイルを削除すると、この制限が削除され、このオファーの作成中にプランが選択できるようになります。
プランは適切な処理によってアクセスされるように構成されていますか。個別報酬プランの中には、新規採用者には付与されるが、再雇用には付与されないものもあれば、内部モビリティ・プロセスに対してのみ予約できるものもあります。個別報酬プランの構成では、プランへのアクセスを制限せずにオファーを作成する際に表示したり、適切な処理を使用してそれらの処理のみを制限するように構成できます。
個人はエレメント自体に適格ですか。必要なプランが選択可能であることを確認するには:
- このオファーが最初にドラフトされた日付を含めて、エレメントおよび適格開始日が過去に十分であることを確認してください。
- 候補者のオファーがエレメント適格に適格であることを確認します。この制限を削除するには、エレメント・レベルでオープン資格を定義することをお薦めします。
- このオファーがドラフトされている雇用主および国別仕様データ・グループにエレメントが添付されており、そのエレメントが国別仕様データ・グループに存在することを確認します。
- 従業員候補者(候補者標準)、派遣就業者候補者(候補者エレメント・エントリのみ)、処理待ち従業員(処理待ち就業者標準)の個人タイプに給与関係マッピングが定義されていることを確認します。

関連項目

個別報酬の概要

遅延報酬によるジョブ・オファーの構成

予定開始日または遅延後に割り当てられた個別報酬プランを使用してジョブ・オファーを構成できます。個々の報酬プランは、新しいアサイメントが開始するのと同じ日、または特定の日数または週数後に、候補者に約束できます。

個別報酬プランの開始日と終了日を、オファーで定義された予定採用日と同期できます。採用担当者がオファーの採用予定日を変更するたびに、個別報酬セクションに移動するとプランの日付が自動的に調整されます。たとえば、オファーの予定開始日が2022年1月1日で、プラン割付が同じ日に開始するとします。その後、予定入社日が2022年2月1日に変更されます。個別報酬セクションに移動すると、新しい採用予定日と連携して、既存のプラン開始日が2022年2月1日に調整されます。

または、遅延を設定できます。オファーの下書きが作成されると、予定採用日と指定した遅延を使用してプランの開始日と終了日が自動的に設定されます。たとえば、予定入社日の1か月後に開始するサインオン・ボーナスがオファーに含まれているとします。現在の予定入社日は2022年2月1日であるため、個別報酬セクションに移動すると、ボーナス・プランの開始日が2022年3月1日に設定されます。

採用担当者がドラフト・オファーにプランを含める場合は、計算済プラン開始日、終了日またはその両方を上書きできます。ただし、採用担当者が日付を上書きすると、自動的に同期されなくなり、予定開始日が変更されるたびに手動介入が必要になります。これらの介入では、既存のプランの日付は訂正せずに、授与された個別報酬を削除して再び追加してください。

ジョブ・オファー・フレックスフィールドの構成

ジョブ・オファー内で様々なタイプのフレックスフィールドが使用可能であり、「オファー」ページの様々なセクションに表示されます。オファー・フレックスフィールド(IRC_OFFERS_DFF)は、オファー・ページの「追加情報」セクションに表示されます。

グローバル・セグメントとコンテキスト依存セグメントの両方に対して、次のフレックスフィールドを定義できます。

90テキスト・フレックスフィールド
30数値フレックスフィールド
10の日付フレックスフィールド
10時間フレックスフィールド

ジョブ・オファー・フレックスフィールドを構成する主なステップは次のとおりです。

ジョブ・オファー・フレックスフィールドを構成します。
ジョブ・オファー・フレックスフィールドを表示します。

ジョブ・オファー・フレックスフィールドの構成

最初にジョブ・オファー・フレックスフィールドを構成する必要があります。

「設定と保守」作業領域で、次の場所に移動します。
- 講義: 採用および候補者エクスペリエンス
- 機能領域: ジョブ・オファー
- タスク: ジョブ・オファーの付加フレックスフィールド
「ジョブ・オファーの付加フレックスフィールド」ページで、「ジョブ・オファーの付加フレックスフィールド」を選択します。
「処理」メニューで、「編集」をクリックします。
「グローバル・セグメント」セクションには、コンテキストに関係なくすべてのオファーで使用可能なフレックスフィールドが表示されます。各行には、使用可能な回答オプションを制御する値セットと、そのページにラベルを付けるためのプロンプトが表示される場合があります。「作成」アイコンをクリックして、必要な新しいグローバル・フレックスフィールドを追加します。
「コンテキスト・セグメント」セクションには、ユーザーが目的のコンテキストを選択した後、特定のオファーで使用可能なフレックスフィールドが表示されます。各行には、値セットとプロンプトを表示できます。「作成」アイコンをクリックして、必要なコンテキスト・フレックスフィールドを追加します。このセクションの上部にあるメニューで別の値を選択してコンテキストを変更し、追加のフレックスフィールド・セットを表示し、必要に応じて拡張できるようにします。
「保存して閉じる」をクリックします。
ジョブ・オファー付加フレックスフィールド・ページに戻ったら、「フレックスフィールドのデプロイ」をクリックします。

ジョブ・オファー・フレックスフィールドの表示

トランザクション設計スタジオを使用して、次のオファー処理を使用してオファー・フレックスフィールドを表示するルールを作成します。

「採用 - ジョブ・オファーの作成および編集」には、「採用」作業領域でジョブ・オファーを作成中にオファー・フレックスフィールドが表示されます。
「採用 - ジョブ応募におけるジョブ・オファーの表示」には、「採用」作業領域のジョブ応募の「オファー」タブにオファー・フレックスフィールドが表示されます。
「採用 - ジョブ・オファーの表示および管理」では、「ジョブ・オファーの管理」クイック・アクションでオファーにオファー・フレックスフィールドが表示されます。

「設定および処理」メニュー→「ページの編集」→「サンドボックスのアクティブ化」の「サイト」レイヤーでサンドボックスおよびページの編集をアクティブ化します。
ホーム・ページで、「自分のクライアント・グループ」→「クイック処理」→「HCMエクスペリエンス設計スタジオ」に移動します
「トランザクション設計スタジオ」タブをクリックします。
次のいずれかの処理を選択します。
- 採用 - ジョブ・オファーの作成および編集
- 採用 - ジョブ応募におけるジョブ・オファーの表示
- 「採用」-ジョブ・オファーの表示および管理
「追加」をクリックして、オファー・フレックスフィールドを表示するルールを作成および構成します。
「基本詳細」セクションで、ルールの名前と説明を入力します。
「リージョンの表示または非表示」セクションで、「追加情報」が「表示」に設定されていることを確認します。
「ページ属性」セクションで、「追加情報」はデフォルトで選択されています。選択したオファー・フレックスフィールドを表示するには、「ジョブ・オファー付加フレックスフィールド」を「表示可能」に設定します。
「編集」アイコンをクリックします。
- フレックスフィールド・コンテンツ・コード: グローバル・コンテキストまたは特定のコンテキストを選択します。
- フレックスフィールド属性: 特定のフレックスフィールドを選択します。
- フィールドを表示し、入力する必要があるかどうかを構成します。
「完了」をクリックします。
「保存して閉じる」をクリックします。

ジョブ・オファー・アサイメント・フレックスフィールドの構成

ジョブ・オファー内で様々なタイプのフレックスフィールドが使用可能であり、「オファー」ページの様々なセクションに表示されます。アサインメント・フレックスフィールド(PER_ASG_DF)は、オファー・ページの「アサイメント情報」セクションに表示されます。採用された場合、各候補者のアサイメントで値が使用可能になります。

グローバル・セグメントとコンテキスト依存セグメントの両方に対して、次のフレックスフィールドを定義できます。

50テキスト・フレックスフィールド
20数値フレックスフィールド
15の日付フレックスフィールド

ジョブ・オファー・アサイメント・フレックスフィールドを構成する主なステップは次のとおりです。

ジョブ・オファー・アサイメント・フレックスフィールドを構成します。
ジョブ・オファー・アサイメント・フレックスフィールドを表示します。

ジョブ・オファー・アサイメント・フレックスフィールドの構成

最初にジョブ・オファー・アサイメント・フレックスフィールドを構成する必要があります。

「設定および保守」作業領域で、「付加フレックスフィールドの管理」タスクを検索します。
「付加フレックスフィールドの管理」ページで、フレックスフィールド・コードPER_ASG_DFを検索します。フレックスフィールド・アサインメント属性が表示されます。
「処理」メニューで、「編集」をクリックします。
「グローバル・セグメント」セクションには、コンテキストに関係なく、すべてのアサインメントおよびオファー・アサインメントで使用可能なフレックスフィールドが表示されます。各行には、使用可能な回答オプションを制御する値セットと、そのページにラベルを付けるためのプロンプトが表示される場合があります。「作成」アイコンをクリックして、必要な新しいグローバル・フレックスフィールドを追加します。
「コンテキスト・セグメント」セクションには、ユーザーが目的のコンテキストを選択した後、特定のアサインメントおよびオファー・アサインメントで使用可能なフレックスフィールドが表示されます。各行には、値セットとプロンプトを表示できます。「作成」アイコンをクリックして、必要なコンテキスト・フレックスフィールドを追加します。このセクションの上部にあるメニューで別の値を選択してコンテキストを変更し、追加のフレックスフィールド・セットを表示し、必要に応じて拡張できるようにします。
「保存して閉じる」をクリックします。
ジョブ・オファー付加フレックスフィールド・ページに戻ったら、「フレックスフィールドのデプロイ」をクリックします。

ジョブ・オファー・アサイメント・フレックスフィールドの表示

トランザクション設計スタジオを使用して、次のオファー処理を使用して、オファー・アサインメント・フレックスフィールドを表示するルールを作成します。

「採用 - ジョブ・オファーの作成および編集」には、「採用」作業領域でジョブ・オファーを作成中にオファー・フレックスフィールドが表示されます。
「採用 - ジョブ応募におけるジョブ・オファーの表示」には、「採用」作業領域のジョブ応募の「オファー」タブにオファー・フレックスフィールドが表示されます。
「採用 - ジョブ・オファーの表示および管理」では、「ジョブ・オファーの管理」クイック・アクションでオファーにオファー・フレックスフィールドが表示されます。

「設定および処理」メニュー→「ページの編集」→「サンドボックスのアクティブ化」の「サイト」レイヤーでサンドボックスおよびページの編集をアクティブ化します。
ホーム・ページで、「自分のクライアント・グループ」→「クイック処理」→「HCMエクスペリエンス設計スタジオ」に移動します
「トランザクション設計スタジオ」タブをクリックします。
次のいずれかの処理を選択します。
- 「採用 - ジョブ・オファーの作成および編集」
- 採用 - ジョブ応募におけるジョブ・オファーの表示
- 「採用」-ジョブ・オファーの表示および管理
「追加」をクリックして、オファー・アサインメント・フレックスフィールドを表示するルールを作成および構成します。
「基本詳細」セクションで、ルールの名前と説明を入力します。
「リージョンの表示または非表示」セクションで、「アサイメント情報」が「表示可能」に設定されていることを確認します。
「ページ属性」セクションで、「雇用詳細」を選択します。
選択したアサイメント・フレックスフィールドを表示するには、「アサイメント属性」を「表示可能」に設定します。
「編集」アイコンをクリックします。
- フレックスフィールド・コンテンツ・コード: グローバル・コンテキストまたは特定のコンテキストを選択します。
- フレックスフィールド属性: 特定のフレックスフィールドを選択します。
- フィールドを表示し、入力する必要があるかどうかを構成します。
「完了」をクリックします。
「保存して閉じる」をクリックします。

デフォルト値を取得するためのジョブ・オファー・フレックスフィールドの構成

候補者や採用中の求人についての既存情報から取得されたデフォルト値を使用して、作成するオファーのフレックスフィールドを構成できます。この機能を有効にすると、求人の値またはオファーを受け取る候補者の値に基づいて初期フレックスフィールド値が設定されたジョブ・オファーが作成されます。これにより時間を節約できるとともに、必要な情報を手動で入力した場合に発生しかねないエラーを減らすことができます。

どのオファー・フレックスフィールドにデフォルト値が設定されるかを構成する必要があります。これらのフィールドに影響するSQL問合せを作成する、2つのパラメータを使用できます。

SUBMISSION_ID。これはジョブ応募、そして求人を参照します
PERSON_ID。これはオファー受信者となる候補者を参照します

新規作成オファーに対して求人または候補者からデフォルトの動作を構成するには、オファーのフレックスフィールドが、値の取得元となるフィールドと同じデータ・タイプおよび値セットとして定義されている必要があります。その後、カスタムSQLコードで、望ましい求人フィールドまたは個人フィールドに基づいて、任意のオファーのフレックスフィールドの初期デフォルトを指定できます。

「設定と保守」作業領域で、次の場所に移動します。
- 講義: 採用および候補者エクスペリエンス
- 機能領域: ジョブ・オファー
- タスク: ジョブ・オファーの付加フレックスフィールド
「ジョブ・オファーの付加フレックスフィールド」ページで、既存のフレックスフィールドを選択し、「編集」アイコンをクリックします。
セグメントの編集ページの「初期デフォルト」セクションで、「初期デフォルト・タイプ」フィールドで値「SQL」を選択します。
「デフォルト値」エリアでは、このフレックスフィールドのデフォルト値のソースを構成する必要があります。SQL問合せまたはパラメータ問合せの作成には、次の2つのパラメータを使用できます。
- SUBMISSION_ID。これはジョブ応募、そして求人を参照します
- PERSON_ID。これはオファー受信者となる候補者を参照します
「保存して閉じる」をクリックします。

「デフォルト値」領域に貼り付けることができるSQL問合せの例を次に示します。この例の目的は、オファーに関連する求人を識別し、「属性番号1」のフレックスフィールドの現在の値を現在のオファーのフレックスフィールドに取得することです。

SELECT REQ.ATTRIBUTE_NUMBER1 FROM IRC_REQUISITIONS_B REQ, IRC_SUBMISSIONS SUB

WHERE REQ.REQUISITION_ID = SUB.REQUISITION_ID

AND SUB.SUBMISSION_ID = :{PARAMETER.SUBMISSION_ID}

関連項目

自動完了ルールの開始

ジョブ・オファー承認ルールの構成

どのオファー関連フィールドも、候補者のジョブ・オファーの承認に招待された人や特定の状況についての決定に使用できます。

たとえば、「Proposed Assignment Details.Business Unit」トークンに基づいて、1レベルまたは2レベルの承認者がオファーのビジネス・ユニットに応じて適している場合があります。または、トークン「Offer Details.Is Custom Resolved Template」または「Offer Details.Is OfferLetter Text1 Null」を使用して、特定の候補者に調整されたオファー・レターに対して追加の承認者を追加できます。

候補者に選択された標準オファー・レターに追加のテキストが追加された場合、「Offer Details.Is OfferLetter Text1 Null」および「Offer Details.Is OfferLetter Text2 Null」のいずれかまたは両方の属性を使用する承認ルールを作成します。
標準トークンを解決する方法、またはそれらを保持する方法を使用して、オファー・レター全体を変更または置換した場合は、「Offer Details.Is Custom Resolved Template」または「Offer Details.Is Custom Offer Template」のいずれかの属性を使用する承認ルールを作成します。

オファーおよびオファーのアサイメントでグローバル・セグメントとして定義されているフレックスフィールドに基づいて、およびオファーの採用対象の求人でグローバルおよびコンテキストベースのセグメントとして定義されているフレックスフィールドに基づいて、ジョブ・オファーの承認サイクルを構成できます。これらの承認ルールは、トランザクション・コンソールを使用せずに、ワークリスト内で構成する必要があります。

また、オファーの採用対象のジョブ求人に関する情報に基づいて、ジョブ・オファー承認ルールを構成することもできます。これらの承認ルールは、トランザクション・コンソールを使用して構成できます。

さらに、ジョブ・オファーの承認ルールを構成する際に、承認者のリストの一部として担当者を追加できます。トランザクション・コンソールで候補者の提示担当者を構成して、候補者のオファーを承認できます。

フレックスフィールドに基づくジョブ・オファー承認ルールの構成

フレックスフィールドを含むオファー承認ルールは、トランザクション・コンソールを介してではなく、ワークリスト内で構成する必要があります。

ホーム・ページで、「通知」アイコンをクリックします。
「通知」ページで、「すべて表示」をクリックします
「ワークリスト」をクリックします。
名前の横にあるメニューで、「管理」を選択します。
「タスク構成」タブをクリックします。
タスクOfferApprovalHumanTaskを検索します
タスクが表示されたら、タスク名をクリックします。
「編集」アイコンをクリックします。
フレックスフィールドが変更されたことを示すメッセージが表示されます。同期の開始をクリックします。
同期が完了したら、OfferApprovalHumanTaskタスクを再度クリックします。
「割当先」タブをクリックします。
「ジョブ・オファー承認者」ボックス内の青いドットをクリックし、ルールに移動します。
SupervisoryRulesListSetをクリックすると、作成されたルールが表示されます。
「IF」セクションで「ルール1」に移動し、「検索」アイコンをクリックします。
条件ブラウザ・ウィンドウで目的のフレックスフィールド検索します。次のものを使用できます。
- OfferDff
- RequisitionDff
- ProposedAssignmentDff
条件を作成します。
「検証」をクリックします。

ジョブ求人情報に基づくジョブ・オファー承認ルールの構成

これらのステップを実行して、オファーの採用対象のジョブ求人に関する情報に基づいて、ジョブ・オファー承認ルールを構成できます。

「ツール」作業領域に移動します。
「トランザクション・コンソール」をクリックします。
「承認ルール」タブをクリックします。
「ジョブ・オファーの承認」プロセスを選択し、「編集」アイコンをクリックします。
ルールをクリックし、「編集」アイコンをクリックします。
ルールを再度クリックし、「選択の編集」アイコンをクリックします。
「承認ルール: 条件式の編集」ウィンドウで、最初のメニューで文を選択します。
2つ目のメニューで、「求人詳細」を選択し、関連するメニューから求人関連フィールドを選択します。
3つ目のメニューで、目的の演算子を選択します。例: >、<、==、contains、startsWith。
承認ルールの残りの式を選択します。

担当者によるジョブ・オファーの承認の構成

これらのステップを実行し、ジョブ・オファーの承認ルールを構成する際に、承認者のリストの一部として担当者を追加できます。候補者の提示担当者を構成して、内部候補者のオファーを承認できます。

「ツール」作業領域に移動します。
「トランザクション・コンソール」をクリックします。
「承認ルール」タブをクリックします。
「ジョブ・オファーの承認」プロセスを選択し、「編集」アイコンをクリックします。
ルールを作成し、担当者承認者を設定します。
「担当者」セクションで、フィールドを次のように設定します。
- 処理タイプ: 承認要
- 担当者タイプ: 採用
- 次の担当者: 候補者の提示担当者
「送信」をクリックします。

ジョブ・オファー承認の管理階層の構成

HCMでは、各従業員は複数のアサイメントを持つことができ、各アサイメントには独自の管理チェーンがあります。従業員のすべてのアサイメントが「ディレクトリ」作業領域(「自分」→「ディレクトリ」)に表示されます。以前のように常にプライマリ・アサイメントに依存するのではなく、承認に使用される独自の管理階層を各アサイメントに設定できます。管理者は、プライマリ・アサイメント・レコードやその他の割当てをオファー承認プロセスに使用できます。また、オファー承認の承認チェーンの採用担当者を選択することもできます。

「ツール」作業領域に移動します。
「トランザクション・コンソール」をクリックします。
「承認ルール」タブをクリックします。
「ジョブ・オファーの承認」プロセスを選択し、「編集」アイコンをクリックします。
「管理階層」ボックスをクリックします。
ページ下部の「管理階層」セクションに移動します。
承認チェーン・フィールドで、次のいずれかのオプションを選択します。
- 採用マネージャ
- 要求者
- 採用担当者
- ユーザー
「採用マネージャ」または「採用担当者」を選択した場合は、アサイメント・タイプを選択できます。
- プライマリ・アサイメント階層の使用(デフォルト値)
- 現行アサイメント階層の使用

ジョブ・オファー承認者の通知の構成

承認者は、候補者にドラフトされたジョブ・オファーに関する決定を求めるEメール通知を受信します。これらの通知は、他のすべての承認と同様に、BI Publisherによって承認者ごとに生成されます。

オファー承認の標準通知には、提示されたアサイメント詳細、給与、その他の報酬、候補者が応募した求人など、ジョブ・オファーに関するすべての関連情報が含まれます。

セキュリティの観点から、承認者は、通知の各セクションを表示するには、次の職務ロールと集計権限が必要です。

ジョブ・オファーの表示
ジョブ・オファー給与の表示
ジョブ・オファーその他の報酬の表示
ジョブ求人の表示

承認者は、承認リクエストの詳細を表示するためにオファー・チームに含める必要はありません。候補者がユーザーのデータ・ロールの個人セキュリティ・プロファイル内にあるかぎり、候補者のオファー値がユーザーに表示されます。

標準通知には、承認者が候補者に拡張されるオファー・レターを表示できるリンクも含まれます。特定のトークンは次のとおりです。

P_OFFERLETTERTEMPLATENAME: このトークンには、リストから選択したオファー・レターの名前が表示されます。候補者のオファーが採用担当者によって調整されている場合は、カスタム・アップロードされたオファー・レター・ファイル名が表示されます。
P_OFFERLETTERDEEPLINK: このトークンには、オファー・レターへのディープ・リンク用のURLが含まれます。承認者のURLとして表示することも、承認者がレター名をクリックしたときにリンク先として通知で作成することもできます。

ジョブ・オファーを候補者に自動的に提示

オファーが承認されると、候補者選択プロセスを構成して、ジョブ・オファーを候補者に自動的に提示できます。オファーは、ジョブ応募が「オファー - 承認済」ステータスになると候補者に自動的に提示されます。

「設定と保守」作業領域で、次の場所に移動します。
- 講義: 採用および候補者エクスペリエンス
- 機能領域: 候補者ジョブ応募
- タスク: 候補者選択プロセス構成
「候補者選択プロセス構成」ページで、プロセスをクリックします。
プロセス・ページで、「オファー」フェーズをクリックします。
「フェーズの状態」セクションで、「承認済」状態を選択します。
「処理」メニューで「オファーの延長」アクションを選択し、「追加」を選択します。
オファーを自動的に提示するまでの遅延時間数を定義します。0と入力すると、各候補者のステータスがオファー - 承認済に達すると、アクションが即座に実行されます。オファーを遅延して提示するように設定されている場合、ユーザーにバナー・メッセージが表示され、オファーが自動的に延長される日時のメッセージが示されます。その時間になると、ユーザーが変更しないかぎりオファーは延長されます。たとえば、採用担当者が候補者を拒否したり、その間にオファーを再作成した場合、オファーは自動的に延長されず、バナーは表示されなくなります。書き直されたオファーが再度承認されると、新しい自動提示がスケジュールされます。
「続行」をクリックします。
他の処理と同様に、「オファーの延長」処理を実行するために満たす必要がある条件を定義できます。
処理に一意の名前を入力してください。
「保存して閉じる」をクリックします。

「オファーの延長」処理がトリガーされると、スケジュール済プロセスが実行され、構成された遅延に基づいて処理が実行されます。

候補者選択プロセスに複数の「オファーの延長」処理を追加して、様々な条件および構成を使用してオファーを延長できます。「オファーの延長のバイパス」オプションを有効にした場合、「オファーの延長」処理は使用できません。

募集人数に一致する人材募集に対して十分な採用が行われた場合でも、オファーは自動的に延長されます。求人の採用数に基づいてオファーを自動的に延長することを防ぐ場合は、条件付きのFastFormulaを使用できます。デフォルトでは、ジョブ・オファーを延長する自動進行は、求人に対して採用された候補者の数をチェックしません。ただし、これらのオファーが承認のために最初に送信されると、求人件数がチェックされ、オファーを多数の候補者まで延長する可能性が大幅に減少します。オファーの自動延長を制限するFastFormulaを構成するには、次の使用可能なメソッドを検討してください。

データベース・アイテム(DBI)を使用して条件を定義します。求人の空席数(IRC_CSP_REQ_NUMBER_TO_HIRE)が現在の採用数(IRC_CSP_REQUISITION_NUMBER_OF_HIRES)より多い場合。
関数を使用した条件の定義: 受諾済状態を通過したジョブ応募の数が求人の空席数より少ない場合。

候補者へのオファーの延長のバイパス

ユーザーが候補者へのジョブ・オファーの延長をバイパスできるように、候補者選択プロセスを構成できます。このパスは、オファー - 承認済からオファー - 受諾済に直接進みます。これは、オファーが延長または受諾された候補者やその他への通知、候補者へのオファー・レターの表示、候補者のオファー受諾および付随する電子署名の取得など、標準のオファー延長済機能がスキップされることを意味します。

「設定と保守」作業領域で、次の場所に移動します。
- 講義: 採用および候補者エクスペリエンス
- 機能領域: 候補者ジョブ応募
- タスク: 候補者選択プロセス構成
「候補者選択プロセス構成」ページで、プロセスを作成するか、既存のプロセスを開きます。
「オファー」フェーズをクリックします。
「編集」を「フェーズ詳細: オファー」の横でクリックします。
オプション「オファーの延長のバイパス」で「はい」を選択します。
「保存」をクリックします。

候補者のオファー受入を確認するための通知の作成

オファーが提示されないため、オファーが提示されたことを通達する標準のコミュニケーションは候補者とオファー・チームに送信されません。ただし、候補者または他のユーザーに通知を送信して候補者の受入を知らせるように構成できます。最初に通知を作成し、その通知を受け取るユーザーを定義します。

通知を作成するには:

「設定と保守」作業領域で、次の場所に移動します。
- 講義: 採用および候補者エクスペリエンス
- 機能領域: 採用および候補者エクスペリエンス管理
- タスク: 採用コンテンツ・ライブラリ
「採用コンテンツ・ライブラリ」ページで、「作成」をクリックします。
コンテンツ項目の作成ページで、名前とコードを入力し、カテゴリ「自動ジョブ応募通知」を選択して、内部候補者、外部候補者、またはその両方について通知を行うかどうかを指定します。
メッセージの件名とテキストを入力します。リッチ・テキスト機能は、テキストの書式設定に使用できます。求人の名前(オファーの名前より望ましい)、就業事業所、提示開始日などのトークンを含めることができます。

ノート: トークンJobOfferDetailsCandidateDeepLinkURLを使用します。採用担当者がオファーの作成中にオファー・レターを関連付けなかった場合は、その候補者が受信するこのメッセージではリンクが機能しません。
他のコンテンツ項目と同様に、他のフィールドに入力します。
「保存してアクティブ化」をクリックします

通知を受信するユーザーを定義するには、次の手順に従います。

「設定と保守」作業領域で、次の場所に移動します。
- 講義: 採用および候補者エクスペリエンス
- 機能領域: 候補者ジョブ応募
- タスク: 候補者選択プロセス構成
「候補者選択プロセス構成」ページで、プロセスをクリックします。
「オファー」フェーズをクリックします。
「フェーズの状態: オファー」セクションで、「通知の送信」アクションを「受諾済」状態に追加します。
「処理: 通知の送信」ページで、「採用担当者」や「採用マネージャ」、あるいはその両方の通知を受け取る採用チームのメンバーを選択します。アラート・コンポーザで構成された標準のレビュー通知を受信します。
内部候補者および外部候補者に対して作成した通知を選択します。
「続行」をクリックします。
条件を追加します。
「保存して閉じる」をクリックします。

候補者が受諾済オファー・レターを表示可能

オファーが提示されないため、候補者は応答する前にオファーを表示できません。ただし、候補者がオファーを受諾した後、その候補者に参照のためオファー・レターを提供できます。オファーのドラフト時にオファー・レターが構成されている場合でも、通知内のハイパーリンクから候補者へのアクセスを提供できます。そのオファー・レターがライト電子署名セクションを含めるように構成されていた場合、候補者は、ジョブ応募を承認済から受諾済の状態に移動したユーザーによって、そのオファー・レターが受諾されたことを確認します。オファーを受け入れた後の内部候補者は、「自分」→「現在のジョブ」→「ジョブ・オファー」作業領域または受信した通知のリンクをクリックして、関連するオファー・レターを表示できます。外部候補者は、通知内のリンクを使用して自分のオファーにのみアクセスできます。

ジョブ・オファーを辞退する事由の定義

候補者がジョブ・オファーを辞退したときにフィードバックを収集できます。候補者は事由のリストが構成されている場合は事由を選択し、任意のコメントを入力できます。このような情報から、組織は採用チームにとって即時的にも長期的にも貴重なデータを収集できます。候補者がジョブ・オファーを辞退したときに採用担当者は即座に通知を受け、ジョブ応募を取り下げることができます。この通知に含まれている情報に基づいて、採用担当者はその候補者に対し必要な処理をすぐに実行できます。長期的には、これらの回答から組織の候補者選定に関する意思決定や問題点について状況が明らかになります。なぜ有力な候補者はジョブ・オファーを辞退したのか。この情報を取得し分析してトレンドを理解することで、組織の将来のオファーおよび将来の採用戦略が向上します。

この機能を有効にするには、次の主なステップを実行する必要があります。

オファー辞退の事由を定義します。
候補者選択プロセスの構成中に「取下げ時の候補者事由およびコメントの許可」オプションを使用可能にします。
自由形式テキストの「コメント」フィールドとともに事由のメニューが必要な場合は、オファー - 取り下げ済ステータスに事由グループを添付します。
ジョブ求人に候補者選択プロセスを追加します。
アラート・コンポーザで通知を構成します。

事由の定義

最初に、ジョブ・オファー辞退の事由を定義します。候補者ライフサイクルの様々な時点で使用されている既存の事由を使用できます。新しい事由を作成し、これらの事由を事由グループに配置することもできます。

詳細は、「ジョブ応募を否認および取下げする事由の定義」を参照してください。

候補者選択プロセスの構成

候補者選択プロセスの「取下げ時の候補者事由およびコメントの許可」オプションを使用可能にする必要があります。

「設定と保守」作業領域で、次の場所に移動します。
- 講義: 採用および候補者エクスペリエンス
- 機能領域: 候補者ジョブ応募
- タスク: 候補者選択プロセス構成
既存のプロセスを開きます。
「オファー」フェーズをクリックします。
「フェーズ詳細: オファー」セクションに移動し、「編集」アイコンをクリックします。
「取下げ時の候補者事由およびコメントの許可」オプションを「はい」に設定し、候補者がジョブ・オファーを辞退するときに自由形式のコメントを入力できるようにします。候補者はこのジョブを辞退すると見なされ、自身を「候補者により取下げ済」に移動します。
「保存」をクリックします。
「フェーズの状態: オファー」セクションに移動します。
(オプション)「候補者により取下げ済」状態の「事由グループ」メニューをクリックし、オファー辞退の理由が含まれているグループを選択します。「候補者により取下げ済」状態に事由グループが関連付けられていない場合、事由のリストは表示されませんが、ジョブを辞退するときに候補者は自由形式テキストのコメントを入力できます。

ジョブ求人への候補者選択プロセスの追加

候補者がジョブ・オファーを辞退した理由をジョブ・オファーで収集するには、このフィードバックを受け入れるように候補者選択プロセスが構成されている求人に関連付ける必要があります。

通知の構成

候補者がジョブ・オファーを辞退すると、標準通知をオファー・チームに送信できます。

IRC_JobOffer_Declined_Internal
IRC_JobOffer_Declined_External

候補者が指定したフィードバックを含めるようにこの通知を構成できます。その場合は、次のトークンを追加します。

JobOfferCandidateDeclineReason
JobOfferCandidateDeclineComment

候補者のHRフェーズへの自動移動

採用ライフサイクル全体の最後に、候補者は、手動で、または候補者選択プロセスの最終HRフェーズに自動的に進める必要があります。候補者選択プロセスを構成すると、「HRに移動」処理を自動化できるため、ジョブ応募が候補者選択プロセスの特定の時点に到達し、選択した条件を満たすと、ジョブ応募が自動的にHRフェーズに移動されます。たとえば、経歴チェックの後に候補者を自動的に前進させることができます。

「HRに移動」アクションは、次の場合にのみ追加できます。

オファー - 受諾済フェーズおよび状態。
オファー・フェーズとHRフェーズの間に含まれるカスタム・フェーズの非終了状態。
オファー・フェーズとHRフェーズの間に含まれるカスタム・フェーズのフェーズ・レベルのイベント。

「設定と保守」作業領域で、次の場所に移動します。
- 講義: 採用および候補者エクスペリエンス
- 機能領域: 候補者ジョブ応募
- タスク: 候補者選択プロセス構成
「候補者選択プロセス構成」ページで、選択プロセスを作成し、既存のドラフト・プロセスを選択します。
「HRに移動」処理をオファー - 受諾済に追加するか、または「オファー」と「HR」のフェーズ間のカスタム・フェーズ、あるいはそのフェーズの非終了状態に追加します。
「処理: HRに移動」ページで、条件を追加します。
- 「事前定義済の追加」をクリックして、事前定義済の条件を選択します。
- 「FastFormulaの追加」をクリックして、条件として使用されるFastFormulaを選択します。
「保存して閉じる」をクリックします。

HRへの移動中のエラーの通知

候補者を自動的にHRフェーズに進めようとするときに、問題が発生する可能性があります。移動を手動で実行すると、採用担当者はエラーが発生したかどうかを確認できます。移動が自動的に設定されると、候補者のジョブ応募に問題があり、処理中にエラーになったときに通知が自動的に送信されます。この標準通知はアラート・コンポーザで使用できます。

IRC_Move_To_HR_Error: HRへの移動中のエラー

この通知を構成できます。たとえば、通知はデフォルトで採用担当者に送信されますが、このような異常な状況の解決について最もよく知っている人事担当者などの他の受信者を追加できます。

これらのトークンは、通知で各エラーの特定詳細を表示するために使用されます。

OfferErrorMessageText
OfferErrorDetailText

また、「ジョブ・オファーの管理」というクイック・アクションにユーザーを送信することもできます。これは、HR担当者がシードされたロールを持つユーザーが使用できます。この通知がこのクイック処理領域に到達する権限を持つ受信者に移動するように構成されている場合は、次のトークンを追加できます。

HRJobOfferListDeepLinkURL: このトークンは、ユーザーをオファー・リストに移動します。
HRJobOfferDetailDeepLinkURL: このトークンは、エラーのある特定のオファーに直接ユーザーを取得します。

ジョブ・オファー後の候補者重複チェックおよびマージ

候補者がジョブ・オファーを受諾し、HRフェーズに移動すると、その候補者が他の候補者ではなくデータベース内の任意の個人と重複しているかどうかを検証するチェックが自動的に行われます。

HRフェーズに移行すると、外部候補者は、すべての就業者、前就業者、派遣就業者、前派遣就業者に対しても、データベースに情報がある連絡先および受益者に対してもチェックできます。このチェックは、採用ライフサイクルで以前に実行可能な重複をチェックする別の方法を補完したものです。この前のチェックでは、この候補者を他のすべての候補者および前就業者と比較して、潜在的な重複が検索されますが、現在の就業者に対しては比較されません。この前のチェックはユーザーが起動するか、候補者選択ワークフローで自動的に実行するように構成できます。

社外候補者のジョブ・オファーを作成する前に、採用ユーザーは候補者のレコードとジョブ応募を任意の前就業者または候補者とマージできます。候補者がデータベースに別のレコードを追加しているとユーザーが判断した場合は、このことが重要です。ただし、ジョブ・オファーが作成された後、重複チェックとマージ機能が自動化され、重複の可能性を見つけるために使用される基準、就業者および前就業者に対してチェックが実行され、使用される基準が若干異なります。

候補者および国別識別子一意性

企業プロファイル・オプション「国別識別子一意性検証モード」を使用して、会社全体のすべての就業者および個人に対する国別ID番号の一意性を確認できます。この値を選択すると、同じ国別識別子を使用して同じ個人を2回誤って追跡することがなくなります。処理待ち就業者および就業者を作成または更新する場合、このオプションを構成するときに国別識別子を一意である必要がありますが、候補は影響を受けません。

採用では、候補者は自分の国別識別子を提供できます。これは、ジョブ応募プロセスの一部である場合、または必要な権限を持つ採用チーム・ユーザーが指定することができます。国民ID番号は、一意でない場合でも入力できます。固有でない国別識別子は、通常、この候補者にすでにデータベースにレコードがあることを意味します。レコードは、前就業者または現在の就業者です。ジョブ応募のフローは中断されず、入力した番号を修正する要求は、必須フィールドとして構成されている場合でもありません。

ただし、プロファイル・オプション「国別識別子一意性検証モード」が有効になっている場合、採用を選択した候補者は、一意でないID番号を使用して処理待ち就業者に変換できません。候補者は、国民ID番号を何も指定せずに処理待ち就業者になることがあります。ただし、この番号は、処理待ち就業者レコードを完了して就業者に変換するために、要求するように構成されると考えられます。新しい処理待ち就業者のID番号が既存の個人の重複として入力されている場合、この値をその処理待ち就業者レコードに保存することはできません。人事担当者は手動で状況を処理する必要があります。

重複チェックおよび個人作成

ジョブ・オファーの作成前に外部候補者が前就業者または候補者の重複であることが検出された場合、ユーザーはその個人に候補者のレコードおよびジョブ応募をマージできます。候補者がデータベースに別のレコードを追加しているとユーザーが判断した場合は、このことが重要です。ただし、ジョブ・オファーの作成後は、ジョブ・オファーの詳細を保持するために、重複チェックとマージ機能が若干異なります。

この自動化された機能によって、ジョブ・オファーの後に重複がチェックされます。ジョブ応募プロセス中に生年月日または国別識別子を外部候補者に提供する必要があることを考慮してください。これらの値により、重複チェックが構成されている場合、処理待ち就業者を作成する前に、データベース内の既存の個人とのよりよい一致を見つけることができます。

国別識別子と生年月日は機密フィールドであるため、候補者がオファーを受諾した後、カスタム・フェーズでこれらのフィールドを収集するようにアプリケーション・プロセスを構成できます。ただし、ジョブ・オファーの後、この候補者と重複レコードをマージする機会は、HRに移動中にのみです。

HRフェーズに移動した時点で、この機能は、重複レコードの構成済定義に依存して、候補者がデータベース内の既存の個人と重複している可能性があるかどうかを確認できます。一致する候補が1つ以上見つかった場合、候補者のジョブ応募はHRの処理進行中ステータスにスムーズに移動しません。ユーザーには、ステータスが「HR -処理中にエラーが発生しました」に移動されたことが通知されます。ユーザーは、次の方法で情報を処理するかどうかを決定する必要があります。

新しく検出された重複した個人レコードを使用して候補者レコードをマージし、既存の就業者に対して候補者のオファーを再作成します。
処理待ち就業者を作成して、元の候補者に進みます。

このチェックによって可能性のある一致が特定されない場合、外部候補者はHRへの移行時に、新しい就業者になる方法に従って、処理待ち就業者に変換されます。

重複が存在しても現時点で見つからない場合、候補者情報が不完全または不適切であるために、HR担当者は状況を手動で処理する必要があります。これには、候補者のオファーに似た既存の個人レコードへの新規アサイメントの直接作成、この不要な候補者ジョブ応募の検討からの取下げ、候補者レコードの削除、求人の手動クローズなどがあります。

関連項目

HRフェーズに移動する候補者重複チェックの構成

外部候補者のHRフェーズへの移動時に採用で重複をチェックするには、次の2つの設定を構成する必要があります。

企業プロファイル・オプション「個人作成重複チェック」では、採用プロセスの外部で個人が作成されたときにチェックされます。
「「HRに移動」での重複チェック」採用設定。このチェックは採用ライフサイクルの終了に適用されます。

個人作成重複チェック設定の構成

まず、既存の個人レコードと候補者レコードを比較するときに重複できる情報の種類を定義する必要があります。これを行うには、企業プロファイル・オプション「個人作成重複チェック」が構成されていることを確認します。このオプションは、マネージャ、HR担当者または他のユーザーが従業員を直接雇用または更新したり、派遣就業者を入力または更新したり、HCMデータ・ローダーを使用した場合に重複を検索するためにすでに使用されています。「HRに移動」処理における採用候補者の重複のチェックも行います(構成されている場合)。

ホーム・ページで、「自分のクライアント・グループ」→「クイック処理」→「詳細の表示」に移動します。
「企業HCM情報の管理」をクリックします。
「企業情報」セクションで、「個人作成重複チェック」の設定を構成します。

この表は、「個人作成重複チェック」オプションの構成時に使用可能なオプションを示しています。

オプション	設定名	重複が検出される条件
1	なし	候補者の照合のチェックは実行されません。
2	国別ID国タイプID	候補者の国別識別子が同じ国およびタイプ内の個人の国別識別子と一致する場合。候補の値がNULLの場合、重複は検出されないことに注意してください。
3	姓、名のイニシャル、DOBまたはNID国タイプID	候補者の国別識別子が同じ国およびタイプ内の個人の国別識別子と一致する場合、氏名または生年月日に一致するかどうかは関係ありません。または、NIDが一致するかどうかやNULLであるかには関係なく、姓と名のイニシャルが一致し、かつ候補者の生年月日が個人の生年月日と一致するか、生年月日がNULLである場合。
4	姓、名のイニシャル、DOB、性別またはNID国タイプID	候補者の国別識別子が同じ国およびタイプ内の個人の国別識別子と一致する場合、氏名または生年月日に一致するかどうかは関係ありません。または、NIDが一致するかどうかやNULLであるかには関係なく、姓と名のイニシャルが一致し、かつ候補者の生年月日が個人の生年月日と一致するか、生年月日がNULLである場合。
5	姓、名、DOB、性別またはNID国タイプID	候補者の国別識別子が同じ国およびタイプ内の個人の国別識別子と一致する場合、氏名、生年月日、性別のいずれに一致するかは関係ありません。または、姓と名の完全一致があり、候補者の生年月日と性別が個人のまたはnullの場合は、NIDが一致するかどうか、またはNULLかどうかに関係なく一致します。
6	NID	オプション2と同じ動作ですが、異なる国の国別識別子に一致する番号が含まれている場合、追加の重複が見つかることがある点が異なります。
7	姓、名のイニシャル、生年月日または国別ID	オプション3と同じ動作ですが、異なる国の国別識別子に一致する番号が含まれている場合、追加の重複が見つかることがある点が異なります。この設定は、オプションが明示的に選択されていない場合のデフォルトの動作です。
8	姓、名のイニシャル、生年月日、性別または国別ID	オプション4と同じ動作ですが、異なる国の国別識別子に一致する番号が含まれている場合、追加の重複が見つかることがある点が異なります。
9	姓、名、生年月日、性別または国別ID	オプション5と同じ動作ですが、異なる国の国別識別子に一致する番号が含まれている場合、追加の重複が見つかることがある点が異なります。

「「HRに移動」での重複チェック」設定の構成

HRフェーズに移動した外部候補者に企業の個人作成重複チェックを拡張するには、採用内の2番目の設定も有効にする必要があります。これにより、新規採用または新規採用候補者が、処理待ち就業者または処理待ち雇用関係の定義に従って重複の可能性がある場合、これらのユーザーが採用プロセスの終了時にその後の進路を決定できるまでの間、これらの関係が自動的に作成されるのが防止されます。

「設定と保守」作業領域で、次の場所に移動します。
- 講義: 採用および候補者エクスペリエンス
- 機能領域: 採用および候補者エクスペリエンス管理
- タスク: 企業採用および候補者エクスペリエンス情報
「HRに移動」セクションの「重複チェック」に移動します。
次のオプションから選択します。
- なし - 重複の検証なし
- すべての候補者に「個人作成重複チェック」を使用
- 生年月日および国別識別子がある候補者に「個人作成重複チェック」設定を使用

候補者が重複とマージされた後、オファーおよびライフサイクルを再訪問

採用担当者と人事担当者は、候補者と、一致する可能性のある任意の従業員、前従業員、派遣就業者、前派遣就業者を組み合せることを決定できます。重複として識別できる他のPersonタイプとのマージは自動的には実行できません。連絡先、受益者、またはその他のタイプの個人が可能性のある一致と判断された場合、人事担当者は、このジョブ応募を手動で管理する必要があります。

マージを決定すると、候補者のプロファイル情報が選択した個人レコードとマージされ、候補者の既存のジョブ応募が選択した個人に転送されます。これには、現在のジョブ・オファーが作成、承認、および受諾されたジョブ応募が含まれます。

候補者のジョブ・オファー詳細は、転送されたジョブ応募で再作成する必要があり、すべての詳細を再訪問して、選択した個人にすべて適切であることを確認する必要があります。外部候補者または他の適格基準に特に適している場合にのみ、オファーの値で必須の変更を行う必要があります。ユーザーがオファーをレビューした後、ライフサイクルの残りの一部またはすべてを省略するかどうかを決定するために様々な選択肢を使用できます。

再作成された各ジョブ・オファーを送信すると、ユーザーはライフサイクルのHRフェーズに直接戻って、すべての介入状態およびカスタム・フェーズをバイパスするかどうかを決定できます。
この個人の新規オファーのライフサイクルをバイパスしない場合、これらの再作成されたオファーを異なる方法で処理するようにオファー承認ルールを構成できます。フィールドMERGE_FLAGは、承認領域で使用するために存在します。これは、重複レコードを識別した後にオファーがこのマージ・プロセスの結果であることを示します。承認ルールは、代替の承認者セットを通じてこれらのオファーを送信するように構成することも、承認者がまったく送信しないように設定することもできます。
同様に、これらの再作成オファーは、個々のユーザーがライフサイクルをバイパスしない場合でも、HRフェーズに迅速に移動できます。フィールドMERGE_FLAGは、FastFormulaで使用するために存在します。これは、重複レコードを識別した後でオファーがこのマージ・プロセスの結果であることを示します。候補者の選考プロセス内では、重複が見つかる前にHRに異動したマージ済候補者に自動昇格を設定できます。たとえば、再作成されたオファーは承認後すぐに延長されるように構成でき、改定されたオファーを受け入れた直後にHRフェーズに直接移動できます。

ノート: 候補者が応募した求人は、既存の個人が重複していることを誰かが認識する前にすでに充足している可能性があります。その場合、採用担当者が2つのレコードをマージしようとすると、最初に調達依頼を再オープンする必要があることを示すエラー・メッセージが表示されます。新しく作成されたオファーが再びHRフェーズに移動すると、このマージされた個人は、元の候補者が受け取った人材募集に再度入力されます。

ジョブ・オファーとジャーニについて

ジャーニは、候補者が採用プロセスの最後に到達し、新しいアサイメントを開始する準備など、個人的な状況に変更がある場合に実行される標準タスクのセットです。

候補者のライフサイクルの初期段階でジャーニを割り当てることは効果的ではありません。外部候補者は、処理待ち就業者になるまで割り当てられたジャーニにアクセスできません。社内モビリティの候補者は、採用プロセスを続行すると、オファーの受諾をやめることも終了しないこともあります。そのため、候補者のジョブ応募がHRフェーズに移行すると、ジャーニを割り当てるための採用ライフサイクルの適切な時間は終了に近づいています。候補者のライフサイクルのこの時点で多くのアクションが発生し、適切なアクションは「HRに移動」という名前の処理である場合とそうでない場合があります。

候補者がHRフェーズに移行したときのジャーニの割当

成功するすべての候補者は、最終的に採用ライフサイクルのHRフェーズに移行されます。

外部候補者がHRフェーズに進行すると、「HRに移動」と「処理待ち就業者の追加」の両方の処理が新しい採用に対してトリガーされます。再雇用の場合は、「HRに移動」と「処理待ち雇用関係の追加」の両方のアクションがトリガーされます。外部候補者の「HRに移動」処理に基づいてジャーニを構成しないことをお薦めします。かわりに、「処理待ち就業者の追加」と「処理待ち雇用関係の追加」の処理に基づいて外部候補者のジャーニを構成します。この構成は、候補者がHRフェーズに移動した後に「処理中エラー」の状態で遅延した場合に役立ちます。このジャーニは、処理待ち就業者または雇用関係を作成できるときに問題が解決された後にのみ割り当てられます。

内部候補者がHRフェーズに移行すると、ジョブ応募はHR -手動処理待ちステータスになり、HR担当者が「ジョブ・オファーの管理」作業領域で処理するのを待機します。HR担当者は、オファーで最初に選択した処理(「転送」、「グローバル異動」、「昇格・昇進」など)を使用してオファーの値を変換します。これらのアクションにジャーニが設定されている場合は、HR担当者がオファーに基づいてこのプロセスを送信した後にのみ、内部個人にジャーニが割り当てられます。内部候補者が実際の内部変更が有効になる前にジャーニ・タスクを実行する必要がある場合は、「HRに移動」処理のためのジャーニを構成する必要があります。

ノート: 「HRに移動」という名前の処理のコードはORA_IRC_ACCEPT_JOB_OFFERですが、候補者がジョブ・オファーを受諾したタイミングは、このアクションをトリガーする時点ではありません。オファーが承認され、「HRに移動」処理の前に、時間が経過してカスタム構成フェーズが介入する可能性があります。したがって、受諾するコードに関係なく、候補者のジョブ応募が最初にHRフェーズの任意の状態に変更されると、「HRに移動」処理がトリガーされます。

適格プロファイルを構成することで、採用ライフサイクルのこの時点で1つのジャーニのみが候補者に割り当てられるようにできます。たとえば、「HRに移動」処理が内部候補者に対してのみ行程をトリガーするように構成されていることを確認して、外部の新規採用と再雇用が「処理待ち就業者の追加」処理と「処理待ち雇用関係の追加」処理に基づいてジャーニを受け取るようにできます。

「HRに移動」処理時にトリガーされるジャーニは、ジャーニの開始者に割り当てられたタスクで構成しないでください。これは、通常、「HRに移動」処理には、候補者選択プロセス内で自動的に実行されるとき、またはユーザーが手動で実行したときに開始者がいないためです。

ノート: これらのオファー関連の処理は、ジャーニの割当には適していません。

「オファーの作成」(コードEMPL_OFFER_CREATE)アクションは、新しい下書きのオファーは新しく採用された就業者や新しく転属した就業者に繋がらないかもしれない多くの理由があるため、時期尚早の可能性があります。
オファーに対するすべての変更は更新ではなく訂正であるため、処理「オファーの更新」(コードEMPL_OFFER_CHANGE)は今日の採用では使用されません。

ジャーニと書直し済オファー

ジョブ応募がHRフェーズに移動した後や、処理待ち就業者または就業者が候補者に対して作成された後でさえ、ジョブ・オファーまたはオファー・レターを変更する必要がある場合があります。これは、トランザクションを取り消してからジョブ・オファーを再作成することで実行できます。

処理待ち就業者または就業者トランザクションが取り消されると、そのレコードは削除され、個人は再び候補者になります。つまり、本人または他のユーザーが、その個人に割り当てたジャーニにアクセスすることはできなくなります。ただし、このジャーニは削除されず、そのジャーニで完了したタスクにすべての情報が保持されます。

再作成されたオファーとそのジョブ応募が再度HRフェーズに移動されると、新しい処理待ち就業者および就業者が再作成されます。アクティブのままのジャーニは、その処理待ち就業者または就業者について再度アクセス可能になり、すべてのタスクを続行して完了できます。

ノート: アクティブなジャーニを持つ処理待ち就業者または処理待ち就業者を取り消す場合、そのジャーニをアクティブなままにしない場合は、処理待ち就業者または就業者を取り消す前に、そのジャーニを削除することを検討してください。個人が最初に取消されると、マネージャおよびその他のユーザーは、ユーザー・インタフェースから未処理のジャーニにアクセスする方法がなくなります。

関連項目

ジャーニの使用方法