メールを送信する [2] 実行

最終更新日: 2021年1月29日
R8 | R9

順次・順次・順次フロー

「フロー参加者設定名01」は「順次・順次・順次フロー」を用います。この例では user01→user02→user03 を使って説明します。

申請

はじめに、user01 でログオンします。

図1 user01で年休申請の登録を行う(1)

データを登録しました。この時点ではまだワークフローは開始していません。次のメールアドレスは申請者となっています。

図2 user01で年休申請の登録を行う(2)

ワークフローを申請します。

図3 ワークフローを申請する(1)

申請すると、次のメールアドレスが user02 に変わります。

図4 ワークフローを申請する(2)

承認

user02 でログオンし、フローを承認します。

図5 user02で承認する(1)

承認すると、次のメールアドレスが user03 に変わります。

図6 user02で承認する(2)

決裁

user03 でログオンし、フローを承認します。

図7 user03で承認する(1)

フロー状態が "決裁" になりました。次のメールアドレスは空になります。

図8 user03で承認する(2)

順次・合議・順次フロー

「フロー参加者設定名02」は「順次・合議・順次フロー」を用います。この例では、user0A→(user0B,user01)→user0C を使って説明します。

申請

はじめに、group0A に所属している user0A でログオンします。(今回のフロー設定では申請者は group0A に所属していれば、誰でも可能です。)

図9 user0Aで年休申請の登録を行う(1)

データを登録しました。この時点ではまだワークフローは開始していません。次のメールアドレスは申請者となっています。

図10 user0Aで年休申請の登録を行う(2)

ワークフローを申請します。

図11 ワークフローを申請する(1)

申請すると、次のメールアドレスが user01,user02,user03,user0B に変わります。これは合議に含まれるすべての対象者のメールアドレスです。

図12 ワークフローを申請する(2)

承認 [1]

user0B でログオンし、フローを承認します。

図13 user0Bで承認する(1)

承認すると、次のメールアドレスが user01,user03,user03 に変わります。

図14 user0Bで承認する(2)

承認 [2]

user01 でログオンし、フローを承認します。ここで二回目の承認が行われたため、次のノード(決裁)へ進みます。次のメールアドレスは user0C に変わります。

図15 user01で承認する

決裁

user0C でログオンし、フローを承認します。

図16 user0Cで承認する(1)

フロー状態が "決裁" になりました。次のメールアドレスは空になります。

図17 user0Cで承認する(2)

仕様

合議ノードでのメール送信

フロー参加者で次の合議ノードを設定した場合を例に説明します。

  • 申請1 (staff01)
  • 申請2 (staff02)
  • 決裁1 (manager01)
  • 決裁2 (manager02)

決裁 以外のイベント

メール設定は staff01 の「申請」イベント、staff02 の「申請」イベント、manager01 の「差し戻し」イベント、manager02 の「差し戻し」イベントなど、各ノードとイベント(「新規登録」「申請」「承認」「却下」「保留」「差し戻し」「取り消し」)の組み合わせで設定を行ないます。

決裁イベント

決裁は、決裁ノードで承認を行なうとシステムで自動追加されるイベントです。このため、決裁のメールは一つだけ設定することで、どの合議ノードで承認しても決裁メールが送信されます。

決裁ノードでの承認イベントは、これが "決裁" となる場合には発生しません。

例えば決裁の合議ノードで必要承認数を2とした場合、最初の承認では決裁とならないため合議ノードの承認イベントが発生し、決裁ノードの承認イベントのメールが送信されます。
続けてもう一方の決裁者が承認を行なった場合、必要承認数2に達したため "決裁" と扱われます。このとき承認イベントのメールは送信されず、決裁イベントのメールのみ送信されます。

つまり、合議ノードの決裁イベントでは、メールを一つだけ設定するとよいです。どの合議ノードで承認しても決裁時にメールが1件、送信されます。