設計情報

投稿者:SPIRERS ナレッジ向上チーム 2022年3月31日 (木)

Web申請アプリ アプリ(DB・メール)設計・構築

SPIRAL ver.2はプログラミング経験がなくても、オリジナルの業務アプリの制作・カスタマイズできるローコード開発プラットフォームです。
詳しくは SPIRAL ver.2 とはをご覧ください。

SPIRAL ver.2を初めて操作する際に何をどう設定すればいいのか?どう管理すればいいのか?と迷う方も多いのではないでしょうか。そこで活用シーンが多い業務アプリの作成手順を通して、
アプリ(DB・メール)設計・構築 / サイト設計・構築 / ユーザ・アプリロール・グループ設定
を各工程を分け、ポイントやおすすめ機能・強化ガジェットを紹介いたします。

第一弾は「Web申請アプリ」です。
この記事は アプリ(DB・メール)設計・構築 のフェーズとなります。
ボリュームのある記事ですが、最後までお読みいただけますと幸いです。
関連記事はこちら

変更・改定履歴

  • 追加

    Web申請フォームデモへのリンクを追加

アプリ機能

SPIRAL ver.2はアプリを定義した後にDBやページ、フォームを設定することができます。
DB設定、通知メール設定はアプリ機能にて行います。
詳しくは アプリ機能 をご覧ください。
今回は、アプリ機能を使って「Web申請DB」と「各種通知メール」を作成します。

登場人物と業務フローの整理

まずはWeb申請アプリを作成するにあたり、Web申請アプリを使う登場人物とそれぞれの人物がアプリ上でどのようなことができるのか、どのような業務を行うのかをまとめてみました。
今回は「申請者」「事務局担当者」「事務局長」を登場人物とした、よくあるWeb申請アプリを想定しました。
登場人物(Web申請アプリを使う人)
またWeb申請アプリの業務フロー図も作成しました。
業務フロー図を作成すると全体の業務が可視化され、対応漏れを防止するための未対応アラートメールが必要など、構築すべき機能の整理ができました。
頭の中に思い描いたイメージの整理にもなるので簡単な業務フロー図を作成するのもおすすめです。
業務フロー図

アプリ(DB、メール)設計・構築

登場人物と業務フローの整理がある程度完了したので、アプリを作成していきます。
アプリ全体像
※ 事務局操作画面(赤枠部分)についてはユーザ・アプリロール・グループ設定記事をご覧ください。
DBについて
まずWeb申請DBを作成します。
大きく分けて、申請者が入力する項目と事務局が入力する項目でDB設計しました。
その他に必要な項目があれば追加可能です。
詳しくは DB機能 をご覧ください。

▼Web申請アプリ DBフィールド一覧
項目名 フィールドタイプ    
申請番号 テキスト 申請者が入力する項目
氏名 テキスト
会社名 テキスト
郵便番号 テキスト
都道府県 セレクト
市区町村・番地 テキスト
ビル名・部屋番号等 テキスト
電話番号 電話番号
メールアドレス メールアドレス
業種 セレクト
業種_その他 テキスト
書類ファイル ファイル
同意 マルチセレクト
ステータス(事務局担当者) セレクト 事務局が入力する項目
ステータス(事務局長) セレクト
ステータス(申請者-再申請) セレクト
ステータス(共通) セレクト
【申請者向け】事務局担当者コメント入力 テキストエリア
【事務局長向け】事務局担当者コメント入力 テキストエリア
【事務局担当者向け】事務局長コメント入力 テキストエリア
ポイント①
SPIRAL ver.2ではメンテナンス項目が自動追加されるので、Web申請の際に必要となる項目のみで設計します。
▼自動追加メンテナンス項目
項目名    
作成日 データが登録された日時(例:2022/04/01 12:00:00)
作成経路 データの登録元(例:Form ※Web申請フォームからの登録の場合)
作成者 データを登録した人物名
(例:Web申請 ※申請者がWeb申請フォームから登録した場合はフォーム名)
(例:パイプ太郎 ※Web申請操作画面からの場合は事務局担当者名)
最終更新日時 データが更新された日時(例:2022/04/01 15:00:00)
最終更新経路 データの更新元(例:UI ※Web申請操作画面からの更新の場合)
最終更新者 データを更新した人物名
(例:パイプ太郎 ※Web申請操作画面からの場合は事務局担当者名)

また本アプリでは事務局側でステータス管理を行うため、
「事務局担当者用ステータス項目」「事務局長用ステータス項目」「申請者-再申請用ステータス項目」「共通ステータス項目」の4つの項目を使用するよう設計しました。
1つのステータス項目で管理をすると担当者なのに「承認」ができてしまうなど不都合が発生するので、担当者にしか変更できないステータス または 局長にしか変更できないステータスと分けてみました。

またなぜ共通ステータス項目を存在しているかというと、DBトリガのレコードアクション(全体像①)を使用すれば担当者用のステータスや局長用のステータスを自動的に共通ステータスに格納することができるからです。
この設定を行うことでそれぞれが確認するのは共有ステータスのみでよいので、ステータス認識を統一することができます。
ポイント②
DBトリガのレコードアクション を使用すれば、簡単に自DB内の別項目に指定した項目の値を格納することができます。もちろん他DBへも可能です。
詳しくは DBトリガのレコードアクション をご覧ください。
本アプリのステータス関連レコードアクショントリガの処理発動条件が少し複雑になるため詳細な発動条件をご案内します。
「(1)ステータス(事務局担当者、事務局長)をステータス(共通)へ格納」と
「(2)事務局担当者・事務局長のステータス更新」を更新トリガで作成します。

(1)ステータス(事務局担当者、事務局長)をステータス(共通)へ格納 トリガ
 このトリガでは以下3つの処理を設定しますが、いずれかの処理が成功すると以降の処理は発動しません。
1-1 ステータス(申請者-再申請)をステータス(事務局担当者、共通)へ格納 処理
この処理は申請者が再申請フォームより更新した際、にステータス(申請者-再申請)の値をステータス(事務局担当者)とステータス(共通)へ格納させたいので発動条件を下記に設定します。
発動条件 指定する
経路条件:一部の経路(フォーム)
簡易条件:指定しない
処理タイプ 更新
処理マッピング アクション先DBフィールド:ステータス(事務局担当者)=格納値:ステータス(申請者-再申請)
アクション先DBフィールド:ステータス(共通)=格納値:ステータス(申請者-再申請)
エラー処理 全てエラー終了

1-2 ステータス(事務局長)をステータス(共通)へ格納 処理
この処理は事務局長が操作画面からステータス更新した際に、ステータス(事務局長)の値をステータス(共通)へ格納させたいので発動条件を下記に設定します。
発動条件 指定する
経路条件:一部の経路(操作画面)
簡易条件:指定する
└ステータス(共通)|等しい|承認依頼
└ステータス(共通)|等しい|事務局長チェック中
└いずれかの条件を満たす
処理タイプ 更新
処理マッピング アクション先DBフィールド:ステータス(共通)=格納値:ステータス(事務局長)
エラー処理 全てエラー終了

1-3 ステータス(事務局担当者)をステータス(共通)へ格納 処理
この処理は事務局担当者が操作画面よりステータス更新した際に、ステータス(事務局担当者)の値をステータス(共通)に格納させたいので発動条件を下記に設定します。
発動条件 指定する
経路条件:一部の経路(操作画面)
簡易条件:指定する
└ステータス(共通)|等しい|申請
└ステータス(共通)|等しい|事務局差戻し
└ステータス(共通)|等しい|再申請
└ステータス(共通)|等しい|承認差戻し
└ステータス(共通)|値なし
└いずれかの条件を満たす
処理タイプ 更新
処理マッピング アクション先DBフィールド:ステータス(共通)=格納値:ステータス(事務局担当者)
エラー処理 全てエラー終了

(2)事務局担当者・事務局長のステータス更新 トリガ
 このトリガでは以下3つの処理を設定しますが、いずれかの処理が成功すると以降の処理は発動しません。
2-1 初回承認依頼 処理
この処理は事務局担当者が操作画面から初回承認依頼した際に、ステータス(事務局担当者)の値をステータス(事務局長)へ格納したいので発動条件を下記に設定します。
発動条件 指定する
経路条件:一部の経路(操作画面)
簡易条件:指定する
└ステータス(事務局長)|値なし
└ステータス(事務局担当者)|等しい|承認依頼
└すべての条件を満たす
処理タイプ 更新
処理マッピング アクション先DBフィールド:ステータス(事務局長)=格納値:ステータス(事務局担当者)
エラー処理 全てエラー終了

2-2 ステータス(事務局長)をステータス(事務局担当者)へ格納 処理
この処理は事務局長が操作画面から承認差戻しにステータス更新した際、ステータス(事務局長)の値をステータス(事務局担当者)へ格納したいので発動条件を下記に設定します。
発動条件 指定する
経路条件:一部の経路(操作画面)
簡易条件:指定する
└ステータス(共通)|等しくない|承認差戻し
└ステータス(共通)|等しくない|承認
└ステータス(共通)|等しくない|否認
└ステータス(事務局長)|等しい|承認差戻し
└すべての条件を満たす
処理タイプ 更新
処理マッピング アクション先DBフィールド:ステータス(事務局担当者)=格納値:ステータス(事務局長)
エラー処理 全てエラー終了

2-3 ステータス(事務局長)をステータス(事務局担当者)へ格納 処理
この処理は事務局担当者が操作画面から2回目以降の承認依頼した際に、ステータス(事務局担当者)の値をステータス(事務局長)へ格納したいので発動条件を下記に設定します。
発動条件 指定する
経路条件:一部の経路(操作画面)
簡易条件:指定する
└ステータス(共通)|等しくない|承認依頼
└ステータス(事務局担当者)|等しい|承認依頼
└ステータス(事務局長)|等しくない|事務局長チェック中
└ステータス(事務局長)|等しくない|承認
└ステータス(事務局長)|等しくない|否認
└すべての条件を満たす
処理タイプ 更新
処理マッピング アクション先DBフィールド:ステータス(事務局長)=格納値:ステータス(事務局担当者)
エラー処理 全てエラー終了

以上でDB関連の設定は完了です。
メールアクションについて
DB作成が完了したら次はメールアクション設定です。
業務フロー図を見てもらうとわかるように本アプリでは複数の通知メールを配信し、登録や更新があった場合や未対応の申請がある旨を知らせるようにしています。
Web申請業務の中で最も避けたいのが「対応漏れ」です。申請登録後即時に担当者へ通知メールを配信したり、万が一未対応が発生してもアラートメールを配信したりすることで、早期に気が付くことができるので顧客満足度の高いアプリの作成が可能です。

▼Web申請アプリ 配信メール一覧
配信名 配信条件・配信先 機能
①申請登録完了メール 抽出ルール:なし
配信指定方法:レコード(申請者メールアドレス)
API配信
(申請後、即時配信)
②申請通知メール 抽出ルール:ステータス(共通)が「申請」
配信指定方法:固定(事務局担当者メールアドレス)
非同期アクション
(更新後、即時配信)
③事務局差戻し通知メール 抽出ルール:ステータス(共有)が「事務局差戻し」
配信指定方法:レコード(申請者メールアドレス)
非同期アクション
(更新後、即時配信)
④再申請通知メール 抽出ルール:ステータス(共通)が「再申請」
配信指定方法:固定(事務局担当者メールアドレス)
非同期アクション
(更新後、即時配信)
⑤承認依頼通知メール 抽出ルール:ステータス(共通)が「承認依頼」
配信指定方法:固定(事務局長メールアドレス)
非同期アクション
(更新後、即時配信)
⑥承認差戻し通知メール 抽出ルール:ステータス(共通)が「承認差戻し」
配信指定方法:固定(事務局担当者メールアドレス)
非同期アクション
(更新後、即時配信)
⑦申請結果通知メール 抽出ルール:ステータス(共有)が「承認」または「否認」
配信指定方法:レコード(申請者メールアドレス)
非同期アクション
(更新後、即時配信)
⑧未対応アラートメール 抽出ルール:ステータスが「申請」 かつ 申請日が1日以上経過しているデータ または ステータスが「再申請」「承認差戻し」かつ更新日時が1日以上経過している
配信指定方法:固定(事務局担当者メールアドレス)
スケジュールトリガ&
メールアクション
(該当データがあれば、毎日9:00配信)
※ ①申請登録完了メールは、サイト設計・構築 にて設定します。
ポイント③
アプリ操作画面からデータ登録・更新・削除をきっかけにメール配信が実行される非同期アクション機能や定期実行できるスケジュールトリガと高度な条件が設定できるメールアクションを組み合わせた配信機能を用意しているので、これらを駆使して最適なタイミングに最適な条件でメール配信が可能です。
各機能の詳細に関しては、下記をご覧ください。
DBトリガの非同期アクション
スケジュールトリガのメール配信アクション

①~⑦の通知メールは非同期アクション機能(全体像②)を使用して配信します。
1画面で「経路条件・配信先指定・配信条件・配信コンテンツ」を設定できるので、とても簡単です。
詳しくは DBトリガの非同期アクション をご覧ください。

⑧未対応アラートメール配信はスケジュールトリガ機能とメールアクション機能(全体像③)を組み合わせて事務局担当者へメールが配信されるよう設定しています。
こちらは配信条件が少しだけ複雑なので詳細に案内します。

(1)スケジュールトリガ設定
毎日9時00分にアクションが実行されるよう設定します。
表示名 未対応アラートメール配信トリガ
実行タイミング 毎日9時00分

(2)アクション設定
(1)のスケジュールトリガに紐づくアクションを設定します。差出人・コンテンツ部分は自由に入力します。
表示名 未対応アラートメール配信アクション
アクションタイプ メール配信(複数レコード)
ステータス 有効
DB Web申請DB
指定方法:固定
配信条件 条件:条件付き配信(高度な条件設定)※ 1
宛先メールアドレス:事務局担当者メールアドレス
配信エラー除外 1回以上
差出人・コンテンツ 差出人メールアドレスや件名・文面を自由に入力
※1 高度な条件設定の抽出条件式は下記をお使いください。
▼抽出条件式
@status = '1' AND @_createdAt <= NOW() - INTERVAL('1 day') OR @status IN ('3', '5') AND @_updatedAt <= NOW() - INTERVAL('1 day ')
▼抽出条件式の解説
以上でメール関連の設定は完了です。

最後に

設定後は動作確認を必ず行い、動作に問題がないか確認をしてください。
また、不具合やほかのやり方が知りたい等あれば、下記の「コンテンツに関しての要望はこちら」からご連絡ください。
アプリ(DB・メール)設計・構築が完了したので次はサイト設計・構築に進みます。

関連記事はこちら
コンテンツに関しての
要望はこちら