> ## 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プレミアム作業フローの手動フローノードについて、基本設定と高度な使い方（フローノード情報、ルール設定、承認者ルール、完了ポリシー、操作ボタン、一括承認）を詳しく解説します。柔軟で効率的な承認フロー管理を実現する設定方法を紹介します。

プレミアム作業フローの手動フローノードは、標準作業フローにおける承認フローノードや実行者フローノードに相当します。手動フローノードは、フローノード進入ルール、フローノード送信ルール、前提条件など、より包括的な承認アクションに対応しています。

## 基本設定

基本設定には、フローノード情報、ルール設定、フローノード操作ボタン、一括承認設定が含まれます。

### フローノード情報

フローノード情報には、フローノード名、英語名、および説明が含まれます。

### ルール設定

#### 承認者ルール

承認者ルールでは、当該フローノードを処理する担当者を定義します。対応するオプションには、常用承認者、部門担当者、指定承認者、部門管理者、連続多層管理者、その他のルールがあります。

* 常用承認者：プレミアム作業フローにおける常用承認者は、標準作業フローにおける指定ロール承認と同様に動作します。複数のユーザーをグループとしてタグ付けし、DingTalkロールまたはYiDAロールを使用します。

<Note>
  ロールの設定方法の詳細については、[ロール管理](/ja/yida/platform-admin/fb7uip)をご参照ください。
</Note>

* 指定承認者：このフローノードの固定承認者を指定します。複数選択に対応しています。

* 部門担当者：部門担当者はプラットフォーム管理ページで管理します。YiDAプラットフォーム管理ページで部門担当者を設定します。詳細については、部門担当者設定をご参照ください。

<Note>
  **注意：**

  部門担当者は、部門の連絡先としてご理解ください。部門には複数の階層がある場合がありますが、通常は指定された部門連絡先が存在します。
</Note>

* 部門管理者：申請者の部門管理者を指定します。最大20階層までの管理者に対応しています。

3種類の部門フィルター設定に対応しています。

* 連続多層管理者：申請者が承認を送信した後、申請者の管理者が最下位から最上位まで順番に承認を行い、指定された終点まで到達します。終点は特定のロールまたは特定の管理者階層に設定できます。

例えば、承認者を第3階層管理者に設定した場合、作業フローがこのフローノードに到達すると、申請者（またはメンバーフィールド）の第1階層管理者から第3階層管理者まで順番に承認が進みます。第3階層管理者が承認して初めて、作業フローは次のフローノードへ進みます。

* その他のルール：上記のルールに加え、変数、サードパーティサービス、またはGroovyリクエストを使用して承認者を設定することもできます。サードパーティサービスは、YiDAのサービス登録ページで設定した後、作業フローで直接選択できます。

すべてのサービスは、使用前にYiDAのサービス登録に登録する必要があります（下図参照）。（詳細については、**サービス登録モジュール**をご参照ください。）

#### 完了ポリシー

完了ポリシーでは、フローノードの後続ラインの実行ルールを定義します。

ラインは、完了ポリシー内のルール名に基づいてマッチングされます。ルール条件のアクションは、フローノードの基本属性で定義されたフローノード操作ボタンから選択されます。

図中の赤枠は、リクエスト署名ルールを示しています。推奨されるベストプラクティスは以下のとおりです：承認は無効、拒否は有効。

完了ポリシー

### フローノード操作ボタン

フローノード操作ボタンの設定により、承認者がこのフローノードで表示するボタンを決定し、後続のライン実行ルールのアクションオプションも定義します。

<Note>
  承認と拒否は必須であり、削除できません。
</Note>

| **ボタン**     | **説明**                                                                                                                                                                                                                                                                                                                                                                                                         |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **承認**      | 現在の申請者の承認フォームを承認します。                                                                                                                                                                                                                                                                                                                                                                                           |
| **拒否**      | 現在の申請者の承認フォームを拒否します。承認者が拒否をクリックすると、承認フォームは直ちに終了します。                                                                                                                                                                                                                                                                                                                                                            |
| **保存**      | 保存アクションは、現在の承認者が追加情報の入力や承認フォームの承認者詳細の変更が必要な場合に適用されます。有効化すると、承認者は承認フォームに保存ボタンが表示されます。                                                                                                                                                                                                                                                                                                                           |
| **転送**      | 転送アクションは、現在のフローノードの承認者が承認フォームを判断できず、上位管理者または他の承認者に処理を依頼する必要がある場合に適用されます。有効化すると、承認者は承認フォームに転送ボタンが表示されます。                                                                                                                                                                                                                                                                                                        |
| **リクエスト署名** | 承認作業フローにおけるリクエスト署名ユーザーは、**事前署名**および**事後署名**の設定に対応しており、両方を組み合わせて設定することもできます。<br />• **事前署名**：現在の承認者の前に承認フローノードを追加します。追加されたフローノードの承認者は、現在の承認者が指定します。複数のユーザーを追加できます。<br />• **事後署名**：現在のフローノードの終了後に承認フローノードを追加します。追加されたフローノードの承認者は、現在の承認者が指定します。複数のユーザーを追加できます。                                                                                                                                                   |
| **差戻し**     | 現在のフローノードの承認者が提出された承認フォームに満足していない場合、または申請者の承認フォームが不完全な場合、作業フローの差戻しが発生します。承認者は承認フォームを申請者または前のフローノードに差戻します。<br />差戻し後の承認方式として、以下に対応しています。<br />• **順次再承認**：フローノードがA => B => Cで、CがAに作業フローを差戻した場合、作業フローはA => B => Cの順で再度進みます。各フローノードは対応するメッセージ通知および業務ルールをトリガーします。すべてのフローノードで自動トリガーを無効化することもできます。<br />• **現在のフローノードから承認**：フローノードがA => B => Cで、CがAに作業フローを差戻した場合、作業フローはC => A => Cの順で進み、対応するメッセージ通知や業務ルールはトリガーされません。 |

### 一括承認

1人が複数の承認フォームを承認する必要がある場合、一括承認により時間を節約し、業務効率を向上させることができます。

## 高度な使い方

### フローノードID

フローノードを一意に識別します。作業フローがエラーを返した場合、フローノードIDを使用して問題のあるフローノードを迅速に特定できます。

### 動的 vs 静的

静的フローノードは、作業フロー開始前に操作者が決定されます。動的フローノードは、作業フロー開始後に操作者が決定されます。

* 承認者ルールが常用承認者、部門担当者、指定承認者、部門管理者、連続多層管理者、または変数の場合、操作者は静的です。
* 承認者が外部サービス（サードパーティサービスまたはGroovyリクエスト）を通じて決定される場合、フローノードは動的です。

<Note>
  動的フローノードは予測情報には表示されません。
</Note>

### タスク割り当て方式

同時割り当ては、フローノードが複数の承認者を必要とする場合、すべての承認者にタスクが一度に割り当てられることを意味します。順次割り当ては、タスクが順番に割り当てられることを意味し、前の承認者が承認を完了して初めて次の承認者にタスクが割り当てられます。タスクセンターへのプッシュや承認コメントの必須化は、必要に応じて設定できます。

### 自動実行ルール

自動実行ルールにより、承認者が作業フローの申請者または前のタスクの承認者である場合に、現在のフローノードを自動的に実行できます。（作業フローフォームのみに適用されます。）

### 前提条件

デザイナーは前提条件の設定に対応しています。前提条件のルールが満たされない場合、フローノードはスキップされ、作業フローはデフォルトの発信ラインまたは条件を満たすラインを辿ります。

### 自動完了ルール

自動完了ルールでは、作業フロー開始時のフォームフィールドおよびシステムフィールドに基づく自動承認ルールを設定します。条件が満たされると、承認または拒否アクションが自動的に実行されます。

<Note>
  選択した条件が申請者の場合、対応するユーザーの`["userid"]/社員番号`を入力してください。ユーザー名を直接入力しても機能しません。
</Note>

### タイムアウトルール

承認者が承認フォームを長時間処理しない場合、フローノードが停滞して進まなくなります。効率への影響を回避するため、タイムアウトルールを設定して承認者に業務通知リマインダーを送信したり、別のフローノードにジャンプしたり、タスクを転送したりできます。通知テンプレートはテンプレート管理で設定できます。

* タイムアウト時のフローノードジャンプ

* タイムアウト時のタスク転送

### チャット設定

作業フローがこのフローノードに到達したときに承認者以外のユーザーに通知するには、メッセージ通知を追加します。通知に作業フローのリンクを含めることができます。ただし、作業フロー管理者ではないユーザーやインスタンスの閲覧権限を持たないユーザーは、作業フローを表示できません。メッセージテンプレートの選択方法の詳細については、**メッセージテンプレート**をご参照ください。

### フローノード進入ルール

フローノード進入ルールは、手動フローノードに進入したときにトリガーされます。対応するサービスを選択すると、作業フローがこのフローノードに到達したときに、関連するサービスが自動的に呼び出されます。

### フローノード送信ルール

フローノード送信ルールは、数式を使用して、ユーザーが作業フローを送信するとき、または承認者が作業フローを処理するときにアクションを実行できるかを検証します。

下図のとおりです。（具体的な数式については、[数式モジュール](/ja/yida/form/gvtpe4)をご参照ください。）

フローノード送信ルール

## ユースケース

**例**：あるチームの少額経費精算システムでは、精算金額について管理者の承認と経理の承認（経理ロールは、経理メンバーのいずれか1人による承認で十分と設定）が必要です。

以下は、作業フローの設計から承認の実行までの全プロセスを示しています。

## FAQ

* Q：なぜ承認と拒否ボタンを無効化できないのですか？

これら2つのボタンの無効化には現在対応していません。右側の目のアイコンをクリックして非表示にすると、キャンセルと同じ効果が得られます。

* Q：承認者が承認フォームを申請者に差戻して再提出させた場合、以前に承認された中間フローノードは再承認が必要ですか？

はい。現在、プレミアム作業フローの差戻しロジックでは、差戻し後にすべての中間フローノードを再実行します。

* Q：一括承認では一度に何件まで承認できますか？

一括承認ではデフォルトで1ページあたり10件の承認項目が表示されるため、一度に最大10件まで承認できます。