> ## Documentation Index
> Fetch the complete documentation index at: https://help.dingtalk.io/llms.txt
> Use this file to discover all available pages before exploring further.
# 承認者フローノード
> YiDAのワークフロー設計における承認者フローノードの役割と設定方法を解説します。承認・却下・転送・リクエスト署名・差し戻しなどの承認アクション、各エディションでの機能対応状況、承認者タイプの設定手順を紹介します。
承認者フローノードは、ワークフロー設計において最も重要なフローノードの1つです。承認、却下、転送、リクエスト署名、差し戻しなどの意思決定権限を担います。本記事では、承認者フローノードの概要と設定方法を紹介します。
| **エディション別機能対応** | **Freeプラン** | **ベーシック版** | **プロフェッショナル版** | **専用版** | **専用版 - OA拡張パック** |
| ------------------- | ----------- | ---------- | -------------- | ------- | ----------------- |
| **複数リクエスト署名の追加** | 非対応 | 非対応 | 非対応 | 対応 | 対応 |
| **サイレントな作業フロー送信取消** | 非対応 | 非対応 | 非対応 | 対応 | 対応 |
| **サードパーティ承認者** | 非対応 | 非対応 | 対応 | 対応 | 対応 |
| **作業フローのタイムアウト処理** | 非対応 | 非対応 | 対応 | 対応 | 対応 |
| **条件モード** | 非対応 | 非対応 | 非対応 | 非対応 | 対応 |
| **ジャンプ設定** | 非対応 | 非対応 | 非対応 | 非対応 | 対応 |
| **権限Matrix** | 非対応 | 非対応 | 非対応 | 非対応 | 対応 |
## 概要
承認者の役割は、該当フローノードでの承認タスクを処理し、**承認、却下**、**転送**、**リクエスト署名**、または**差し戻し**などの意思決定を行うことです。すべての作業フローには少なくとも1つの承認者フローノードが含まれている必要があり、必要に応じて承認者フローノードを追加または削除できます。
例えば、社員がオフィス用パソコンを購入する場合、精算のために会社の作業フローに従う必要があります。社員が精算申請を提出し、経理担当者が承認するかどうかを判断します（承認、却下、またはその他のアクション）。このシナリオでは、経理担当者が作業フローにおける**承認者**となります。
## 承認者フローノードの追加
以下の手順に沿って承認者フローノードを追加します。
[YiDAワークベンチ](https://www.yidaapps.com/workPlatform)にログインします。対象のアプリを選択し、**ページ管理**ページに移動します。
ワークフローフォームを選択し、フォーム名の横にある下向き矢印をクリックして**ワークフロー設計**を選択します。
3. 作業フローのフローノード間の接続線にカーソルを合わせると、\*\*+**ボタンが表示されます。**+\*\*をクリックし、承認者フローノードを選択します。
## 承認者の設定
承認者は業務シナリオに応じて異なる役割に対応します。YiDAの承認者フローノードでは、現在以下の承認者タイプに対応しています。
⚠️**注意：1つのフローノードで指定できるユーザー、ロール、上長、または連絡先は最大100件です。**
### 指定ユーザー
シンプルモードにおける指定ユーザーとは、フローノードの承認者を固定の承認者として指定することです。複数選択にも対応しています。
複数の承認者がいる場合、以下のマルチ承認者モードを利用できます。
* 並列（いずれか）：設定されたすべてのユーザーに通知が届きます。いずれかの承認者が承認した時点で、作業フローは次のフローノードに進みます。最終結果は、最初にアクションを起こした人によって決定されます。
* 並列（全員）：すべての承認者が承認した後にのみ、作業フローは次のフローノードに進みます。
* 順次：承認者が設定された順序に従って1人ずつアクションを行います。
### 指定ロール
指定ロールによる承認は、複数のメンバーを1つのグループとしてマークします。**DingTalkロール**または**YiDAロール**を利用できます。
* YiDAロールは、YiDAワークベンチ > プラットフォーム管理ページで管理します。
* DingTalkロールは、DingTalk管理コンソールで管理します。
ロールの設定方法については、[ロール管理](/ja/yida/platform-admin/fb7uip)を参照してください。
複数の承認者がいる場合、以下のマルチ承認者モードを利用できます。
* 並列（いずれか）：設定されたすべてのユーザーに通知が届きます。いずれかの承認者が承認した時点で、作業フローは次のフローノードに進みます。最終結果は、最初にアクションを起こした人によって決定されます。
* 並列（全員）：すべての承認者が承認した後にのみ、作業フローは次のフローノードに進みます。
* 順次：承認者が設定された順序に従って1人ずつアクションを行います。
### 部門長
申請者、またはページ上のメンバーコンポーネントの部門長を指定します。
1. 最大20階層までの上長に対応しています。
2. 上長の取得元がフォーム上のメンバーコンポーネントで、そのメンバーが複数の部門に所属している場合、システムはランダムに1つの部門を選択して「部門長」を取得します。
以下の設定項目に対応しています。
* 部門フィルター：
* マルチ承認者モード：
### 複数階層の上長
申請者が提出した後、申請者より上位の各階層の上長が、承認の終点に達するまで順次承認を行います。
承認の終点は、指定ロールまたは特定の上長階層に設定できます。
**承認の終点**：
* 指定ロール（上長チェーン上に存在する必要あり）：
どの上長階層が必要か分からないものの、上長のロールが分かっている場合にこのオプションを使用します。
例：上長のロールが経理であることは分かっているが、正確な階層は不明な場合。このオプションを選択し、ロールを経理に設定することで、上長チェーンに沿って経理ロールを持つ上長を承認者として見つけます。
* 連絡先からN階層目の上長：連絡先内のどの上長階層を承認者にするかを選択します。
例：承認者を3階層目の上長に設定した場合、作業フローがこのフローノードに到達すると、申請者（またはメンバーフィールド）の1階層目の上長から3階層目の上長まで順次承認が行われます。その後、作業フローは次の承認フローノードに進みます。
**上長の取得元**：作業フロー申請者、またはフォーム上のメンバーフィールドの連続する複数階層の上長。
1.「複数階層の上長」における「上長」は「部門長」（「直属の上長」ではない）を指します。
2\. 上長の取得元がフォーム上のメンバーフィールドで、そのフィールド内のメンバーが複数の部門に所属している場合、システムはランダムに1つの部門を選択して「部門長」を取得します。
**複数階層連続**：
* 複数階層連続がオフの場合、承認の終点の上長のみが承認します。
* 複数階層連続がオンの場合、1階層目から承認の終点までのすべての上長が順次承認します。
**承認の終点と複数階層連続の組み合わせ**
**複数階層連続オン**
1. 指定ロールを終点とする場合
* 複数階層連続の上長はA-B-C-Dです。
* 終点のロールにCが含まれます。
* 最終的な承認チェーンはA-B-Cです。
注意：最小範囲切り取りルールに従い、チェーンがA-B-C-DでロールにCとDの両方が含まれる場合、Cが承認の終点として扱われ、結果はA-B-Cのままとなります。
2. 指定N階層目の上長を終点とする場合：1階層目からN階層目までのすべての上長を取得します。
* 複数階層連続の上長はA-B-C-Dです。
* 終点が3階層目の上長（C）の場合、最終的な承認チェーンはA-B-Cです。
* 終点が最上位階層の上長の場合、最終的な承認チェーンはA-B-C-Dです。
**複数階層連続オフ**
1. 指定ロールを終点とする場合：ロールと1階層目からN階層目までの上長の積集合を取得します。
* 連続する上長はA-B-C-Dです。
* ロール内のメンバーは（A、D、E）です。
* 最終的な承認者はAとDです。
2. 指定N階層目の上長を終点とする場合：N階層目の上長のみを取得します。
* 連続する上長はA-B-C-Dです。
* 終点が3階層目の上長の場合、最終的な承認者はCです。
* 終点が最上位階層の上長の場合、最終的な承認者はDです。
### 直属の上長
申請者、またはページ上のメンバーコンポーネント変数の直属の上長を指定します。N階層目の上長をカスタマイズできます。
**直属の上長が見つからない場合、部門長が代わりに承認する**という設定に対応しています。
1. 最大20階層までの上長に対応しています。
2. 上長の取得元がフォーム上のメンバーコンポーネントで、そのメンバーが複数の部門に所属している場合、システムはランダムに1つの部門を選択して「直属の上長」を取得します。
3. 申請者の直属の上長を承認者に選択し、申請者が退職した場合、上長情報を取得できないため承認者の取得に失敗します。
### 部門連絡先
部門連絡先は**プラットフォーム管理**ページで管理します。右側の連絡先管理ボタンをクリックしてプラットフォーム管理ページに入り、部門連絡先を設定します。詳細は[連絡先設定](/ja/yida/platform-admin/ka1xu9)を参照してください。
部門連絡先は、部門の連絡担当者と理解できます。部門に複数の階層があっても、通常は指定された連絡先が1つ存在します。
複数の承認者がいる場合、以下のマルチ承認者モードを利用できます。
* 並列（いずれか）：設定されたすべてのユーザーに通知が届きます。いずれかの承認者が承認した時点で、作業フローは次のフローノードに進みます。最終結果は、最初にアクションを起こした人によって決定されます。
* 並列（全員）：すべての承認者が承認した後にのみ、作業フローは次のフローノードに進みます。
* 順次：承認者が設定された順序に従って1人ずつアクションを行います。
### 申請者
現在のフローノードの承認者は、作業フローの申請者となります。申請者が情報を再度確認する必要がある場合に便利です。
承認者が申請者の場合、このフローノードは自動承認ルールの影響を受けません。
### 申請者が選択
申請者が作業フローを開始する際に承認者を選択します。
選択範囲は**全社**、**指定ユーザー**、**指定ロール**の3つの次元で設定できます。
* 全社：申請者は社内の誰でも承認者として選択できます。
* 指定ユーザー：申請者は、指定されたユーザーリストから承認者を選択します。
* 指定ロール：申請者は、指定されたロールリストから承認者を選択します。
複数の承認者を選択できる場合、マルチ承認者モードを設定できます。
* 並列（いずれか）：設定されたすべてのユーザーに通知が届きます。いずれかの承認者が承認した時点で、作業フローは次のフローノードに進みます。最終結果は、最初にアクションを起こした人によって決定されます。
* 並列（全員）：すべての承認者が承認した後にのみ、作業フローは次のフローノードに進みます。
* 順次：承認者が設定された順序に従って1人ずつアクションを行います。
### フォーム上のメンバーフィールド
フォーム上のメンバー変数または申請者変数を承認者として使用します。
複数の承認者に対応しています。マルチ承認者モードは以下のとおりです。
* 並列（いずれか）：設定されたすべてのユーザーに通知が届きます。いずれかの承認者が承認した時点で、作業フローは次のフローノードに進みます。最終結果は、最初にアクションを起こした人によって決定されます。
* 並列（全員）：すべての承認者が承認した後にのみ、作業フローは次のフローノードに進みます。
* 順次：承認者が設定された順序に従って1人ずつアクションを行います。
### サードパーティサービス
サードパーティサービスを介して承認者を設定します。**プラットフォーム管理** > **サービス登録**でサードパーティサービスを登録し、作業フローで直接選択します。
#### レスポンス形式の要件
```java theme={"theme":{"light":"github-light","dark":"github-dark"}}
[
"社員番号 1",
"社員番号 2"
]
```
サービスの登録方法などの詳細については、サービス登録を参照してください。
### コネクタから取得
カスタムデータコネクタ（YiDAコネクタファクトリーまたは DingTalk連携プラットフォーム）から承認者を取得できます。設定フローはコネクタフローノードと同じです。
コネクタの設定については以下を参照してください。
* YiDAコネクタファクトリー
* DingTalk連携プラットフォーム
**コネクタ** > **アクションの実行** > **アクションの設定**を選択します。
作業フローは、コネクタから返されたユーザー情報を自動的に承認者として使用します。
```javascript theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
"result": [
"5014533041684350",
"01432910392321237660"
],
"success": true,
"error": ""
}
```
### 権限Matrixから取得
権限Matrixから承認者を設定します。**プラットフォーム管理** > **権限Matrix**で設定し、作業フローで直接選択します。
権限Matrixの設定については、[権限Matrix](/ja/yida/platform-admin/bqc0fgwy5usglvrn)を参照してください。
### 条件モード
> ベータ版
条件を設定することで、システムはあらかじめ定義したルールに基づいて自動的に承認者を判別し、条件ごとに異なる承認者を選択できます。条件モードでは、柔軟なルール設定を通じて動的かつ正確なタスク割り当てを実現し、条件の組み合わせによって承認者、CC受信者、実行者を決定します。
この機能は**専用版 - OA拡張パックユーザー**専用です。
OA拡張パックにご興味のある方は、YiDAアカウント担当者にお問い合わせください。
1. 承認設定ページに移動します：YiDAプラットフォームで、承認ワークフローの設定ページを開きます。
2. 条件モードを選択します：承認者、CC受信者、または実行者のオペレーター設定で「条件モード」を選択します。条件モードは複数の承認者グループに対応しており、異なる条件を定義することで異なる承認者へのルーティングが可能です。
3. 条件ルールを設定します：\[項目を追加]をクリックして、下の承認有効条件に行を追加します。\[条件を設定]をクリックして条件設定ダイアログを開き、必要に応じてルールを設定します。
例：申請金額が1,000元未満の場合、経理マネージャーが承認します。
申請金額が1,000元以上の場合、経理ディレクターが承認します。以下の図を参照してください。
4. 複数のルールの有効化方法：
* 優先順位ベース：
* 並列：
5. マルチ承認者モード：
* 並列（全員）（すべての承認者の承認が必要）
* 並列（いずれか）（いずれか1人の承認者による承認で十分）
* 順次（順番に1人ずつ承認）
6. 保存して公開します：すべての条件を設定した後、設定を保存して公開します。
## 承認ボタン
承認ボタンは、作業フローが現在のフローノードに到達したときに、そのフローノードの承認者が実行できるアクションです。以下のアクションに対応しています：承認、却下、保存、転送、リクエスト署名、差し戻し、送信取消。各アクションの表示名、デフォルトコメント、有効/無効の状態を設定できます。承認と却下は一括承認にも対応しています。
* 少なくとも1つの承認ボタンを有効にする必要があります。
* 承認者フローノードを作成すると、承認と却下がデフォルトで有効になります。
承認ボタンの設定
承認者による承認アクションの実行
各承認アクションの説明と設定は以下のとおりです。
### 承認
現在の申請者の承認フォームを承認することを示します。有効にすると、承認者の承認フォーム上に承認ボタンが表示されます。
一括承認、コメントボックスの表示有無、コメントの必須有無、デフォルトコメントを設定できます。
### 却下
現在の申請者の承認フォームを却下することを示します。有効にすると、承認者の承認フォーム上に却下ボタンが表示されます。却下をクリックすると、承認フォームは即座に終了します。
一括承認、コメントボックスの表示有無、コメントの必須有無、デフォルトコメントを設定できます。
### 保存
保存アクションは、現在の承認者が承認フォームに情報を追加したり内容を修正したりする必要があるシナリオに適用されます。有効にすると、承認者の承認フォーム上に保存ボタンが表示されます。
### 転送
転送アクションは、現在の承認者が承認フォームについて判断できず、上位の管理者や別の承認者に対応してもらう必要がある場合に適用されます。有効にすると、承認者の承認フォーム上に転送ボタンが表示されます。
一括承認、コメントボックスの表示有無、コメントの必須有無、デフォルトコメントを設定できます。
### リクエスト署名
リクエスト署名は、承認フローに承認者を追加します。**リクエスト署名の位置**、**リクエスト署名の目的**、**リクエスト署名のアクションボタン**を設定できます。
リクエスト署名ボタンは以下の設定に対応しています。
**リクエスト署名の位置**：
* 前：現在の承認者の前に承認フローノードを追加します。現在の承認者が、追加されたフローノードの承認者を指定します。複数のリクエスト署名に対応しています。
* 後：現在のフローノードが終了した後に承認フローノードを追加します。現在の承認者が、追加されたフローノードの承認者を指定します。複数のリクエスト署名に対応しています。
**リクエスト署名の目的**：
* 承認に参加：目的が承認への参加である場合、リクエスト署名用の新しい承認フローノードが作成されます。
* 通知のみ、参加しない：通知のみに設定した場合、リクエスト署名ユーザーは通知を受け取るだけで、作業フローの処理には参加せず、ワークフローインスタンスビューにも表示されません。
**リクエスト署名のアクションボタン**：リクエスト署名ユーザーが利用できる承認アクション。承認、却下、転送、リクエスト署名、差し戻しに対応しています。
リクエスト署名を追加した後の作業フロー図は以下のとおりです。
* 現在の承認者はリクエスト署名ユーザーとして選択できません。特定のユーザーのみ選択可能で、ロールは選択できません。
* リクエスト署名ユーザーのマルチ承認者モードは、現在の承認者フローノードのモードに従います。
* 「前」のリクエスト署名フローノードが生成されると、元のフローノードのすべての保留中タスクはキャンセルされます。「前」のリクエスト署名フローノードが解決された後、元のフローノードへの影響に基づいて、元のフローノードの保留中タスクが再生成されます。
### 差し戻し
作業フローの差し戻しとは、承認フロー中に、現在のフローノードの承認者が提出された承認フォームに満足していないか、申請者の提出内容が不完全な場合に、承認者が承認フォームを申請者または作業フローの前のフローノードに差し戻すことを意味します。
* 承認ボタンに差し戻しとリクエスト署名の両方が含まれ、リクエスト署名の設定にも「差し戻し」ボタンが含まれている場合、差し戻し機能は承認者フローノードの差し戻しロジックに従います。
* リクエスト署名のみが設定されており、リクエスト署名オプション内で差し戻しが有効になっている場合、承認者は差し戻しアクションを実行できませんが、リクエスト署名ユーザーは選択された差し戻しロジックに従って差し戻しを実行できます。
* 作業フローで自動重複排除が有効になっており、作業フローが前の承認フローノードに差し戻されて再承認された場合、自動重複排除ロジックはダウングレードされ、途中の関連する承認者は再度承認する必要があります。つまり、差し戻しシナリオでは自動重複排除は適用されません。
* 作業フローが申請者に差し戻された後、申請者は承認を送信取消できます。
* \[申請者への差し戻し後、現在のフローノードから続く]：申請者への差し戻し後、元のフローノードは一時停止します。申請者は情報を修正できます。元のフローノードのタイムアウトタイマーは中断されず、データ管理ページに表示される現在のフローノードは元のフローノードのままです。
* \[申請者への差し戻し後、再承認]：申請者への差し戻し後、作業フローは実際には申請者フローノードに戻ります。データ管理ページには申請者フローノードが表示され、元のフローノードのタイムアウトタイマーはリセットされます。
作業フローの差し戻し後、以下の再承認モードに対応しています。
* 順番に再実行：申請者への差し戻し後、作業フローは実際には申請者フローノードに戻ります。データ管理ページには申請者フローノードが表示され、元のフローノードのタイムアウトタイマーはリセットされます。
作業フローのフローノードがA => B => Cで、CがAに差し戻す場合、作業フローはA => B => Cとして再実行されます。フローノードAとCのメッセージ通知およびビジネスルールは再度トリガーされ、現在のフローノードは**再提出**にリセットされます。
* \[順番に再実行]を選択すると、作業フローは直接申請者に差し戻され、作業フローの状態は申請者の下に表示されます。申請者が申請者フローノードで再提出する際に、すべてのフローノードの自動トリガーを無効にするかどうか、つまり\[数式、関連するビジネスルール、およびサードパーティサービスのコールバックもトリガーするかどうか]を設定できます。
* 元のフローノードのタイムアウトタイマーはリセットされます。
* 現在のフローノードから承認：申請者への差し戻し後、元のフローノードは一時停止します。申請者は情報を修正できます。元のフローノードのタイムアウトタイマーは中断されず、データ管理ページに表示される現在のフローノードは元のフローノードのままです。
作業フローのフローノードがA => B => Cで、CがAに差し戻す場合、作業フローはC => A => Cのパスに従います。メッセージ通知およびビジネスルールはトリガーされず、現在のフローノードは保持されるため、再提出後に現在のフローノードから承認を続けることができます。
* \[現在のフローノードから承認]を選択すると、作業フローは申請者に差し戻されますが、作業フローの状態は現在の承認者の下に留まります。
* 元のフローノードのタイムアウトタイマーは中断されません。つまり、フローノードにタイムアウト処理ルールが設定されている場合、そのルールは引き続き有効で、タイマーはカウントを続けます。
### 送信取消
作業フローの送信取消とは、作業フローが次の承認者または実行者フローノードに到達したときに、現在のフローノードのユーザーが送信取消を実行して再承認または再実行できることを意味します。
YiDA専用版はサイレント送信取消に対応しています。サイレント送信取消が有効な場合、送信取消の記録は承認履歴に表示されません。サイレント送信取消は、作業フローの**グローバル設定**で有効にできます。
送信取消のロジックは以下のとおりです。
* 作業フローの最初のフローノードは送信取消に対応しておらず、ボタンは非表示になります。代わりに取り消しを使用します。
* 送信取消は隣接するフローノード間でのみ対応しています。1回の送信取消が実行されると、連続した送信取消には対応しません。
* 作業フローのフローノードにフローノード提出ルール、統合と自動化のトリガー、または類似の機能が設定されている場合、送信取消は対応していません。
* 隣接する作業フローのフローノード間に自動化フローノードがある場合。
* フローノードが並列（全員）として設定されている場合。
* 複数の承認者がいる並列（いずれか）の場合、1人による送信取消でフローノードが再アクティブ化されます。
* 転送またはリクエスト署名によって生成されたタスクは、送信取消に対応しています。
## フィールド権限の設定
フローノードレベルのフィールド権限は、承認フローノードの承認者がどのフォームフィールドを表示できるかを制御します。コンポーネント名ごとに、編集可能、閲覧のみ、または非表示のステータスを設定できます。詳細については、[作業フロー権限制御](/ja/yida/process/lagbfd)を参照してください。
## ジャンプ設定
> ベータ版
この機能は**専用版 - OA拡張パック**専用です。
OA拡張パックにご興味のある方は、YiDAアカウント担当者にお問い合わせください。
業務作業フローにおいて、「承認者」フローノードは、業務ニーズに応じてジャンプルールをカスタマイズできるジャンプ設定モジュールに対応しました。
ジャンプルール設定ページのダイアログが開きます。条件と対象フローノードを設定します。
⚠️注意：ここでの対象フローノードは\[承認者]フローノードのみ選択できます。
以下のようにジャンプ条件を設定します。
3. その他の設定
* ジャンプ条件が満たされない場合、作業フローを終了するか、指定のフローノードにルーティングするかを選択します。
* 上流のフローノードにジャンプして作業フローを再実行する場合、数式、関連するビジネスルール、およびサードパーティサービスのコールバックを再度トリガーするかどうかを設定できます。
**特記事項**：フローノードのジャンプルールが有効になった後、現在のフローノードが100回通過されるかループが検出されると、業務上の問題を防ぐため作業フローは停止しエラーをスローします。
• 単一フローノードのコピーは「ジャンプ設定」のコピーに対応しています。フローノード設定の同期は、現在「ジャンプ設定」のコピーに対応していません。
4. 保存して公開：すべての条件を設定した後、設定を保存して新しい承認フローを公開します。
## 高度な設定
作業フローフローノードの高度な設定では、現在のフローノードの自動承認ルール、現在のフローノードに承認者がいない場合の処理ロジック、およびタイムアウト処理ルールを設定できます。
### 自動承認
自動承認ルールは、承認フローを簡素化し、重複承認による作業フローの非効率性を解消します。
詳細については、[自動承認ルール](/ja/yida/process/eeykw4)を参照してください。
### 承認者が見つからない場合
承認者が空の場合の処理オプション：
* フローノードを自動的にスキップ：
* アプリのスーパー管理者に転送：複数のアプリのスーパー管理者がいる場合、そのうちの1人にランダムに転送されます。
* 指定ユーザーに転送：1人以上のユーザーを追加します。複数のユーザーが指定されている場合、承認モードは現在のフローノードの「マルチ承認者モード」に従います。
* 作業フローを一時停止：空は許可されません。作業フローの状態は「作業フローエラー」として表示され、アプリの管理者またはプラットフォーム管理者による対応が必要です。
空とは、誰も見つからないことを意味します。例えば、ロールにメンバーがいない、またはユーザーの上長が設定されていないなどです。**退職したユーザーは空としてカウントされません。**
### タイムアウト処理
タイムアウト処理ルールは、ワークフロー設計における高度な設定の1つです。作業フローが**承認者**または**実行者**フローノードに到達した際、承認者または実行者が設定された時間内に対応しない場合、システムはルールで選択されたアクションを自動的に実行します。
詳細については、[タイムアウト処理ルール](/ja/yida/process/aglbg3)を参照してください。
## 注意事項
* 作業フローの申請者と申請部門は、作業フローが開始された時点でロックされます。作業フロー中に部門の変更や他者への委任による再提出があっても変更されません。
* 作業フロー中にユーザーが退職し、承認フローノードがそのユーザーの組織構成情報（例えば上長承認）に依存している場合、作業フローは承認者を見つけられず、エラーが発生したり承認が停止したりする可能性があります。この場合は、管理者に連絡し、フローノードのジャンプを使用して問題を解決してください。