概念: オンボーディングビジネスプロセスのガイドライン

オンボーディングプロセス内で開始されるタスクの場合、従業員には特定のセキュリティ権限が必要です。これらのタスクを完了するためのアクセス権は、"Employee as Self"
または "Contingent Worker as Self"
セキュリティグループなどのセルフサービスロールを通じて付与されます。これらの "Self-Service" セキュリティグループに割り当てられているセキュリティ権限を評価して、必要なタスクを完了するための適切な権限を持っていることを確認することは非常に重要です。

プロセス開始者

さまざまなアクションを使用して、従業員の " オンボーディング
" ビジネスプロセスを開始できます。表示ステップ: オンボーディングビジネスプロセスの設定。

制限事項

" オンボーディング
" ビジネスプロセスは堅固ですが、考慮すべきいくつかの制限事項があります。

単一のオンボーディングプロセス: 従業員が一度に処理できる アクティブなオンボーディングプロセスは
1 つだけです。すでにアクティブなプロセスに含まれている従業員に対して新しいオンボーディングイベントが開始された場合、その新しいビジネスプロセスイベントは開始されません。

法的準拠: Workday には、応募者に入社前にタスクを割り当てるツールが用意されていますが、法的な助言は提供されません。所属先の組織は、応募者のアクティビティの報酬に関する労働法に準拠する責任があります。

海外赴任/出向のあるフォーム I-9:"海外赴任/出向の開始
" ビジネスプロセスの一部として " オンボーディング
" プロセスが開始された場合、"Complete Form I-9"
ステップは開始されません。

共通ワークフロー

パス 1: 標準的な社外新規採用のオンボーディング

このワークフローは "採用" ビジネスプロセスから開始され、社外の新規社員を対象に設計されています。3 つのパスのうち最も包括的なものとなります。

A: Initiation > B: Tasks by Employee as Self > C: Action by Employee As Self > D: Review Documents by Employee as Self > E: Action by Employee as Self  > F: To Do by Employee as Self

パス 2: 社内異動のオンボーディング (ライトバージョン)

このライトワークフローは、既存の社員に対する "職務の変更"
ビジネスプロセスから開始されます。通常、初回採用にのみ必要なステップは省略されます。

A: Initiation > B: Tasks by Employee as Self > C: Review Documents by Employee as Self > D: To Do by Employee as Self

パス 3: 臨時従業員 (契約社員) のオンボーディング

このワークフローでは、最初のデータ入力からドキュメントのレビューから、システムアクセスの付与や機器のプロビジョニングのための社内プロセスまで、新しい臨時従業員のオンボーディングを行うための主要なステップを示します。

A: Initiation > B: Tasks by Contingent Worker as Self > C: Review Documents by Contingent Worker as Self > D: To Do by Hiring Manager > E: To Do by IT Administrator

ワークフローステップ

"オンボーディング
" ビジネスプロセスワークフローの一般的なステップタイプは次のとおりです。

開始: ステップの順序
: これは常にビジネスプロセスの最初のステップであり、文字 A で指定されます。
グループ
: 親ビジネスプロセスのステップの完了によってトリガされたシステムアクションによって実行されます (例: " 採用
")。親プロセスを開始するユーザーのセキュリティによって、 オンボーディング ()
を開始できるユーザーが決まります。共通ロールには以下が含まれます。
HR Administrator
Manager
オンボーディングスペシャリスト
"
" を指定
: このフィールドは、"開始
" ステップタイプには適用されません。
ステップタイプのガイドライン
:
ベストプラクティス: シームレスな新規採用の経験を提供するために、"オンボーディング
" ビジネスプロセスを、"採用" ビジネスプロセス内のサブプロセスとして設定する必要があります。推奨されるプラクティスとして、" オンボーディング
" アクションステップを "採用"
プロセスの "Create Workday Account"
ステップ の後に
配置することです。これにより、新規採用者は、オンボーディングタスクを完了するためのシステムアクセス権を保持できます。
ユースケース: " 開始
" ステップの主なユースケースは、オンボーディングジャーニーを構成する一連のイベントをトリガすることです。これには、タスクの生成、通知の送信、新しい従業員およびその他の関連ロールへのドキュメントの転送が含まれます。このセクションは、"関連手続き"
、"ドキュメントのレビュー"
、その他のタスクなど、後続のすべてのステップのコンテナとして機能します。
例:HR 管理者が、
新規社員に対して "採用
" ビジネスプロセスの最終ステップを完了させるとします。プロセスが完了すると、"オンボーディング
" ビジネスプロセスが自動的に開始されます。その後、新規採用者は Workday にログインし、個人情報の更新や会社ポリシーのレビューなどのオンボーディングタスクを完了するための通知を受け取ります。
。
条件ルールのガイドライン
:
ベストプラクティス: 親ビジネスプロセスでルールを設定し、専用の オンボーディング
ワークフローをトリガします。たとえば、法人社員向けに 1 つの オンボーディング
プロセス、製造拠点の社員向けに別個の 1 つがあり、それぞれステップとドキュメントが異なるとします。
ユースケース: " 開始
" ステップ自体には条件ルールを設定しませんが (プロセスが開始されないようになるため)、親ビジネスプロセス (例: " 採用
") ではルールベースのルーティングを使用してかどうかを判断できます。開始する "オンボーディング
" ビジネスプロセス定義これにより、職務プロファイル、勤務地、従業員タイプなどの条件に基づいて異なるオンボーディングを経験できます。
例:"採用
" ビジネスプロセスの条件ルールでは、新規採用者の国をチェックできます。国が米国の場合、 フォーム I-9
ステップを含む 米国のオンボーディング
プロセスが開始されます。国がカナダの場合、国固有のドキュメントとタスクを使用して カナダのオンボーディング
プロセスが開始されます。

タスク: これは アクション
ステップです。特定のステップタイプは "タスク"
です。
ステップの順序
: 順序は "オンボーディング
" ビジネスプロセス定義内で定義されます。ステップの順序は、文字または数字で割り当てることができます。
ベストプラクティス: 複数のタスクを従業員の "インボックス" に同時に表示させるには、タスクに同じ順序 ID を割り当てて、それらのタスクを並行ステップとして設定できます (たとえば、すべてのステップを b に設定)。ただし、タスクが未割当になることを防ぐため、これらのタスクを含むステップは、親ビジネスプロセス (例: 採用
) の "Workday アカウントの作成"
ステップより後に発生するようにしてください。
グループ
:
"Tasks by Employee as Self" は、
"Employee as Self"
セキュリティグループによって実行されます。
"Tasks by Contingent Worker as Self" は、
"Contingent Worker as Self"
セキュリティグループによって実行されます。
ベストプラクティス: 従業員が正式な開始日よりも前にオンボーディングタスクを完了できるようにし、開始日が移動した場合にタスクが未割当になることを防ぐため、このステップを応募者とアクティブな従業員のセキュリティグループの両方に割り当てることをお勧めします。
社員の場合:Employee as Self
および Pre-Employee as Self
臨時従業員の場合:"Contingent Worker as Self"
および "Pre-Contingent Worker as Self"
セキュリティドメイン
: ロールベースのセキュリティグループにアクセス権を付与する必要があるセキュリティドメイン。
Self-Service: Personal Data
Self-Service: Person
Self-Service: Verify National ID
Self-Service: Home Contact Information
Self-Service: Work Contact Information
Self-Service: Emergency Contacts
Self-Service: Payment Election
Self-Service: Payroll - USA
Self-Service: Payroll (My Withholding Elections) - CAN
Self-Service: Benefits
Self-Service: Dependents
"
" を指定
:"タスク"
ステップの設定では、" 指定
" オプションフィールドが使用されていません。代わりに、使用可能なセルフサービスビジネスプロセスのリストから選択することにより、含まれるタスクを指定します。複数のアクションを 1 つの "タスク"
ステップにグループ化するか、個別にすることができます。
ステップタイプのガイドライン
:
ベストプラクティス
簡素化されたユーザーエクスペリエンスを実現するために、関連アイテムを 1 つの "タスク"
ステップにグループ化し、それらのラベルを明確に設定することができます ("新規採用の書類作成の完了"
など)。
特定のタスクが他のタスクより先に完了していることを確認する必要がある場合は、それらを別々のステップに配置できます。たとえば、"個人情報の確認"
(ステップ b) を、 支払オプションの管理
(ステップ c) の前提条件にすることができます。
従業員の採用日以降にのみ使用可能にするタスク (福利厚生オプションなど) については、ビジネスプロセス設定内の特定のステップで " ステップの延期"
を使用します。これにより、タスクが途中でインボックスに表示されるのを防ぎます。
ユースケース: このステップに含まれる一般的なタスクには以下が含まれます。
個人情報の入力
連絡先情報の入力
政府 ID の編集
支払オプションの管理 (口座振込)
(連邦および州の源泉徴収フォームの記入)
緊急連絡先の入力
福利厚生オプションの変更
例:"標準の社外新規採用のオンボーディング"
ワークフローで、"Pre-Employee as Self"
および "Employee as Self"
に割り当てる "初期のオンボーディングタスク"
というラベルの付いた タスク
ステップを設定できます。この 1 つのステップには、以下が含まれる可能性があります。
個人情報の入力
連絡先情報の入力
緊急連絡先の入力
条件ルールのガイドライン
: 条件ルールを適用して、ステップが開始またはスキップされるを制御できます。
ユースケース: 従業員がタスクにアクセスしたものの、送信前に変更を行っていない場合に、個人情報および連絡先情報の更新の承認ステップを自動的にスキップするように条件ルールを設定できます。これにより、承認者への不要なルーティングを防止できます。

アクション: ステップの順序
: 開始
ステップ (ステップ a) の後の任意の場所に配置できます。文字 (b、c、d) を使用して連番を定義できます。同じ文字のステップが並行して実行されます。
グループ
: このタスクの実行者は非常に柔軟です。これを オンボーディング管理者 (
)、 社員 (セルフ)
、 臨時従業員 (セルフ
)、 マネージャ ()
、HR パートナー ()
、 福利厚生パートナー (
またはサブプロセスを開始するのに必要な権限を持つその他セキュリティグループに割り当てることができます。
セキュリティドメイン
: ロールベースのセキュリティグループにアクセス権を付与する必要があるセキュリティドメイン。
Onboarding Administrator
: オンボーディングのルールとテンプレートを設定するためのタスクにアクセスします。次のドメインへのアクセスを制限する必要があります:Set Up: Onboarding
-
Employee As Self
: ダッシュボードのワークレットを含む、オンボーディングプロセスのセルフサービスへのアクセス:Self-Service: Onboarding
、Self-Service: Home Contact Information (およびサブドメイン)
、Self-Service: Work Contact Information (およびサブドメイン) )
、Self-Service: 緊急連絡先
、Self-Service: Benefits
、Self-Service: Payroll (My 源泉徴収オプション)
マネージャ
:"Worker Data: Work Contact Information" (およびサブドメイン)
へのアクセス権を表示または変更します。
HR 管理者: Set Up: Onboarding
(オンボーディングのルールとテンプレートを設定するためのタスクへのアクセスこのドメインへのアクセスを制限する必要があります)、 Person Data: Home Contact Information (およびサブドメイン)、Worker Data: Work Contact Information (およびサブドメイン)、Person Data: 緊急連絡先 ()。
HR パートナー
:Person Data: Home Contact Information (およびサブドメイン)
、Worker Data: Benefits
、Worker Data: Work Contact Information (およびサブドメイン)
の表示または変更。
福利厚生管理者/パートナー
: 従業員データ: 福利厚生、個人データ: 緊急連絡先
を表示または変更します。
""
を指定
: サブプロセスとして開始する特定のビジネスプロセスを選択します。オンボーディングの例:
個人情報の変更
連絡先情報の変更
政府 ID の変更
緊急連絡先の変更
福利厚生オプションの変更
I-9 フォームの完了
ステップタイプのガイドライン
:
ベストプラクティス: 類似したデータ収集タスクをグループ化します。たとえば、"個人情報"、"連絡先情報"、"緊急連絡先情報" について、個別のステップではなく、統合された "タスク" ステップタイプを使用できます。ただし、それぞれに別個の承認またはルーティングが必要な場合は、別個のアクションステップとして保持しておくことをお勧めします。
例:"プロファイルを完成させてください"
というアクションステップから、"Employee As Self"
に割り当てられた "個人情報の変更
" サブプロセスを開始できます。
条件ルールのガイドライン
:
ベストプラクティス
ルールを一度に 1 つずつ構築およびテストします。
特定のフィールドを使用して、ルールを正確に作成してください。
"ビジネスプロセス設定オプション"
レポートを活用して、ルールに使用可能なフィールドを確認します。
ユースケース:
動的で関連性の高いオンボーディングエクスペリエンスを作成するためには、条件ルールが必要です。これらを使用して、従業員データに基づいてステップを含めたりスキップしたりできます。
福利厚生対象外のパートタイム従業員に対する福利厚生登録をスキップする。
特定の州の従業員に関してのみ、州固有のポリシーレビュードキュメントを含める。
社内異動 vs 新規採用に対して、異なる一連のタスクをトリガする。
例: 米国ベースの採用についてのみ "Complete Form I-9
" ステップを実行する場合は、次のようなルールを作成できます。
ルールタイプ:
入力条件
条件:
従業員の主ポジションの国
が アメリカ合衆国
です。

関連手続き: ステップの順序
: フロー内の任意の場所に配置できます。専用のビジネスプロセスを持たないリマインダーやタスクによく使用されます。
グループ
: 任意のセキュリティグループで実行されます。共通割当先は以下のとおりです。
社員 (セルフ)
。
マネージャ
部門のコーディネーター (例:IT サポート
)。
""
を指定
:
"TO DO の管理
" タスクで管理するリストから、事前設定済みの TO DO を
選択します。
ステップタイプのガイドライン
:
ベストプラクティス: システム以外のタスクまたは単純なリマインダーに "関連手続き
" ステップを使用します。これにより、ビジネスプロセスがクリーンになり、単純なアクションのために複雑なサブプロセスが作成されるのを回避できます。
例: 新規採用者に割り当てられる TO DO を
、"CEO のウェルカムビデオの視聴"
などが考えられます。手順にはビデオへのリンクが含まれます。
条件ルールのガイドライン
:
ベストプラクティス
関連 手続き
のテキストは明確でアクション可能な状態にしてください。
通知を使用して、期日が近づいていることを割当先に通知します。
ユースケース:
" ノートパソコンの TO DO の
リクエスト" をマネージャに割り当てる (給与制社員の場合のみ)。
新規採用者が国民の祝日に近い場合、「会社の休日カレンダーをレビューする」
よう促す。
例:
"マネージャ: ウェルカムパッケージの準備"
というラベルの付いた "関連 手続き"
ステップをマネージャロールに割り当てることができます。

ドキュメントのレビュー: これは
アクション
ステップです。
順序
: 通常、最初のデータ収集の後で、完了ステップの前に配置します。
グループ
: ほぼ常に "Employee As Self"
によって実行されます。
""
を指定
: 含めるドキュメントと、電子署名が必要かどうかを設定できます。例: 社員ハンドブック、秘密保持契約書。
ステップタイプのガイドライン
:
ベストプラクティス: 重大なコンプライアンスドキュメントの場合、これを必須ステップとして設定し、追跡と監査の目的で電子署名機能を使用します。
例:"会社の方針を確認"
というラベルの付いたステップに、行動規範、IT 利用規約、および社員ハンドブックを含めることができます。
条件ルールのガイドライン
:
ベストプラクティス: 対象者と署名の要件が同じドキュメントを 1 つのステップにグループ化して、ユーザーエクスペリエンスを合理化します。
ユースケース:
従業員の国または会社に基づいて異なる社員ハンドブックを提示します。
営業組織の社員についてのみ、販売コミッションプランドキュメントを含める。
例: ルールで従業員の 職務系列
をチェックできます。"職務系列"
が "販売" の場合、このステップには署名用に 販売奨励金プランの
ドキュメントが含まれます。

サービス: ステップの順序
: これらのステップの順序が重要です。たとえば、"Workday アカウントの作成" は
、新しい社員にタスクが転送される前に発生する必要があります。
グループ
: システムによって実行され、従来の意味で人が割り当てられていません。
"
" を指定
: 実行する特定のシステムサービスを選択します。オンボーディング
の共通サービス:
Workday アカウントの作成
オンボーディングプランの割当
ステップタイプのガイドライン
:
ベストプラクティス: これらはバックグラウンドのシステムプロセスです。これらはユーザーが完了するタスクではありませんが、ワークフローの自動化にとって重要です。
例: "採用" プロセスの早い段階で "Workday アカウントの作成
" サービスを配置すると、応募者は入社前にログイン認証情報を取得して Workday でオンボーディングタスクを開始できます。
条件ルールのガイドライン
:
ベストプラクティス: これらのステップは基本的なものです。" オンボーディング
" プロセスを有効にするために、これらのイベントが親ビジネスプロセス (例:"採用
") の順序に正しく配置されていることを確認します。"Workday アカウントの作成
" ステップは、" オンボーディング
" ステップ自体より前に配置する必要があります。
ユースケース: 条件ルールを使用して、採用日のかなり時期を過ぎて Workday アカウントが作成されないようにすることができます。
例: " 採用
" ビジネスプロセスに "Onboarding Plan Assignment"
サービスステップを追加して、正しいオンボーディングプランを新規採用者に自動的に割り当てます。

インテグレーション

Workday では、"インテグレーション"
ステップタイプをサポートしているすべてのビジネスプロセスからインテグレーションを開始できます。これは通常、オンボーディング時に、サードパーティシステム ( 福利厚生
、 給与計算
、または IT プロビジョニングなど) にデータを送信したり、 フォーム I-9 の E-Verify
などの社内プロセスを開始したりするために使用されます。

ステップの順序

: インテグレーションはワークフロー内の複数のステップで行うことができます。このステップは通常、すべての承認が完了した後、プロセスが完了する前に発生します。

グループ

: システムによって実行されます。インテグレーションを実行するために必要なセキュリティ権限を持つ、事前設定されたインテグレーションシステムユーザー (ISU) を割り当てる必要があります。

" を指定

: 実行する特定のインテグレーションシステムを選択します。これは、法人カードプロバイダ用の 1 つなどの事前構築済みの Workday コネクタ、または、Workday Studio、エンタープライズインターフェイスビルダー (EIB)、またはコアコネクタを使用してカスタム構築したインテグレーションである場合があります。

ステップタイプのガイドライン

ベストプラクティス

最初に作成: ビジネスプロセスに "インテグレーション" ステップを追加して設定する前に、常にインテグレーションシステムを作成して設定します。

ISU を使用: インテグレーションを実行する場合は、 インテグレーションシステムユーザー
を使用しないでください。これにより、セキュリティが向上し、検証が容易になります。

分割して送信: インテグレーションプロセスは通常、ファイルの生成と送信に分割されます。外部システムでファイルを受信できない場合は、"プロセスモニタ" レポート
と "インテグレーションイベント"
レポートを使用して、ファイルの生成ステップまたは送信ステップが失敗したかどうかをトラブルシューティングします。

ユースケース:

アウトバウンドインテグレーション: オンボーディング
で最も一般的なユースケースは、新規採用データを外部システムに送信するアウトバウンドインテグレーションをトリガすることです。例としては、IT アカウントプロビジョニングのための Okta または Active Directory への従業員データの送信、サードパーティの給与計算プロバイダまたは福利厚生プロバイダへの新規採用の情報の送信、"Complete Form I-9"
ビジネスプロセスによる社員データの E-Verify
への送信などが含まれます。

インバウンドインテグレーション:"オンボーディング
" ビジネスプロセスの直接的な一部として一般的ではありませんが、インテグレーションは、最終的に Workday にデータを再ロードするプロセスをトリガする可能性があります (たとえば、グローバル HR システムから新規採用者の恒久 ID を取得する場合など)。

条件ルールのガイドライン

ベストプラクティス: ビジネスプロセス定義を変更した後は特に、ルールを定期的にテストして、期待どおりにルーティングされていることを確認します。

管理が困難になる複雑なルールを避ける。場合によっては、ビジネスプロセスを個別のルールベースの定義として作成する方が、1 つの定義内で多くの複雑なルールを作成するよりも明確になります。

条件付きでもある同時実行ステップでは、時にプロセスが停止する可能性があるため、注意してください。通常、重要なインテグレーションは独自の連続したステップに配置する方が有効です。

ユースケース:

不要なステップをスキップ

: 従業員が実際の変更を行わずに個人情報または連絡先情報を再送信した場合に、承認ステップをスキップするルールを作成します。

ルールベースのルーティング: 会社 ()
、 監督組織 ()
、 事業地 ()
などの条件に基づいて異なるバージョンの " オンボーディング
" ビジネスプロセスを定義します。たとえば、カナダ vs 米国の従業員に対して、独自のオンボーディングプロセスを設定して、国固有のベンダーに対して異なるインテグレーションステップを含めることができます。

個別のコンテンツ: 条件ルールを使用して オンボーディングプランの対象者
を定義し、対象となるコンテンツ、タスク、ドキュメントをさまざまな新規採用グループに送信できます。

例: 会社のハンドブックをすでに確認している社内異動の場合は、"ドキュメントのレビュー"
ステップをスキップします。

ルールロジック

: 従業員の "

採用ソース"

が

"社内異動"

の場合に偽
と評価する条件ルールを "ドキュメントのレビュー"
ステップで作成します。このステップは、この社員に対してスキップされますが、すべての社外採用に対してはトリガされます。

通知

システム通知

システム通知は、ビジネスプロセスイベントに対して Workday によって生成されるデフォルトのアラートです。ビジネスプロセスの

"通知"

タブで、すべてのシステム通知を表示できます。Workday では特定の通知を無効にすることができますが、多くの場合、ユーザーレベルで通知プリファレンスを管理するか、対象者を絞ったアラートにカスタム通知を使用する方が有効です。ビジネスプロセスシステム通知の設定を参照してください。

グローバル通知設定は、

"テナント設定の編集 - 通知"

タスクで管理します。

カスタム通知

ビジネスプロセスの任意のステップで開始できるカスタム通知を作成して、イベント、必須のアクション、またはステータス変更についてユーザーにアラートを送信できます。通知を作成するには、ビジネスプロセス定義で該当するステップに移動し、そのステップの関連アクションメニューから

"ビジネスプロセス"

"通知の追加" を

選択します。カスタム通知の作成を参照してください。

ガイドラインとベストプラクティス

統合可能なタイミングで統合: 新規採用者が完了する必要がある単一のタスクごとに個別の通知を送信するのではなく、統合することを検討してください。たとえば、新規採用者の "Workday オンボーディング
" ダッシュボードまたは "My タスク"
ページへのリンクを記載した 1 つの "ようこそ
" E メールを送信し、そこで処理待ちのアイテムをすべて確認できます。これにより、E メールが多すぎて新規採用者が混乱するのを防ぐことができます。

明確でアクション向けの言語を使用する: 通知の件名と本文は、明確で簡潔であり、受信者に行う必要があることを正確に伝えてください。動的フィールドを使用して、新規採用者の名前、開始日、マネージャなどを設定してメッセージをパーソナライズします。

動的コンテンツを活用: クラスレポートフィールドを使用して、関連情報を通知に取り込みます。これには次のような詳細を含めることができます。

採用日

職務名

マネージャ

勤務地。

オンボーディングダッシュボードへのリンク

対象者を検討: 受信者に向けた通知の内容と形式を設定します。新規採用者への通知は、IT チームメンバーや採用マネージャへの通知とは異なる通知になります。

ブランディング:"E メールテンプレートの管理" タスク
と "Notification Designer"
タスクを使用して、会社の外観と使い心地に合わせたブランディングを適用した E メールテンプレートを作成します。カスタム通知のデフォルトの E メールテンプレートを上書きして、特定のブランドテンプレートを使用できます。

ようこそ E メールのトリガ:

新規採用者が Workday にアクセスできるようにするには、"採用
" ビジネスプロセスの "Workday アカウントの作成"
ステップの後にこの通知をトリガする必要があります。

ステップの延期を使用して、採用が完了してから一定日数の後にこの通知を送信することも、 オンボーディング
プロセスへの入力後、すぐに通知をトリガすることもできます。

社内チームへの通知:

IT
、施設
、 給与計算
などの社内チームに新規採用が処理されたことを警告するカスタム通知を作成します。

これらの通知は、プロセスの適切なタイミングでトリガされる必要があります。たとえば、"採用
" ビジネスプロセスの完了時に IT 通知をトリガできます。

関連する詳細を通知に含める (新規採用者の名前、開始日、勤務地、特定の機器やアクセス要件など)。

サブプロセス通知の管理:

多くの場合、 オンボーディング
プロセスにはサブプロセスが含まれます (たとえば、福利厚生の登録、I-9 の検証など)。これらのサブプロセスには、それぞれの通知設定があります。

多くの E メールが送信されないように、サブプロセスからの通知を表示しない場合は、そのサブプロセスの開始ステップでシステム通知を無効にできます。

サブプロセスは、他のビジネスプロセスで使用されている場合があることに注意してください。意図しない結果を避けるため、カスタム通知に条件ルールを追加して 、単独のビジネスプロセス () が発生している場合にのみ開始できる
ように設定できます。

条件ルールを使用して、以下を実行します。

条件ルールは、通知が送信されるタイミングを制御するための強力なツールです。属性を使用して次のことができます。

たとえば、新規採用が特定の勤務地または職務プロファイルにある場合など、特定の条件が満たされた場合にのみ通知を送信する。

ビジネスプロセスのデータに基づいて、さまざまな通知をさまざまなグループに送信します。

一連のステップがすべて完了した後にのみ通知が送信されるようにします。

任意ステップの処理: 任意のステップで通知を設定すると、そのステップがスキップされていても通知が送信されることに注意してください。それに応じて通知ストラテジーを計画します。

例:

目標:"オンボーディング
" ビジネスプロセスが開始したらすぐに、新しい採用者にエキサイティングな歓迎メッセージを送信する。

設定:"オンボーディング
" ビジネスプロセスの "開始" ステップでカスタム通知を作成します。受信者は Employee as Self で
、通知は社員の個人の E メールアドレスに送信されます。

目標: 新規採用者が初採用日に必要な主要な情報を送信する。

設定: 開始日の前日にスケジュールされている " 関連手続き
" ステップをトリガする通知を作成します。

問題と解決策

出庫	原因と解決策
"採用" の完了後に、新規採用に対して"オンボーディング" プロセスがトリガされない。	原因: これには複数の原因が考えられます。新規採用者に対して Workday アカウントがまだ作成されていない場合は、オンボーディングステップは未割当になります。 "オンボーディング" および "オンボーディングの設定 " ステップの順序が正しくないか、親の " 採用 " ビジネスプロセスに含まれていません。ソリューション: "ビジネスプロセス定義 (デフォルト定義) の作成 " タスクを使用して、"オンボーディングの設定 " ビジネスプロセスのデフォルト定義を作成します。 "採用 " ビジネスプロセス定義で、"オンボーディングの設定 " ステップが " オンボーディング " ステップの直前に配置されていることを確認します。どちらのステップも、"Workday アカウントの作成 " ステップの後に配置する必要があります。
新規採用者は、オンボーディング通知を受け取りません。	原因: 最も一般的な原因は、誤ったルーティングルールです。応募者の場合、通知は応募者の E メールアドレスに送信する必要があります。ソリューション: "テナント設定の編集 - 通知" に移動します。"HCM" セクションで、オンボーディングプラン通知または関連するカスタム通知が、対象者の外部 E メールに送信されるように設定されていることを確認します。また、応募者の個人の E メールアドレスが Workday で入力されていることも確認します。
新規採用者は、自分のインボックスにすべてのオンボーディングタスクを一度に受け取ることはできません。	原因: "オンボーディング" ビジネスプロセス定義の各ステップで異なる順序番号 (例: c、d、e) が設定されているため、先行する各ステップが完了するたびに、このステップが順番に送信されるように設定されています。ソリューション: "オンボーディング" ビジネスプロセス定義をレビューします。すべてのタスクを一度に表示することが目標の場合、関連するステップ (たとえば、関連手続き、ドキュメントのレビュー、個人情報の変更 ) が同じ順序文字 (例: c、c、c) を使用して設定されていることを確認してください。これにより、インボックスに同時に表示される並行ステップになります。
"Complete Form I-9 " ステップが停止状態になり、続行しません。	原因: "Complete Form I-9" ステップは、" オンボーディング " ビジネスプロセスの他のステップと同時に実行されるように設定されています (つまり、同じ順序番号を使用して)。このステップの一部である E-Verify インテグレーションは、多くの場合、他のすべての並行ステップが完了するまで実行されません。ソリューション: "オンボーディング" ビジネスプロセス定義を編集して、"Complete Form I-9 " ステップを (一意の順序で) 連続したステップに配置します。最良の結果を得るために、他のステップを並行して実行しないでください。
ビジネスプロセスステップの完了時に通知がトリガされない。	原因: 通知がビジネスプロセスステップに正しく関連付けられていないか、通知に満たされていない条件がある可能性があります。ソリューション: カスタム通知設定をレビューして、正しいビジネスプロセスおよびステップにリンクされていることを確認します。通知の "条件" タブをチェックして、トリガを妨げているルールがないか確認します。また、従業員の "プロセスモニタ" をオンにして、ビジネスプロセスが期待どおりに機能しているかを確認します。
通知内のリンク (例: オンボーディングプランへの) は、新規採用者に対して機能しません。	原因: 多くの場合、これはセキュリティの問題です。新規採用者に、まだ Workday アカウントへのアクセス権が付与されていないか、ターゲットページのセキュリティが不足している可能性があります。ソリューション: 内部リンクを含む通知が送信される前に、"採用" または "オンボーディング " ビジネスプロセスの "Workday アカウントの作成" ステップが実行されるようにします。応募者が入社前にコンテンツにアクセスできるようにしたい場合は、社外プリボーディングの設定が正しく設定されていることを確認してください。
マネージャまたは他の参加者がリマインダー通知を受け取っていません。	原因: 受信者が誤って定義されているか、Workday にユーザーの勤務先 E メールアドレスが設定されていない可能性があります。ソリューション: カスタム通知の "受信者 " フィールドをチェックして、正しいロール (例: マネージャ、HR パートナー ) が選択されていることを確認してください。対象の受信者に有効な勤務先 E メールアドレスが入力されていることを従業員プロファイルで確認します。
承認者または他の参加者 (例: マネージャ ) がオンボーディングステップを確認したりアクションを実行したりすることはできません。	原因: 通常、ユーザーのセキュリティロールに、ビジネスプロセスにおける特定のステップに対する権限がない場合に発生するセキュリティの問題です。ソリューション: " オンボーディング " ビジネスプロセスの "ビジネスプロセスセキュリティポリシー" にアクセスします。特定のステップ (例: ドキュメントのレビュー、関連手続き ) を検索し、そのステップに対してアクションを実行できる適切なセキュリティグループ (例: マネージャ、HR パートナー ) がリストされていることを確認します。