【Notion】Notionで申請ステータスを自動で管理したい時のプロパティ設計

Notionを申請管理に活用しているものの、ステータスを手動で更新する手間やミスに悩んでいる方は少なくありません。特に複数の承認者が関わる申請では、誰がどの段階かを一目で把握できる自動化が欠かせません。しかし、プロパティ設計を誤ると、かえって管理が煩雑になり、自動化が機能しなくなります。本記事では、申請ステータスを自動管理するためのプロパティ設計の考え方と具体的な構築手順を解説します。会社でNotionを運用中の方、これから導入を検討されている方は参考にしてください。

なぜ申請ステータスの自動管理が必要か

Notionでの申請管理には、休暇申請、経費申請、書類承認など様々なワークフローがあります。これらのステータスを手動で更新していると、更新忘れや誤った値の入力が発生し、承認プロセスが滞る原因になります。自動管理を導入すれば、申請者がフォームを送信した時点で「申請中」、承認者が確認したら「承認済み」といった状態遷移を自動化でき、リアルタイムな状況把握が可能になります。また、複数の申請を一覧で見る際にフィルタやソートが効率的になり、チーム全体の生産性向上につながります。

プロパティ設計の基本:押さえておくべき5つの要素

自動管理を実現するには、適切なプロパティの種類と構造を選ぶことが重要です。以下の5つの要素を基準に設計してください。

1. ステータスプロパティ

Notionには「Status」プロパティと「Select」プロパティの2種類があります。Statusは自動的に色分けされて見やすい反面、カスタマイズの自由度が低い場合があります。Selectは完全に自由に選択肢を設定でき、数値や式との連携も容易です。自動管理に適しているのは、後述するオートメーションと相性の良いStatusプロパティです。ただし、ステータス名称を独自に変更したい場合はSelectを使う必要があります。

2. 日付プロパティ

申請日、承認期限、完了日などを記録するために必須です。自動管理では、日付をトリガーにしてステータスを変更したり、期限切れを警告するために使います。「Created time」プロパティで自動記録する方法も検討してください。

3. 担当者プロパティ

申請者と承認者を明確にするために「Person」プロパティを使います。複数の承認者がいる場合は、関連データベースで管理するか、テキストプロパティでまとめて記入する方法があります。自動管理では、特定の人物が変更されたときにトリガーを設定できます。

4. 関連データベース(Relation / Rollup)

申請テーブルと承認テーブルを分ける場合、Relationで紐付け、Rollupで承認状況を集約します。複雑なワークフローではこの設計が不可欠です。

5. Formulaプロパティ

条件に応じてステータスを自動計算する場合に使います。例えば、すべての承認者のステータスが「承認済み」なら「全体ステータス」を「承認済み」に変更する、といった判定が可能です。

自動管理を実現する2つの方法

Notionでステータスを自動更新する方法は、大きく分けて「データベースオートメーション」と「ボタン+フォーミュラ」の2つです。それぞれの特徴と手順を解説します。

方法1:データベースオートメーションを使う

ワークスペースのプランがEnterpriseまたはプラス以上で利用可能な機能です(無料プランでは使用不可)。以下の手順で設定します。

1. 申請データベースを開き、右上の「…」メニューから「データベースオートメーション」を選択します。
2. 「+ オートメーションを追加」をクリックし、トリガー条件を設定します。例:「ステータスが申請中に変更されたとき」を選択。
3. アクションを追加します。例:「担当者(承認者)に通知を送信」「日付を今日の日付に設定」など。
4. 必要に応じて複数のトリガーとアクションを組み合わせます。例えば、承認者フィールドが変更されたら「承認済み」に更新するルールも設定可能です。
5. 設定後、実際の申請をテストして動作を確認します。

方法2:ボタン+フォーミュラによる手動トリガー補助

データベースオートメーションが使えない環境でも、ボタンプロパティとフォーミュラを組み合わせて疑似的な自動化が可能です。例えば、「承認済みにする」ボタンを押すと、ステータスを変更し同時に日付を記録するような動作を作れます。ただし、完全な自動化ではないため、手動操作が残る点を考慮してください。

具体的なプロパティ設計例:休暇申請のケース

実際に休暇申請を例に、プロパティ設計と自動化の流れを説明します。以下の表は、単一テーブル方式と関連テーブル方式の比較です。

設計方式	メリット	デメリット	おすすめシーン
単一テーブル(申請項目をすべて1テーブルに)	シンプルで管理が容易、オートメーション設定が少ない	承認者が複数いる場合にプロパティが増える、履歴管理が難しい	承認者が1人だけのシンプルな申請
関連テーブル(申請テーブル+承認テーブルを別に)	複数承認者でも柔軟、承認履歴を残せる、再利用性が高い	設定が複雑、RelationやRollupの理解が必要	チーム全体で申請ワークフローを標準化したい場合

休暇申請の単一テーブル方式では、以下のプロパティを設定します。

• 申請者(Person)
• 休暇種類(Select:年休、病欠、特別休暇など)
• 開始日・終了日(Date)
• 承認者(Person)
• ステータス(Status:申請中、承認者確認中、承認済み、却下)
• 備考(Text)

オートメーションの例:申請者がフォームからデータベースに追加した時点でステータスを「申請中」に設定。承認者フィールドが変更されたら「承認者確認中」に自動変更。承認者が自身の担当フィールドを更新したら「承認済み」に変更する、など。

失敗パターンとその対策

自動管理を導入する際によく発生する失敗を3つ紹介します。

失敗1:プロパティの種類を誤る

例えば、ステータスをTextプロパティで管理すると、オートメーションで更新できません。必ずStatusまたはSelectプロパティを使用してください。また、日付を手入力するとタイムゾーンの問題が起きるため、DateプロパティまたはCreated timeを利用しましょう。

失敗2:関連データベースの循環参照

申請テーブルと承認テーブルをRelationで結ぶ際、お互いに参照し合うと循環参照が発生し、Rollupがエラーになります。設計時には必ず一方向の関係にし、承認テーブルから申請テーブルを参照するようにしてください。

失敗3:オートメーションのトリガー条件が不適切

「ステータスが変更されたとき」だけをトリガーにすると、本来変更したくない場面でも動作してしまいます。例えば、申請者が誤ってステータスを変更した場合も自動処理が走るため、変更元・変更先の条件を細かく設定する必要があります。データベースオートメーションでは、トリガーに「ステータスがXからYに変わったとき」と指定できるため、具体的な遷移を明示しましょう。

テナント管理者に確認すべきこと

会社のNotion環境では、以下の点を事前に管理者に確認してください。

• データベースオートメーション機能が有効かどうか(プランによる制限)
• テンプレートの利用ポリシー(テンプレートからのデータベース作成が許可されているか)
• API連携の可否(外部ツールと連携して自動化する場合)
• 共有設定(ゲストのアクセス権限など)

管理者が機能制限をかけている場合、自由に設定できないことがあります。その際は代替案として書式やフォーミュラを使った簡易自動化を提案しましょう。

よくある質問(FAQ)

• Q1. 無料プランでも自動管理は可能ですか? データベースオートメーションは有料プラン限定です。無料プランでは、ボタンとフォーミュラを組み合わせた手動補助的な自動化しかできません。
• Q2. ステータスが更新されない原因は? プロパティの種類がTextになっている、オートメーションのトリガー条件が合っていない、または権限が不足している可能性があります。まずは手動で更新して動作を確認してください。
• Q3. 複数の承認者を設定したい場合の最適な設計は? 関連テーブル方式をおすすめします。申請テーブルに承認者プロパティを設定するのではなく、承認テーブルを作成し、Relationで紐付けます。そうすることで、各承認者のステータスを個別に管理できます。
• Q4. オートメーションで通知を送る方法は? データベースオートメーションのアクションに「メンバーに通知」が用意されています。指定したPersonプロパティに通知が送られます。ただし、メール通知はNotionの設定次第です。

まとめ

Notionで申請ステータスを自動管理するには、プロパティ設計が最も重要です。Statusプロパティとデータベースオートメーションを組み合わせることで、手動更新の手間を大幅に削減できます。ただし、会社のプランやポリシーによって使える機能が異なるため、管理者への確認は欠かせません。設計段階で失敗パターンを把握し、適切なテーブル構造を選ぶことで、チームの申請業務を効率化できるでしょう。ぜひ本記事を参考に、あなたのワークフローに最適な自動化を構築してください。

🧩

Notionトラブル完全解決データベース 共有、権限、データベース、Notion AI、インポートで止まる問題を横断的に確認できます。