逆引きレシピ集

NuAppのプラットフォーム上でアプリを作成する「アプリ管理」では一見シンプルな設定画面から実に様々なアプリの機能を作り出すことができます。

アプリ管理のドキュメントを全て見れば、大体の使い方は分かるかもしれませんが、多くの開発者の方は、実現したい機能の作り方を今すぐ知りたいと思うのではないでしょうか。

このチャプターでは、「やりたい事」に対する「作り方=レシピ」が紹介されています。作り方を見ながら要件に合わせてアレンジして、要望に即した機能を実現していって下さい。

目次

データをインポートする

実現できること(ゴールイメージ)

作成したアプリ内に、CSVファイルからデータを一括登録できる「インポート機能」を設置します。 NuAppのインポート機能は、実行前にプレビューでデータの整合性を確認できるなど非常にユーザーフレンドリーです。固定の管理者画面ではなく「アプリの一機能」としてメニューに配置するため、「マスタ担当者だけにインポートを許可する」といった柔軟な運用が可能です。

前提条件

インポートする対象のモデルが既に作成されている

手順

  1. インポート機能を設置したいアプリの設定画面を開く
    ※ 例えば、ある程度の権限を持つユーザーだけにアクセスさせる「マスタメンテ」アプリを作って、そこに配置する、といったことが考えられます。
  2. 対象のモデルが利用するモデルになければ追加
  3. Web向けメニューの任意の位置にコンポーネントを追加し、「インポート」を選択
  4. 対象のモデルを選択

以上で、機能の設定自体は完了です。

実際のアプリから当機能にアクセスすると、CSVファイルの作り方やサンプルのダウンロード、インポート方法について細かく記載されていますので、そちらを御覧ください。

データをエクスポート(CSV出力)する

実現できること(ゴールイメージ)

アプリ内のデータをCSV形式で一括出力します。 NuAppのエクスポートは固定の管理者機能ではなく、インポートと同様に「作成するアプリの一機能」として提供されます。業務要件やユーザーの権限に応じて、以下の2つの実装アプローチを使い分けることが可能です。

  • アプローチA(簡易): 「検索機能」に標準で備わっているエクスポートを利用する(全項目を手軽に出力したい場合)。
  • アプローチB(高度): 「エクスポート専用コンポーネント」を配置する(出力項目の絞り込み、ヘッダー名の変更、項目の結合など、加工して出力したい場合。主にシステム連携用途を想定)。

前提条件(必要なモデル)

  • データをエクスポートする対象のモデルが既に作成されていること。

手順

パターンA:検索機能の標準オプションを利用する場合

アプリに設置した検索コンポーネント、リストコンポーネントからは、設定不要でエクスポートが行えます。

  1. 利用ユーザーとして対象のアプリを開く
  2. リストコンポーネントでエクスポート実施
    • リストの上部にあるエクスポートボタンをクリック→エクスポートオプションを選択
  3. 検索コンポーネントでエクスポート実施
    • 検索条件の上部にある「その他オプション」>「CSVエクスポート方法を選択」をクリック→エクスポートオプションを選択
パターンB:エクスポート専用コンポーネントを配置する場合

出力する項目を厳密にコントロールしたり、データを加工して出力させたい場合の設定です。

  1. コンポーネントの追加
    • [Web向けメニュー] の編集画面を開き、機能を設置したい任意の場所で [コンポーネントを追加] をクリックします。
  2. 「エクスポート」の選択とモデル指定
    • 種類から 「エクスポート」 を選択し、対象の モデル を指定します。
  3. 出力項目のカスタマイズ(加工・結合)
    • 設定パネル内で、出力したい項目だけに絞り込み、並び順やヘッダー名(CSVの1行目に出力される文字列)を任意に変更します。
    • 項目の結合: 必要に応じて「姓」と「名」の属性を結合して1つの「氏名」列として出力する等の加工ロジックを記述します。

ユースケースによる使い分け: 「社内のデータバックアップや、全データをExcelでこねくり回したい」という要望にはパターンA(標準オプション)が手軽で最適です。 一方で、「他システム(会計ソフトなど)にそのまま取り込める形式でCSVを出力したい」という場合は、ヘッダー名や項目結合の制御が不可欠となるため、必ずパターンB(専用コンポーネント)で逆算して設計してください。

データ項目の内容を自動的に入力したい

実現できること(ゴールイメージ)

データを一箇所入力すると、関連する入力フォームが全て自動入力される動作を実現する、「自動補完」を設定します。
自動補完を使うと、参照型項目の参照先の項目や、座標データから住所を持ってきて、他の項目に自動セットさせることができます。

前提条件

参照型項目から値を取得したい場合は、参照先のモデルの設定を作成しておく

手順

  1. 対象のモデルの設定画面の「データ」設定を開く
  2. 参照先の項目は、仕様に応じて参照型か地図型(座標)を設定する
  3. 自動補完させる項目の詳細設定で「自動補完」の欄にて、参照先の項目を選択
  4. 上記設定の下に、「補完項目」の選択肢が表示されるので、補完したい項目を選ぶ

また、計算型も自動的に入力を行うという点では、類似していますが、詳しくは計算型のページをご覧下さい。計算型では、①数値同士を演算して、金額を出したり、税込み価格等を算出する ②明細型から合計金額を集計するといった際に利用します。

担当者を自動設定する

実現できること(ゴールイメージ)

タスクの担当者を、ユーザーが手動で選ばずとも、自動でアサインするような動作を実現します。
ここでは、2つのシナリオを想定して、それぞれの設定方法を解説しますが、1つめは、例えば選んだ顧客の担当者をそのまま業務の担当にする、といったマスターデータが持つユーザー型項目を活用する自動設定方法。2つめは、ログインユーザーに自動的に担当を割り当てる方法です。

前提条件 – ユーザー型項目からアサイン

マスターデータとなるモデルを作成し、ユーザー型項目を追加する

手順 – ユーザー型項目からアサイン

  1. 対象のモデルの設定画面で「データ」設定を開く
  2. 前提条件で作成したモデルへの参照型を追加
  3. 「プロセス」設定を開く
  4. アサインしたい担当者とタスクを追加
  5. 初期登録タスクの後に、「データ操作」を追加して設定を開く
  6. 更新先タイプは「担当者」、更新元タイプは「参照先」で、更新元で先ほど追加した参照型を指定
  7. 「追加」をクリックして操作のオペレーションを追加する
  8. 変更元の項目は前提条件で追加したユーザー型項目を指定、反映先の項目に4で追加した担当者を指定

前提条件 – ログインユーザーにアサイン

特になし

手順 – ログインユーザーにアサイン

  1. 対象のモデルの設定画面を開く
  2. 「プロセス」設定を選択
  3. 担当をクリック
  4. 設定ルールを「アサインされたユーザーがタスクを担当」にする
  5. 初期値を「ログインユーザー」にする

※この場合は、最初に登録したユーザー以外は基本的に編集できなくなります。

他のユーザーにも編集させたいときは、別の担当と、別のタスクを追加して、そちらにもプロセスを流すような設定が必要です。

項目の必須や任意、非表示等を設定する

実現できること(ゴールイメージ)

データ項目の必須や任意、非表示等の設定を行う。

こうした設定は、タスク毎に行います。例えば、ワークフローで申請者と承認者では、編集できる項目に違いがあるはずですが、そのようにモデルを取り扱う場面に応じて、必須や任意を設定する、という考え方です。

手順1

  1. 対象のモデルの設定画面を開く
  2. 「プロセス」設定を選択
  3. 任意のタスクの設定画面を開く
  4. 「編集権限」タブで、各項目について「必須」「任意」「読み取りのみ」「未使用」「非表示」から権限を選びます。

※「未使用」は表示せず登録を行わない

※「非表示」は表示しないが登録は行う。例えば、初期値を登録させたい場合や、自動補完される値を登録した場合等に使います。

表示設定について、一点注意が必要です。これは、あくまでもタスクを開いた入力フォームでの設定です。リストや閲覧画面での表示には何ら関わりがありません。

それらリストや閲覧画面から非表示にしたい場合は以下の手順で行います。

手順2

  1. 対象のモデルの設定画面を開く
  2. 「データ」設定で該当の項目のオプション設定>「閲覧可能か」を閲覧不可にする

登録・更新時の「日付・時間」を自動で記録する

実現できること(ゴールイメージ)

「出荷タスクを完了した日を出荷日とする」「受付タスクを通った時間を受付時間とする」など、特定の業務処理(タスク)が行われたタイミングの日時を、データ項目としてバックエンドで自動的に記録・保存します。 ユーザーに手動でカレンダーから日付を選ばせる手間を省き、入力漏れや日付の入力ミスを完全にゼロにします。ここで記録された日付は、他のデータ操作での期間計算や、一覧画面でのソート・条件検索にそのまま活用できます。

前提条件(必要なモデル)

  • 対象のモデルに、業務データとして活用したい 「日付型」 や 「時間型」の属性があらかじめ定義されていること。

手順

設定は「①バックエンドでの自動書き込み(ロジック)」と、「②入力・閲覧画面の制御(UI)」の2つのステップで行います。

ステップ①:プロセスに「データ操作」を挟み、システム値を書き込む

特定のタスク(状態)が完了した直後のタイミングで、システムが持つ「その瞬間の日時」を属性データに保存します。

  1. データ操作ノードの配置
    • 対象モデルのプロセス編集画面を開きます。
    • トリガーとしたいタスク(例:「出荷」「完了」など)の直後の矢印線上に、[データ操作] ノードを配置します。
  2. システム値(今日・今)の反映ロジックを設定
    • データ操作の設定パネルを開き、以下の設定を行います。
    • 日付項目への書き込み: タイプ=システム値、反映元の項目=今日
    • 時間項目への書き込み: タイプ=システム値、反映元の項目=今
    • ※これにより、タスクが次の状態に進んだ瞬間の正確な日付・時間が、データ項目として確定・保存されます。
ステップ②:タスク設定で「入力時は非表示」に制御する

自動反映されるデータ項目をユーザーが手動で誤って書き換えないよう、画面上の権限を設置します。

  1. 入力フォーム(処理中)では非表示にする
    • データ操作の手前にある「入力タスク」の編集権限設定を開きます。
    • 該当の属性(例:出荷日・出荷時間)の表示ステータスを 「非表示」 に設定します。
    • ※自動取得される項目を入力画面から隠すことで、ユーザーに「何を入力すればいいんだろう?」と迷わせるノイズを排除します。

定期実行処理(バッチ処理)をプロセスで実装する

実現できること(ゴールイメージ)

「毎日AM 9:00にリマインドを送る」「毎月1日に定期請求データを生成する」といった定期実行処理(バッチ処理)を、外部システムや複雑なプログラムを使わず、NuAppのプロセス(ワークフロー)設定のループ構造だけで実現します。

前提条件(必要なモデル)

  • バッチ処理の「次回実行タイミング」を保持するための 「日付型」の属性が、対象モデルにあらかじめ定義されていること。
  • ※基本的には、バッチを起動・管理するための「バッチ管理レコード」をシステムに1件だけ登録して運用します。

手順

設定は、プロセス上に「待機 ➔ 実行 ➔ 日付の更新 ➔ ループ」のサイクルを描くことで実現します。

  1. スケジューラーイベントの配置(待機)
    • 対象モデルのプロセス編集画面を開きます。
    • フローの起点に 「スケジューラーイベント」 ノードを配置します。
    • 設定パネルの実行日付で、モデル内の [次回実行日(日付型)] 属性を指定します。
    • ※システムはこのノードに到達すると、指定された日付(および指定時間)が来るまで処理を一時停止(シームレスに待機)します。
  2. 実行したい処理の配置(実行)
    • スケジューラーイベントの「次」に、実際に定期実行させたい処理(例:通知を飛ばすメッセージ送信、データを更新するデータ操作、モデル連携など)を配置して矢印を繋ぎます。
  3. 実行日の更新ロジックの配置(日付の加算)
    • 実行したい処理のさらに「次」に、新しく [データ操作] ノードを配置します。
    • 待機に使用した日付属性を、次の実行タイミング(翌日や翌月)に進める設定を行います。
      • 毎日実行したい場合: 反映元の項目=固定値1、反映先の項目=次回実行日、操作=日付加算や営業日加算
      • 毎月実行したい場合:反映元の項目=固定値1、反映先の項目=次回実行日、操作=月加算
  4. 矢印をスケジューラーに戻す(ループの完成)
    • 日付を更新したデータ操作ノードから、一番最初の「スケジューラーイベント」に向かって逆向きにプロセスの矢印を引き戻します。
    • ※これにより、「日付が来る ➔ 処理する ➔ 日付を翌日に進める ➔ 翌日までまた待機する」という永久機関(バッチループ)が完成します。
  5. 初期実行時のタスク設置
    • プロセスはタスクがなければ開始できません。最初に開始するためのタスクを作成し、次回実行日の初期値を入力させるようにして、スケジューラーに繋ぎます。一度回り始めれば、あとはシステムが自動で日付を更新しながら回り続けます。

ログインユーザー自身のデータのみを一覧表示する

実現できること(ゴールイメージ)

アプリの一覧画面を開いた際、ログインしているユーザー(自分)が担当しているデータだけを初期表示、または強制的に限定表示する「マイタスク」「マイデータ」画面を構築します。 ユーザーが毎回自分の名前で検索し直す手間を省くと同時に、業務セグメントの分離やセキュリティの向上を実現します。要件に合わせて、以下の2つの実装アプローチを使い分けます。

  • アプローチA(厳密・推奨): リストコンポーネント を使用し、自分以外のデータをシステム的に強制非表示にする(他人のデータを閲覧させたくない場合)。
  • アプローチB(簡易): 検索コンポーネント を使用し、初期表示のみを自分のデータに絞り込む(他人のデータも検索すれば見られる状態にしたい場合)。

前提条件(必要なモデル)

  • 対象のモデルに、担当者を表す 「ユーザー型」(またはログインユーザーのIDやアカウントと紐付けられる属性)が定義されていること。

手順

パターンA:リストコンポーネントで「強制的に非表示」にする場合

画面の検索条件に関わらず、システム裏側のフィルターで「自分のデータのみ」に完全にロックをかける、最も堅牢な方法です。

  1. アプリの画面編集を開く
    • [設定] > 対象の アプリ > [Web向けメニュー] の画面編集を開きます。
  2. 「リスト」コンポーネントを配置する
    • 画面上に 「リスト」(または一覧表示用のコンポーネント)を配置し、対象のモデルを紐付けます。
  3. コンポーネント固定の抽出条件を設定する
    • リストコンポーネントの個別設定パネル内にある「抽出条件」を開きます。
    • 以下のように、担当者属性がログインユーザー自身である条件を設定します。
    • [担当者] == ログインユーザー(※meボタンをクリックします)
    • ※この設定により、ユーザーが画面側でどう操作しようとも、裏側のクエリレベルで自分のデータ以外は完全にシャットアウトされます。
パターンB:検索コンポーネントで「自分のデータを初期表示」にする場合

通常の一覧画面(検索画面)をベースにしながら、他のユーザーのデータを隠蔽、または初期表示を自分にする方法です。

  1. 「検索コンポーネント」を配置する
    • メニュー画面に 「検索」 コンポーネントを配置します。
  2. 検索の初期値(デフォルト値)を設定する
    • 検索条件の「担当者」項目の初期値設定(デフォルト値)に、システム値の ログインユーザー を指定します。これで開いた瞬間は自分のデータだけが表示されます。
  3. 【重要】他人のデータを見せないためのガードレール設定
    • もし「他人のデータを見せたくない(でも検索コンポーネントの見た目をベースにしたい)」という場合は、検索フォームに表示する項目から「担当者」を明示的に外します(非表示にする)。
    • ※検索条件から「担当者」の選択ボックス自体を消し去ることで、ユーザーが他人の名前に条件を切り替える操作自体を不可能にします。

セキュリティ要件による使い分けの鉄則: 「個人情報の兼ね合いで、他人のデータは存在すら知られてはならない」という厳格な要件(例:顧客向けのマイページ、外注先専用のタスク一覧など)の場合は、必ずパターンA(リストコンポーネントの固定条件)で設計してください。 一方で、「普段は自分の仕事に集中したいが、同僚の進捗も必要に応じて検索して確認したい」という社内向けの業務画面であれば、パターンB(検索コンポーネントの初期値設定)で「担当者」項目を残したままにしておく設計がベストプラクティスです。

地図やGPS情報を活用する方法

実現できること(ゴールイメージ)

NuAppでは、スマートフォンのGPS機能やマップと連動した、位置情報を活用するアプリ(例:訪問ルート営業管理、設備・現場のマップ可視化)を簡単に構築できます。 要件(ざっくりとしたイメージ)に合わせて、以下の3つのアプローチから最適な方法を選択します。

前提条件(必要なモデル)

  • 対象のモデルに、位置情報の基準となる「住所(テキスト型 or 座標 or 位置情報)」の属性があらかじめ定義されていること。

要件別の実装アプローチ(どれを選ぶ?)

アプローチ①:現在地や住所を「地図で確認」したい(初級)

  • やりたいこと: 顧客マスタにある住所をクリックしたら、その場所のGoogleマップを開きたい。
  • 実装方法:
    • モデルのデータ項目として 「地図型」 を使用します。
    • 地図型のタイプは、住所を入力する場合は「住所」、地図から位置を指定する場合は「座標」を選びます
    • ※ユーザーは画面上のリンクを1クリックするだけで、即座に正しい地図を確認できます。

アプローチ②:複数のピンを「1つの地図にまとめて表示」したい(中級)

  • やりたいこと: 本日の訪問予定先の一覧や、自社の管理している設備の一覧を「地図(マップビュー)」として俯瞰したい。
  • 実装方法:
    • 対象のアプリ設定を開き、メニューのコンポーネントとして 「地図へのデータ表示」 を選択して配置します。(Web版、スマホ版両対応)
    • 設定パネルで、ピンを立てる基準となる「住所(または緯度・経度)の属性」を指定します。
    • ※これだけで、検索結果に該当するデータが地図上に一斉にピン留めされて表示されます。
    • Point!:地図上のピンを選んで、その物件での報告入力、といった場合には、次のアクションで物件→報告を設定しておきます。これによりピンを選んで登録といった自然な流れを実現できます。

アプローチ③:スマホのGPSで「現在地を取得・記録」したい(上級)

  • やりたいこと: 「外回り中の営業マンや配達員の“今の居場所”をリアルタイムに把握したい」または「現場に本当に到着して作業したという“証憑(エビデンス)”を残したい」。
  • 実装方法: 要件に合わせて、NuAppが提供する以下の2つの強力なGPSパターンを使い分けます。
パターン実装方法と仕組み主なユースケース
1. 定期自動送信(現在地把握)スマホアプリ側のHome > 設定で「位置情報送信」をONにします。
これにより、端末から一定時間ごとに現在地が自動送信され、NuApp標準の「位置情報モデル」が自動更新されます。このモデルをベースに地図ビューを組むことで、ユーザーごとの直近の居場所をマップ上に一斉ピン表示できます。
動態管理、配達員のルート追跡、緊急時のスタッフ配置確認など
2. ワンタップ付与(位置の証憑)業務モデルのデータ項目(属性)に、「地図型(現在位置タイプ)」を追加します。
ユーザーがアプリの入力画面でボタンをワンタップすると、その瞬間の位置情報とタイムスタンプがデータに直接付与されます。後から改ざんできないため、正しい場所で作業や報告が行われた確固たる証拠になります。
外出先からの日報入力、設備点検の完了報告、直行直帰の打刻など

住所 vs 緯度経度: 基本的な地図表示(アプローチ①・②)であれば「住所(テキストデータ)」の登録だけで動くため、ユーザーの入力ハードルは低くなります。ただし、「住所表記の揺れ」によるピンズレを防ぎたい場合や、山奥の設備など住所がない場所を扱う場合は、最初から「緯度・経度(数値型)」でデータを保持するモデル設計にすることを推奨します。
応用編: 上記のいいとこ取りをするために、入力は住所で行い、別項目で座標タイプを設けて、裏でデータ操作により住所→座標を反映。その後、位置調整が必要であれば地図上で、細かい座標を指定する。というワークフローにも対応できます。

スマホやタブレットで手書きサインを入力する

実現できること(ゴールイメージ)

端末の画面上に指やスタイラスペンで直接サイン(署名)してもらい、それを画像データとしてシステムに登録・保存する「手書きサイン機能」を構築します。 検収書、作業完了報告書、秘密保持の同意確認など、現場でのペーパーレス化や証憑(エビデンス)確保に最適です。

前提条件(必要なモデル)

  • 特になし

実装手順(ステップ・バイ・ステップ)

手書きサインは、独立した「サイン型」があるわけではなく、「ファイル型」属性を使えばスマホ版アプリから入力可能です。

  1. モデルの属性(項目)を追加・変更する
    • モデルを作成し、サインを保存するための「ファイル型」項目を追加する。
    • ※これだけで、スマホ等の端末から該当項目をタップして、手書き入力を選択した際、手書き用のキャンバス(入力領域)が起動するようになります。
  2. 【推奨】サイン専用(手書きのみ)に制御する
    • より「サイン欄」としての使い勝手を高めるため、同設定パネル内にある「スマホからの登録制限」で手書きのみを選択する。
    • ※この設定を行うことで、ユーザーが間違えてアルバムから写真をアップロードするなどの誤操作を防ぎ、純粋なサイン専用欄として画面を固定できます。

カスタム属性をモデル間で共通化・連動させる

実現できること(ゴールイメージ)

マスター側(例:案件モデル)で登録した独自のカスタム属性(可変フィールド)を、トランザクション側(例:報告書モデル)へ自動的に引き継ぎ、共通化させます。 これにより、「案件Aを選んだら、案件A専用のカスタム属性項目が報告書画面に自動で出現する」といった、現場の運用をスムーズにする動的な画面・データ連携が実現します。

前提条件(必要なモデル)

  • マスターとなる親モデル(例:案件モデル)
  • トランザクションとなる子モデル(例:報告書モデル。属性として「案件モデル」への 参照型 を持っていること)

実装手順(ステップ・バイ・ステップ)

設定は「①モデル(裏側)」「②アプリ(画面)」「③データ操作(連動)」の3ステップで行います。

ステップ①:モデル設定で「グループID」を統一する(裏側の紐付け)

通常は自動割り当てされるIDを手動で一致させ、2つのモデルのカスタム属性が「同じ器」であることをシステムに認識させます。

  1. マスター側のグループIDを確認する
    • [設定] > [モデル一覧] から「案件モデル」を選択し、カスタム属性の設定画面を開きます。
    • 設定されている 「グループID」(英数字の文字列)をコピーします。
  2. トランザクション側に同じグループIDをセットする
    • 「報告書モデル」のカスタム属性項目の設定を開きます。
    • 普段は自動生成されるグループIDの欄に、先ほどコピーした「案件モデルと全く同じグループID」を入力して保存します。
ステップ②:アプリ設定で「カスタム属性」コンポーネントを配置する(画面の設置)

マスター側で、ユーザーがカスタム属性を追加・管理できるように画面を整えます。

  1. 親側のアプリ設定を開く
    • [アプリ設定] から「アプリ」の画面編集(Web向けメニュー)を開きます。
  2. コンポーネントの配置
    • 任意の場所に 「カスタム属性」コンポーネント を配置して、案件モデルとそのカスタム属性を指定します。これにより、案件ごとに自由に項目を追加できるエリアが画面に用意されます。
ステップ③:データ操作で「値のコピーと自動取得」を組む(プロセスの連動)

報告書側で案件を選択した際、裏側でデータを同期させます。

  1. データ操作の追加
    • 「報告書モデル」のプロセス設定を開き、案件が選択された(またはタスクが遷移した)タイミングの [データ操作] ノードを追加します。
  2. カスタム属性値のコピー設定
    • 参照している「案件」のカスタム属性データを、自身の「報告書」のカスタム属性へコピーするデータ操作ロジックを記述します。
  3. タスク開示時の自動取得
    • これにより、ユーザーが後に報告書アプリで該当タスクを開いた際、引き継がれた可変フィールド(カスタム属性)が自動取得されて画面に出現し、値が入力可能な状態になります。

ライフサイクルの意識: マスター側のカスタム属性が「後から追加・変更」された場合でも、ステップ③のデータ操作(自動取得)が走るタイミングで最新の定義がトランザクション側に反映されます。どのタイミングでデータを同期させるか、業務フロー(タスク)の引き金を意識して設計してください。

帳票を添付した定型メールを自動送信する

実現できること(ゴールイメージ)

請求書や報告書などのPDF帳票を自動で生成し、顧客マスタ等に登録されているメールアドレス宛に添付メールとして自動送信します。 手動でPDFをダウンロードしてメールに添付する手間を完全に無くし、送信ミス(添付間違いや宛先間違い)をシステム構造的にゼロにします。

前提条件(必要なモデル・帳票定義)

  • 顧客マスタ(参照モデル): 属性として 「リンク型(メール)」 のメールアドレス項目が定義されていること。
  • 自モデル(トランザクション): 属性として上記「顧客マスタ」への 参照型 項目を持っていること。
  • 帳票テンプレート: 自モデルのデータを流し込むための「帳票設定」が事前に完了していること。(例えば、モデルの「その他設定」>「帳票出力」で設定できます)

手順

設定は「①宛先とメッセージの設定」「②帳票の自動添付設定」「③送信タイミングの制御」の3つに分けて行います。

ステップ①:メールイベントを作成し、顧客のメールアドレスを動的に指定する

宛先をデータに紐づく顧客のアドレスから自動取得させます。

  1. メールイベントの追加
    • 対象モデルのプロセス編集画面を開き、メール送信を行いたい場所に 「メールイベント」 ノードを配置します。
  2. 宛先(To)の動的設定
    • メールイベントの設定パネルを開き、送信先タイプ で 「参照型の項目」 を選択します。
    • 選択肢から、[顧客マスタの参照項目] > [メールアドレス(リンク型)] を指定します。
    • ※これにより、その伝票に紐づいている顧客のアドレスへ動的にメールが送られます。
ステップ②:送信直前のデータを帳票に自動出力して添付する

システムが送信ボタンを押した瞬間の最新データをPDF化して自動添付します。

  1. 添付ファイル種別の指定
    • メールイベント内のオプション設定にある「添付ファイル種別」で 「帳票」 を選択します。
  2. 対象帳票の紐付け
    • あらかじめ作成しておいた、自モデルに対応する帳票テンプレート(例:請求書PDFなど)を選択します。
    • ※この設定により、メールが送信される直前に、自データの内容が自動的に帳票へレンダリング(出力)されてメールに添付されます。
ステップ③:プロセス設計等による「一回だけの送信」制御

顧客へ送信するメールが、プロセスの行き来(差し戻しなど)によって何度も誤送信されるのを防ぐための設計の工夫です。

  1. ユーザーが手動制御
    • タスクで「送信」ボタンを押したらメールイベントに遷移するといったフローにする。
  2. 送信専用タスク(またはイベント)の単一化
    • 通常の編集タスクの中にメール送信トリガーを混ぜるのではなく、例えば「承認完了」から「確定(完了)」へ遷移する矢印の線上(イベントノード)にメール送信を配置します。
  3. 送信済ステータスの管理(ガードレールの設置)
    • 万が一、完了後にデータを修正して再送信ルートを通る可能性がある場合は、モデル側に「メール送信フラグ(チェックボックス等)」を用意します。
    • メール送信イベントの実行条件に [メール送信フラグ] == False を設定し、送信直後のデータ操作でフラグを True に書き換えることで、「然るべきタイミングで、生涯に1回だけしか送信されない」堅牢なプロセスを設計します。

即時送信 vs ユーザー確認: プロセス上に直接メールイベントを置くと「ボタンを押した瞬間にサイレントで即時送信」されます。もしユーザーに「送信前に文面を最終確認・微調整させたい」という要件がある場合は、 「メール作成タスク」 をプロセスに配置し、メールテンプレートからコピーした文面を一度プレビュー・編集させる設計パターンへの切り替えを検討してください。

目次