Skip to main content
実行者は意思決定を行いません。担当タスクを完了させた後、作業フローを承認者に戻し、以降の処理を委ねます。実行者の作業内容は承認結果とは無関係です。 例えば、経理承認のシナリオでは、経理マネージャーが承認を処理し、出納担当者が支払いを行います。経理マネージャーは承認者として作業フローの方向(承認、却下、転送など)を制御し、出納担当者は実行者として特定のアクションのみを実行します。

実行者ノードの追加

以下の手順で実行者ノードを追加します。
1

ステップ 1

YiDAワークベンチにログインします。対象のアプリを選択し、ページ管理ページを開きます。
2

ステップ 2

ワークフローフォームを選択し、ワークフローフォーム編集の隣にある下向き矢印をクリックしてから、ワークフロー設計をクリックします。
  1. カーソルを2つのフローノード間のコネクタ線上に移動すると、**+ボタンが表示されます。+**をクリックし、実行者ノードを選択します。

実行者の設定

実行者の役割はビジネスシナリオによって異なります。YiDAの実行者ノードは、現在、以下の実行者タイプに対応しています。
⚠️注意:1つのフローノードには、最大100名のメンバー、ロール、管理者、または連絡先まで設定できます。

指定メンバー

指定メンバーとは、当該フローノードの実行者を固定で指定することを意味します。複数選択に対応しています。 複数の実行者がいる場合、以下の動作方式を設定できます。
  • いずれか(OR):当該フローノードに設定されたすべてのメンバーに通知が届きます。いずれかの実行者がアクションを完了すると、作業フローは次のフローノードに進みます。最終結果は、最初に操作した人によって決まります。
  • すべて(AND):当該フローノードのすべての実行者がアクションを完了して初めて、作業フローは次のフローノードに進みます。
  • 順次:実行者は設定された順序で1人ずつ操作します。

指定ロール

ロールにアクションを割り当てると、複数のメンバーを一度にタグ付けできます。DingTalkロールまたはYiDAロールを利用できます。
  • YiDAロールは、YiDAワークベンチ > プラットフォーム管理ページで管理します。
  • DingTalkロールは、DingTalk管理コンソールで管理します。
ロール設定の手順については、ロール管理を参照してください。
複数の実行者がいる場合、以下の動作方式を設定できます。
  • いずれか(OR):当該フローノードに設定されたすべてのメンバーに通知が届きます。いずれかの実行者がアクションを完了すると、作業フローは次のフローノードに進みます。最終結果は、最初に操作した人によって決まります。
  • すべて(AND):当該フローノードのすべての実行者がアクションを完了して初めて、作業フローは次のフローノードに進みます。
  • 順次:実行者は設定された順序で1人ずつ操作します。

部門管理者

申請者、またはページ上のメンバーコンポーネント変数の部門管理者を指定します。
最大20階層までの管理者に対応しています。
以下のオプションを設定できます。
  • 部門フィルター:
  • 複数の実行者がいる場合、以下の動作方式を設定できます。

多階層管理者

申請者がリクエストを送信した後、承認終点に達するまで、レポートライン上の各管理者が順番に承認します。 承認終点は、特定のロールまたは特定の管理者階層に設定できます。
管理者のロールは分かっているが階層が不明な場合は、ロールを承認終点として使用します。例えば、管理者のロールがFinanceであると分かっているものの、その管理者がどの階層に位置するかが不明な場合は、このオプションを選択し、ロールをFinanceに設定します。作業フローは、レポートライン上でFinanceロールを持つ管理者を検索し、その人物を実行者として割り当てます。
承認終点
  • 指定ロール(レポートライン上の管理者である必要があります):
  • 連絡先内の第n階層の管理者:連絡先内のどの管理者階層を実行者にするかを選択します。
例えば、実行者を第3階層の管理者に設定した場合、作業フローが当該フローノードに到達すると、申請者(またはメンバーフィールド)の第1階層から第3階層までの管理者が順次承認します。すべての承認が完了して初めて、作業フローは次の承認フローノードに進みます。 管理者ソース:申請者の直上から連続する管理者階層、またはフォーム内のメンバーフィールドの直上から連続する管理者階層を選択します。 連続階層
  • 連続階層がオフの場合、承認終点の管理者のみが承認します。
  • 連続階層がオンの場合、第1階層から承認終点までのすべての管理者が順番に承認します。

直属管理者

申請者、またはページ上のメンバーコンポーネント変数の直属管理者を指定します。第N階層の管理者を指定することも可能です。 直属管理者が見つからない場合、部門管理者が代わりに承認するを有効化できます。
  • 最大20階層までの管理者に対応しています。
  • 承認者として申請者の直属管理者を選択した場合、申請者が退職していると、管理者情報を取得できないため、実行者の検索は失敗します。

部門連絡先

部門連絡先は、プラットフォーム管理ページで管理します。右側の連絡先管理ボタンをクリックしてプラットフォーム管理ページを開き、部門連絡先を設定します。詳細については、連絡先設定を参照してください。
部門連絡先は、部門の窓口担当者と考えてください。部門には複数のレポート階層が存在する場合がありますが、通常、指定された連絡先は1名です。
複数の実行者がいる場合、以下の動作方式を設定できます。
  • いずれか(OR):当該フローノードに設定されたすべてのメンバーに通知が届きます。いずれかの実行者がアクションを完了すると、作業フローは次のフローノードに進みます。最終結果は、最初に操作した人によって決まります。
  • すべて(AND):当該フローノードのすべての実行者がアクションを完了して初めて、作業フローは次のフローノードに進みます。
  • 順次:実行者は設定された順序で1人ずつ操作します。

申請者

現在のフローノードの実行者を、作業フローを開始した人物に設定します。申請者が情報を再確認する必要がある場合に、このオプションを使用します。
実行者が申請者の場合、当該フローノードは自動承認ルールの影響を受けません。

申請者が選択

申請者が作業フローを開始する際に実行者を選択します。 企業全体指定メンバー指定ロールの3つの観点から、選択スコープを設定できます。
  • 企業全体:申請者は、企業内の誰からでも現在のフローノードの実行者を選択できます。
  • 指定メンバー:申請者は、指定されたメンバーの中から現在のフローノードの実行者を選択できます。
  • 指定ロール:申請者は、指定されたロールの中から現在のフローノードの実行者を選択できます。
申請者が複数の承認者から選択できる場合、複数の承認者の動作方式を設定できます。
  • いずれか(OR):当該フローノードに設定されたすべてのメンバーに通知が届きます。いずれかの承認者が承認すると、作業フローは次のフローノードに進みます。最終結果は、最初に操作した人によって決まります。
  • すべて(AND):当該フローノードのすべての承認者が承認して初めて、作業フローは次のフローノードに進みます。
  • 順次:承認者は設定された順序で1人ずつ操作します。

フォーム内のメンバーフィールド

フォーム内のメンバー変数または申請者変数を実行者として使用します。 複数の実行者がいる場合、以下の動作方式を設定できます。
  • いずれか(OR):当該フローノードに設定されたすべてのメンバーに通知が届きます。いずれかの実行者がアクションを完了すると、作業フローは次のフローノードに進みます。最終結果は、最初に操作した人によって決まります。
  • すべて(AND):当該フローノードのすべての実行者がアクションを完了して初めて、作業フローは次のフローノードに進みます。
  • 順次:実行者は設定された順序で1人ずつ操作します。

コネクタから取得

カスタムデータコネクタ(YiDAコネクタファクトリー、またはDingTalkコネクタプラットフォーム)から実行者を取得できます。設定手順はコネクタノードと同様です。
コネクタの設定については、以下を参照してください。
  • YiDAコネクタファクトリー
  • DingTalkコネクタプラットフォーム
コネクタ > アクションを実行 > アクションを設定を選択します。 作業フローは、コネクタが返すユーザー情報を実行者として自動的に使用します。

権限マトリックスから取得

プラットフォーム管理 > 権限マトリックスで承認者を設定し、作業フロー内で直接選択します。 権限マトリックスの設定については、権限マトリックスを参照してください。

条件モード

段階的リリース中
実行者ノードは条件モードに対応しています。手順は承認者ノードと同じです。設定の詳細については、承認者ノード - 条件モードを参照してください。
本機能は専用版 - OA拡張パッケージ専用です。OA拡張パッケージにご興味がある場合は、YiDAの担当者までお問い合わせください。