無料で始めるワークフローシステム
稟議・申請の承認をOSSで

1. 稟議書や申請書を紙で回していて、承認の印をもらうために社内を回っている
2. Excelの申請書をメールで送って承認を頼んでいるので、どれが最新でいま誰が持っているのか分からない
3. 申請の金額によって承認する人が変わり、ルートを間違えて差し戻しになる
4. 誰がいつ承認したのか、後から確かめる記録が残っていない
5. 承認待ちのまま止まっている申請に、誰も気づかない
6. ワークフローの製品は利用者の人数ごとの料金で、全社員に広げると費用がかさむ
7. 申請の項目や承認の段階を変えたいが、そのたびに開発会社に頼んでいる

この設定は、マニュアルのFAQ：稟議申請などのワークフロー（承認プロセス）をプロセス機能で実現するで、項目の作り方から順に説明しています。デモ環境の「稟議申請の例」のフォルダで、実際の設定と動きを試せます。

［承認］ボタンを押したときに、データの変更で、押した人の名前と押した日時を、その段階の「承認者」「承認日」の項目に自動で入れられます。申請番号も、［申請］ボタンを押したときに「20261002-0001」のような書式で自動で採番できます。

レコードを更新するたびに変更履歴が残り、誰がいつ何を変えたかを後から追跡できます。決裁のあとは状況による制御で申請の内容を読取専用にし、完了したらレコード全体を読取専用にすれば、承認した内容が画面から書き換えられることを防げます。

ただし、次の点は運用で決めておきます。

1. 変更履歴の復元・削除は、テーブルの履歴の設定で許可したときだけ使えます。削除にはサイトの管理権限が要ります
2. 状況による制御の読取専用は、インポート・一括更新・APIでの更新では効きません。これらを使える人を権限で絞ります

内部統制や監査に使える承認の記録を残す仕組みを作ることはできますが、プリザンターは法令や規格への適合を保証する製品ではありません。東洋アルミニウムでは、承認者を上長だけに設定することで、インシデント対応の承認の証跡をIT統制の観点で担保しています。

例1：決裁が済んだ申請を、ほかのシステムで受け取る（API）

会計システムへの連携の仕組みから、複数レコード取得APIを呼んで、ステータスが「完了」（コード900）の申請だけを取り出す例です。APIキーは事前に作成しておきます。取り出したデータを会計システムに登録する部分は、相手のシステムの仕様に合わせて作ります。

curl -X POST "http://{サーバ名}/api/items/{サイトID}/get" \
  -H "Content-Type: application/json" \
  -d '{
    "ApiVersion": 1.1,
    "ApiKey": "{APIキー}",
    "View": {
      "ColumnFilterHash": { "Status": "[\"900\"]" }
    }
  }'

マニュアル：複数レコード取得API／APIキー

例2：申請者の部署から、承認者を自動で入れる（サーバスクリプト）

申請者が所属する部署の課長を、承認者の項目に自動で入れる例です。課長のユーザをグループ（ここではグループID 3）にまとめておき、そのメンバーの中から、申請者と同じ組織の人を選びます。条件は「レコード読み込み時」にします。組織図の変更に合わせてグループのメンバーを直せば、スクリプトを書き換えずに済みます。

// 申請者と同じ組織にいる課長を、承認者（ClassB）に入れる
const managerGroupId = 3; // 課長のグループ
for (const member of groups.Get(managerGroupId).GetMembers()) {
    if (member.UserId > 0) {
        const user = users.Get(member.UserId);
        if (user.DeptId === context.DeptId) {
            model.ClassB = user.UserId;
            break;
        }
    }
}

金額に応じて部長・役員まで承認ルートを組み立て、承認のたびに次の承認者へ回す一式は、FAQ：稟議申請などのワークフローをサーバスクリプトで実現するにあり、サイトパッケージで取り込んで試せます。

マニュアル：groups.Get／GetMembers／users.Get／実行条件

1. 日本国内で開発されているオープンソース。Community Editionは、利用者の人数や期間の制限なく無料で使え、商用利用もできます。申請する人が全社員でも、人数を気にせず広げられます
2. 自社のサーバー（オンプレミス）や、自社で管理するAWS・Azureなどに構築できます。申請の内容を社外のクラウドに出したくない場合にも使えます
3. WindowsとLinuxのどちらでも動き、実行環境は.NET 10、データベースはPostgreSQL・SQL Server・MySQLから選べます。Dockerのコンテナでも動かせます
4. 検証の環境で作った申請のテーブルは、サイトパッケージで本番の環境に移せます

オンプレミスで使えるノーコード・Webデータベース
FAQ：動作環境や推奨スペック

価格・動作環境・セキュリティの機能を含めた基本的な事実は、プリザンターの基本情報に、出典のページと合わせて載せています。

1. 01

   サーバーを準備する

   事前準備として、.NETとデータベース（SQL Server・PostgreSQL・MySQLのいずれか）をインストールします（FAQ：動作環境や推奨スペック）

2. 02

   インストーラで入れる

   インストーラを起動し、表示される指示に沿ってインストール先やデータベースの接続先を入力します。プリザンターの最新のバージョンは、インストーラが自動でダウンロードします。手順はWindows・Linux・Azure App Serviceの別にあります（マニュアル：インストーラでのインストール）

3. 03

   申請の画面を作る

   ブラウザでログインし、標準のテンプレート「稟議申請」などから申請のテーブルを作ります。プロセスで［申請］［承認］［差戻］のボタンを足し、通知を設定します（マニュアル：ワークフローをプロセス機能で実現する）

インターネットにつながないサーバーには、ダウンロードセンターから取得したファイルを置いてインストールできます。Dockerのコンテナでも動かせます。

ほかの始め方

1. サーバーを用意する前に操作を確かめる：60日間無料のデモ環境。メールアドレスの登録だけで始められます
2. サーバーを持たずに使う：クラウドサービスのPleasanter.net。3ユーザーまで無料です（プリザンターのはじめ方）
3. Enterprise Editionを試す：自社に構築したCommunity Editionの環境で、90日間の無料トライアルを使えます

1. 申請書を決まった書式のPDFの帳票で出力したい：標準の機能にはありません。認定パートナーの帳票出力のソリューションと組み合わせます
2. 電子署名や電子契約まで一つの製品で完結させたい：標準の機能にはありません
3. 代理承認・後閲・組織図からの承認者の自動の割り当てなどを、設定だけですぐに使いたい：承認者の自動の割り当てはサーバスクリプトで作ります（例2）。ワークフロー専用の製品が持つ細かな決まりは、自社で作り込みます
4. サーバーを運用する体制がない：オンプレミスでは、構築・バックアップ・バージョンアップを自社で行います。認定パートナーに任せることもできます