頂戴した懸念事項を一問一答形式で整理し、各項目について「できる／できない」だけでなく、なぜそれが可能なのか（仕組み・原理）を解説した資料です。
前提となる弊社のアプローチは、既製パッケージに業務を合わせるのではなく、業務に合わせて設計するスクラッチ開発（受託開発）です。以下の回答もこの前提に基づきます。
鍵は、ワークフローシステムを「申請書を作る道具」ではなく「申請書を運ぶ道具」として設計することです。
承認者は添付された申請書ファイルを開いて中身を確認し、システム上では承認ボタンを押すだけです。申請書の「中身」と、承認の「流れ」を別レイヤに分離しているため、様式が何種類あっても、将来何度変わっても、システム改修は発生しません。
御社のWebメールは一定時間で自動ログアウトします。つまり「通知を受け取り続ける受け皿が常駐していない」のが問題の本質です。一方、サイボウズデスクトップアプリは常駐しています。だからそこへ通知を出せばよい、という発想になります。
ここで一つ壁があります。サイボウズデスクトップアプリの通知は、基本的にサイボウズ Office自身に起きたイベント（メッセージ着信など）に紐づいて表示されます。外部のワークフローシステムで起きたことを、アプリは直接は知りません。
そこで「翻訳」を挟みます。ワークフロー側で承認依頼が発生したら、その内容をサイボウズ Office内に通知（メッセージ等）として書き込みます。すると、サイボウズから見れば「自分のところに新着メッセージが来た」という自分自身のイベントになり、デスクトップアプリは普段どおりそれを通知します。
多くのシステムは「1人＝1所属＝1役職」を前提にユーザを登録します。承認者を「○○部の課長」と役職で指定したとき、その人が複数の顔（部署A課長／部署B主任）を持てないと、兼務時に承認がうまく回りません。
解決策は、「人」と「役職・所属」を切り離し、1人に複数の役割をぶら下げるデータ構造にすることです。1人のユーザに対して「部署A・課長」「部署B・主任」といったポスト（役割）を複数登録します。承認ルートは「人名」ではなく「ポスト」で指定します。
申請が来ると、システムは該当ポストを持つ人を探して回付します。結果、同一人物が、部署Aの案件では課長として、部署Bの案件では主任として、それぞれ別々に承認画面に並びます。
ルートを「申請のたびに人が手で指名する」のではなく、「ルール表（マスタ）から自動で導き出す」方式にします。
あらかじめ承認ルートマスタに、「申請種別 × 申請者の役職 × 金額レンジ × 部署」→「経由するポストの並び」という対応表を定義しておきます。申請が出された瞬間、システムは申請者の属性（役職・部署）と申請内容（種別・金額）を条件にこの表を引き、承認者の並びを自動生成します。
これにより「課長本人が出した申請に課長承認は付けない」「少額なら部長を飛ばす」といった制御が自動で効き、不要な上位・下位者への回付を抑止できます。
採番は、システムが「連番カウンタ」を一元管理することで実現します。申請が確定した瞬間に「年度＋申請種別コード＋連番」の番号を払い出します。複数人が同時に申請しても、内部の排他制御により番号は順番に払い出され、重複は起こりません。
「データベース化」とは、申請1件をデータベースの1レコードとして、番号・申請者・日付・金額・状態・添付ファイルの所在などを項目（カラム）に分けて保存することです。Excelの台帳と違い、構造化されているため、番号順の並び替え・絞り込み・検索が確実に行えます。
1件の申請レコードに対して、複数の添付ファイルを1対多で紐付けます。ファイルの実体はストレージに保存し、データベースには「どの申請の・何という名前の・どこにあるファイルか」という紐付け情報を持たせます。
この構造により、申請様式そのものと、補足・参考資料を区別して管理できます。後述の「承認後の追記」（Q9）と組み合わせれば、概算時の資料・確定時の資料、というように承認の世代ごとに添付を分けて履歴管理することも可能です。容量・形式・最大件数の制限は要件定義で確定します。
システムが定期的に（例：1日1回）、「承認待ちのまま一定日数が経過したレコード」を自動で探し出します。この「一定日数」の閾値は、申請種別ごとにマスタで設定できます（急ぎの申請は短く、など）。
閾値を超えた申請が見つかると、今まさにボールを持っている承認者（現在のステップの担当ポストの人）へ自動で通知します。さらに停滞が続く場合は、上位者へエスカレーション通知することも設定可能です。人が目視で滞留を見張る必要がなくなります。
承認が完了しても、申請レコードは削除されず「承認済み」という状態でデータベースに残り続けます。データは消すのではなく、状態を遷移させていく考え方です。
検索は2種類の仕組みを併用します。①番号・申請者・日付・金額・種別といった構造化された項目への絞り込み検索。②本文や添付ファイル名に対する全文検索。②では、あらかじめ検索用の「索引（インデックス）」を作っておくため、申請件数が数万件規模に増えても高速に探し出せます。
多くのシステムは「承認＝完了・凍結」と捉え、承認後のデータを書き換えられません。御社の要件（概算→確定金額の反映、経理の支払日入力など）は、この「凍結」が壁になります。
そこで、承認済みレコードに対して「追記の種類によって処理を切り分ける」設計にします。
そして、AもBも「いつ・誰が・何を追記したか」をすべて監査ログに残します。これにより、後から追記しても「いつ時点で何が承認されていたか」をたどれる状態を保てます。