ABEJA Tech Blog

中の人の興味のある情報を発信していきます

【実例付き】Notion好き必見!NotionのDatabase automationsで効率化できる9つのこと

はじめに

皆さん、お久しぶりです、ABEJAで細々とNotion普及活動をしている齋藤です。

こちらは ABEJAアドベントカレンダー2023 の 4日目の記事です。
他にも弊社メンバーが面白い記事をどんどん投稿予定なので、是非チェックしてみてください。

【実例付き】Notion好き必見!NotionのDatabase automationsで効率化できる9つのこと

目次

Notion Database automationsって何?

Notionは日々進化しており、つい最近「Notion AIによるQ&Aのbeta版」*1がリリースされています。
このNotionのQA機能はとても便利は、特にアプリ版にはなりますが、ドキュメントの検索にNotionAIを取り込んで検索できるショートカットキーが追加されていたりします。

閑話休題、話がそれてしまいましたのでもとに戻ると、今回はそんなNotionの更新の中で9月下旬にリリースされた 「Automate workflows」*2の中で実装されたDatabase automationsに関して色々ご紹介しようと思います。

※「Database automationsのことは知ってるから事例見せて」って方は、
こちら(事例紹介)まで読み飛ばしてください 🙇‍♂️

皆さんはNotionの 「Database automations」を活用できてていますでしょうか?
そもそもDatabase automationsとは、

(原文ママ)
Database automations are sequences of actions that happen any time a specific change to a database occurs. *3

そのまま日本語訳すると
「Database automationsとは、データベースに対する特定の変更が発生するたびに発生するアクションのシーケンスです。」
になります。

「Notionの最新の機能の紹介」ではありませんが、しれっと追加されたこのDatabase automationsですが、DatabaseのTemplateと実は相性がよく、かなり活用し易い機能です。
本日の記事では、このDatabase automationsで「どんな事ができるのか」を、「具体的な利用例」を交えてご共有します。

できること

Notion公式が公開しているこちらのYoutube(※全文英語ですが、翻訳字幕表示可能です)を見ると、Database automationsの機能の全容を把握することができます。


www.youtube.com

Database automationsでは
Databaseの変更の検知を司る「トリガー」と
トリガーを元に指定された機能を実行する「アクション」
という2つの構成要素があり、これらを組み合わせることによって様々なことを実現することができます。

Database automationsの設定

下記の設定で用いたDatabase情報はこちら(※クリックで開閉)

  • Database名
    • Sample 01
  • View
    • Table
      • DB作成時のデフォルトのtable view
    • sample01_list
      • list view
  • Template
    • なし
  • Properties
    • Title
      • (key) Title形式
    • Text
      • Text input
    • Number
      • Number input
    • Select
      • Select input
      • options
        • select01
        • select02
    • Multi-select
      • Multi-select input
      • options
        • m-select01
        • m-select02
        • m-select03
        • m-select04
    • Status
      • Status input
      • options (デフォルト)
        • To-do
          • Not started
        • In progress
          • In progress
        • Complete
          • Done
    • Date
      • Date input
    • Person
      • Person Select
    • Files & media
      • Files & media upload
    • Checkbox
      • Checkbox input
    • URL
      • URL input
    • Email
      • Email input
    • Phone
      • Phone Number input

対象DBのプロパティ一覧

対象選択

Database automationsでは、トリガーが発火する画面を指定することが可能です。

対象の選択画面

画像の Sample01はデータベース名で、これを選択すると、このSample01に含まれるすべてのViewでトリガーが適用されることになります。

Any page in this database
(訳)このdatabaseの任意(すべて)のページ

画像の Tablesample_01_listSample01 に含まれるViewで、このViewでトリガーが適用される形になります。

Any page in this view
(訳)このviewの任意(すべて)のページ

このように、あまり知られていませんが、View単位でトリガーの発火をコントロールできるので、例えば下記の場合

  • 会社全体のTask Databaseが存在
  • 各プロジェクトごとに表示されるようにフィルタリングされたViewが存在

『そのView上で新しいレコード(つまり新しいタスク)が追加されたときにトリガーが動くようにする』
といった処理を自動でさせることが可能になります。

トリガー

トリガー設定画面

トリガーは画像のように

  1. 対象に対するページ(レコード)が新規作成された時
    Page added
  2. 対象に対するページ(レコード)の任意のプロパティが更新された時
    Property edited

の大きく分けて2つの動作をしたときを指定することができます。
中でも、2. 対象に対するページ(レコード)の任意のプロパティが更新された時のトリガーは、更に細かくどんな状態になったのかを判定して発火するように指定できるものがあります。
下記にプロパティのタイプごとに設定可能な条件をまとめています。

項目 編集した時 任意の値になった時 メモ
Any property ⭕️ - 任意のpropertyが変更された時発火
Title ⭕️ -
Text ⭕️ -
Number ⭕️ -
Date ⭕️ -
Person ⭕️ -
Files & media ⭕️ -
URL ⭕️ -
Email ⭕️ -
Phone ⭕️ -
Select ⭕️ ⭕️ Any option 選択で変更時全て発火
Multi-select ⭕️ ⭕️ 同上
Status ⭕️ ⭕️ Any option 選択で変更時全て発火
大項目、小項目でそれぞれ発火判定が可能
Checkbox ⭕️ ⭕️ CheckedUncheckedを両方有効化することで変更時全て発火
Selectのトリガー編集画面
Multi-selectのトリガー編集画面
Statusのトリガー編集画面
Checkboxのトリガー編集画面

アクション

アクション設定画面

アクションは、画像のように「Edit property」「Add Page to...」「Edit pages in...」「Send Slack notification to...」が可能です。
この中で、別のDatabaseへの変更・追加を担うのが、「Add Page to...」「Edit pages in...」の2項目です。

Edit property - propertyの編集

トリガーが発火する要因になったページ(レコード)のpropertyを変更する機能です。
後の事例紹介でも紹介しますが、「グループを選択するとその該当メンバーがParsonタイプのpropertyに登録される」といったことを実現することができます。
別の視座に立つと、Templateでpropertyを設定するのと同じように、設定を追加したり変更したりすることができます。

Add Page to... - ページの追加

この設定では、任意のDatabaseにページを追加することができます。
まず初めにページ(レコード)を追加するDatabaseを選択し、その後追加するページ(レコード)のタイトルやpropertyを指定して追加することができます。
また、このAdd Page to...のときだけ、トリガーで検知したページ(レコード)自体をRelationのpropertyで設定できるため、「作成したページ(レコード)と紐づいた別DBのページ(レコード)」を簡単に作成することができます。

[ページ追加] 追加対象DB選択
[ページ追加] 追加情報入力

Edit pages in... - ページの編集

この設定では、任意のDatabaseの任意のページ(レコード)の情報を更新することができます。
Databaseの選択は「Add Page to... - ページの追加」と同様ですが、この設定では更にレコードを限定するため、フィルターを設定します。このフィルターは、Databaseのフィルターと全く同じように設定することができます。
フィルターを設定後、その対象のページ(レコード)のpropertyを任意の値に設定することができます。

[ページ編集] 編集対象DB選択
[ページ編集] 編集対象フィルタ&編集内容登録

Send Slack notification to... - Slackへの通知

この設定では、追加されたページ(レコード)や変更されたページ(レコード)の情報をSlackにて通知することができます。

[Slack通知] Slack連携画面
[Slack通知] Slack投稿設定画面

事例紹介

ここでは、前述したDatabase automationsの設定で実際にできる9つの事例をその設定方法とともにご紹介します。

紹介する事例の簡単な目次(※クリックで開閉)

  1. 自身の入力を補助する系
    1. TodoリストでFormulaプロパティを使わず進捗のバーを表示
    2. 議事録でチームを指定すると、該当メンバーを参加者に自動で登録
    3. プロジェクトを選択すると、関連するDBと自動で接続して各種データを取得
  2. Slackに通知する系
    1. TODOリストをSlackに通知
    2. 日報をSalckに通知
    3. 議事録をSlackに通知
  3. 他のNotionDBを操作する系
    1. プロジェクトDBを追加したら自動で、関連するDBにページを作成
    2. 計算用DBに自動反映
    3. (邪法)計算用DBに自動反映してランキング生成

自身の入力を補助する系

TodoリストでFormulaプロパティを使わず進捗のバーを表示

■ 利用シーン
Formulaの使い方が分からなかったり、そもそもFormulaを使いたくないときでも簡単に設定することができます

■ メリット

Formulaを使いたくない

  1. 単純にFormulaの使い方が分からなくても(非エンジニアでも)設定可能
  2. 既に複雑なFormulaがある場合でも問題なく設定可能*4
  3. Database automationはページのフルアクセス権がないと変更不可
    • むやみに変更されないという利点があります

■ 作成方法

  • データベース
    • property
      • ステータス: Status
      • 進捗: Number
      • any other
  • view
    • 指定なし(なんでもOK)
  • Template
    • ステータスNot Started
    • 進捗0
    • デフォルトに設定
  • automation 設定
    1. トリガーにステータスの変更を指定(例: In Progressに変更されたら)
    2. アクションに進捗の値を変更するように指定(値を20に変更)
    3. [1 ~ 2]を繰り返して、ステータスに対応する進捗の値をそれぞれ設定
    4. 完了

進捗バーのサンプル.png
進捗バーのサンプル


議事録でチームを指定すると、該当メンバーを参加者に自動で登録

■ 利用シーン
同じプロジェクトで同じ議事録のTemplateを使っているけれど、セールスチーム、開発チーム、保守運用チームなどチームごとに別れている場合に活用することができます。
所謂、プリセット化ができるものに関して、登録することで一括でデータの投入をすることが可能になります。

■ メリット
- 複数の類似するTemplateの作成の手間が不要

■ 作成方法

  • データベース
    • property
      • メンバー: メンバー
      • チーム: Select (Sales,Dev,Ops)
      • ステータス: Select (商談中,開発中,運用中)
      • any other
  • view
    • 指定なし(なんでもOK)
    • チームごとにビューを作ってautomation設定してもOK
  • Template
    • 指定なし(なんでもOK)
      • 既存の議事録Templateなど
  • automation 設定
    1. トリガーにチームの変更を指定(例: Devに変更されたら)
    2. アクションにメンバーの値を変更するように指定(例: 値をDEVのメンバーに変更)
    3. アクションにステータスの値を変更するように指定(例: 値を開発中に変更)
    4. [1 ~ 3]を繰り返して、ステータスに対応する各種値をそれぞれ設定
    5. 完了

議事録プリセット登録のサンプル.png
議事録プリセット登録のサンプル*5


プロジェクトを選択すると、関連するDBと自動で接続して各種データを取得

■ 利用シーン
上の「議事録でチームを指定すると、該当メンバーを参加者に自動で登録」の応用パターンで、ActionでRelationの変更を選択することで、そのRelationを参照しているLookUpも一緒に更新し、参照することができるようになります。

■ メリット

  1. 複数の類似するTemplateの作成の手間が不要
  2. 他のDBの情報の取得もプリセット化が可能

■ 作成方法
今回いい感じのDBが手元になかったので、私が個人的に運用しているプロセカNotionを利用してご紹介します。
楽曲名 = プロジェクト名
作曲者名 = クライアント名
リリース日 = 商談開始日
などのように置き換えて利用しています。

  • データベース
    • 議事録DB
      • property
        • プロジェクト名(※楽曲名): Select(千本桜,うっせぇわ,夜に駆ける)
        • クライアント名(※作曲者名): Lookup
        • 商談開始日(※リリース日): Lookup
        • プロジェクトDB_Relation(※楽曲DB_Relation): Relation
        • any other
    • プロジェクトDB(※楽曲DB)
      • property
        • クライアント名(※作曲者名): Text
        • 商談開始日(※リリース日): Date
        • any other
  • view
    • 指定なし(なんでもOK)
  • Template
    • 指定なし(なんでもOK)
  • automation 設定
    1. トリガーに楽曲名の変更を指定(例: 千本桜に変更されたら)
    2. アクションに楽曲DB_relationの値を変更するように指定(例: 千本桜に変更)
    3. [1 ~ 2]を繰り返して、各楽曲に対応する値をそれぞれ設定
    4. 完了

議事録プリセット登録-応用編-のサンプル.png
議事録プリセット登録-応用編-のサンプル


Slackに通知する系

TODOリストをSlackに通知

■ 利用シーン
自身の今作業しているタスクや、その日実施する予定のタスクなどを通知して、他のメンバーに共有するときなどに利用することができます。

■ メリット
リモートワークが拡大する中で、「誰がどのタスクをどこまで進めているのか」「誰がどのタスクで困っているのか」をキャッチアップしやすくなるという利点があります。
また、作成時にToriggerとなる部分を意識すると、色々な場面で利用することができます。

トリガーの例)

トリガー条件 通知内容
新規ページ作成時 新規タスク
Status: Backlogに変更 その日実施予定のタスク
Status: In progressに変更 作業中のタスク
Status: Reviewに変更 レビュー中のタスク
Status: Closeに変更 完了したタスク

■ 作成方法

  • データベース
    • Todo DB
      • property
        • Status: Status(new Issue,Backlog,In progress,Review,Close)
        • Project: Select(Project01,Project02)
        • any other
  • view
    • Project01_view
      • Project01でフィルタリングしたView
    • Project02_view
      • Project02でフィルタリングしたView
  • Template
    • Template01
      • Statusをnew Issueに設定
      • ProjectをProject01に設定
      • Project01_viewのデフォルトに設定
    • Template02
      • Statusをnew Issueに設定
      • ProjectをProject02に設定
      • Project02_viewのデフォルトに設定
  • automation 設定
    1. 対象をProject01_viewに設定
      1. 上記のトリガーの例に当てはまるようにトリガーを設定(※サンプルでは新規タスク作成時)
      2. アクションからSlackに通知を選択(※該当ProjectのSlackチャンネルを選択)
    2. 対象をProject02_viewに設定
      1. 上記のトリガーの例に当てはまるようにトリガーを設定(※サンプルではタスク完了時)
      2. アクションからSlackに通知を選択(※該当ProjectのSlackチャンネルを選択)

TODOリストをSlackに通知のサンプル.png
TODOリストをSlackに通知のサンプル


日報をSalckに通知

■ 利用シーン
上記のTodoリストの日報バージョン(※上記と類似しているのでかなり端折ります)
業務の終わりに作成した日報をSlackに通知する事ができる。

■ メリット
書いた日報を他のメンバーに簡単に共有でき、進捗の共有やコミュニケーションの活発化に寄与することができる。

■ 作成方法

  • データベース
    • 日報DB
  • view
    • 指定なし(なんでもOK)
  • Template
    • 指定なし(なんでもOK)
  • automation 設定
    1. トリガーに Page added ...を指定
    2. アクションにSlackに通知を選択(※該当のチャンネルを選択)

日報をSalckに通知.png
日報をSalckに通知のサンプル


議事録をSlackに通知

■ 利用シーン
前述しているTodoリストや日報と同様に、議事録も事前通知することができます。
また、Propertyに参加者を追加し、参加者の変更をトリガーにすることで、会議終了後に参加者を記録するようにすると、会議終了後に会議の議事録が任意のSlackチャンネルに通知されるようにすることが可能です。

■ メリット

  • 議事録作成時に通知する場合
    • 議事録にアジェンダを含めておくと、事前にアジェンダを共有することになるため、会議自体を円滑に進めることが可能
  • 会議終了後に通知する場合
    • 会議に参加できなかったメンバーにも確実に議事録を共有可能

他のNotionDBを操作する系

プロジェクトDBを追加したら自動で、関連するDBにページを作成

■ 利用シーン
例) プロジェクトDBに該当プロジェクトを作成すると、工数管理DBに該当プロジェクトのページ(レコード)が自動生成されます。

■ メリット

  • 作るべきページ(レコード)を作り忘れるということを予防可能
  • リレーションでDB同士が繋がる場合、どうしても両方のレコードが生成されたあとにリレーションのプロパティを設定する必要があるが、automationの場合、ページ生成時に This page という操作されたページをリレーションに含めることが可能
    • 双方向リレーションを設定していれば、自動で双方向のリレーションを張ることができます

■ 作成方法

  • データベース
    • プロジェクトDB
      • property
        • 工数管理_relation: Relation(双方向)
        • any other
    • 工数管理DB
      • property
        • プロジェクト_relation: Relation(双方向)
        • any other
  • automation 設定
    1. プロジェクトDBからPage Addedトリガーを設定
    2. ActionでAdd page to ...工数管理DBを選択
    3. Edit another propertyプロジェクト_relation を選択し、This pageに設定

自動で関連DBにページ生成のサンプル.png
自動で関連DBにページ生成のサンプル


計算用DBに自動反映

■ 利用シーン
基本的な情報を表示する用のDBと、計算用のDBに分けている場合*6、用意に計算用のDBに対してページ(レコード)を生成してFormulaにて計算を実施。その後計算結果を表示する用のDBからLookupで取得することができます。

■ メリット
Formulaで長大な計算処理を実施する場合、かなり処理時間に時間がかかってしまったり、APIでデータを上手く吸い出せなくなってしまったりするので、計算のためだけのDBに分けることで、ストレスなく複雑な計算処理の結果だけを取得することが可能になります。
この時、計算用のDBにもページ(レコード)を作成する処理をDatabase automationsに任せることが可能であり、コレは「重い処理をしているDBの手動でのページ(レコード)作成が不要になる」ということと同義になります。

■ 作成方法

  1. 表示用DBからPage Addedトリガーを設定
  2. ActionでAdd page to ...計算用DBを選択
  3. Edit another propertyプロジェクト_relation を選択し、This pageに設定

■ 動作のフロー*7

計算用DBに自動反映の動作フロー.png
計算用DBに自動反映の動作フロー

  1. データの入力
    1. 計算用DB表示用DB関連するDBへのリレーションを張っているため、LookUpで計算に必要な情報を取得
    2. 複雑な計算を実施
  2. 表示用DBから参照
    1. 表示用DBから計算用DBへのリレーションを元に計算結果をLookUpで取得

(邪法)計算用DBに自動反映してランキング生成

こちらの使い方ですが、Notionが独自にTableViewやListViewにてソートしたものの順にランキングを振る機能がついたらお役御免になる機能であり、実装するに当たってかなり複雑なDB構成及びFormulaを利用していますので、参考程度していただくのが良いかと思います。
※ THE 力技です

■ 利用シーン

ランキング結果利用例*8

画像のように数値を持っているページ(レコード)に対して、そのDBの中でその数値は何位なのかを表示したい場合に利用

■ メリット
他の事例と同じですが、複雑な処理をしたり、直接参照しないようなDBは基本的にページ(レコード)を追加し忘れてしまったり、そもそも表示や追加をマニュアルで実施しようとすると処理が重くて時間がかかってしまったりするという大きのデメリットがあります。
Database automationsを利用することで、これらの複雑なDBへの追加処理が容易になるというのは非常に大きなメリットになります。

■ 作成方法
こちらの作成方法ですが、節題の通り邪法ですので、どんなフローでこの計算がされているのかを中心にご紹介します。

表示 説明
(手動) 手動で操作する部分
(自動) Database automationsにて操作される処理
(計算) Formulaにて操作される処理
  1. 各種DB作成 & リストへのデータ追加
    1. (手動)表示用DB作成
    2. (自動)数値入力DBに該当のページ作成
    3. (自動)計算用DBに該当のページ作成
    4. (自動)数値配列DBのレコードのリレーションに該当ページを紐づけ
  2. (手動)値の入力
  3. (計算)計算用DBが数値配列DBを用いて、配列計算を実施し、順位の数値を出力
  4. (計算)Lookupにて順位の数値を取得し、取得した値に「位」をつけて出力

邪法のFormula設定 (注: めちゃめちゃ長いですのでご注意ください)(※クリックで開閉)

  • データベース
    • 表示用DB
      • property
        • relation_計算: Relation
        • 順位: Lookup
    • 数値入力DB
      • property
        • relation_計算: Relation
        • relation_数値配列: Relation
        • value: Number
    • 計算用DB
      • property
        • relation_表示: Relation
        • relation_数値配列: Relation
        • calc_number: Formula
        • result: Formula: Text
    • 数値配列DB
      • property
        • list: Lookup → Number
        • relations: Relation

■ calc_number のFormula

lets(
    pointDbList, first(prop("relation_数値配列").map(current.prop("list"))),
    thisNum, first(prop("数値入力DB").map(current.prop("value"))),
    ranking, filter(pointDbList,current >= thisNum),
    rankingLength, ranking.length(), 
    ifs(
        rankingLength == 0, "", 
        max(pointDbList) == min(ranking), 1, 
        rankingLength
    )
)

// Typescriptで書き換え
// 入力されたすべての値が格納されている数値配列
const pointDbList: Number[] = relation_数値配列.list

// 現在の数値
const thisNum: Number = 数値入力DB.value

// pointDbListの中で、thisNum以上の数値を持つ数値配列
const ranking: Number[] = pointDbList.filter((e) => e >= thisNum))
const rankingLength: Number = ranking.length

if (rankingLength == 0) return null // 数値が入力されいない時
if (Math.max(pointDbList) == Math.min(ranking)) // ランキングが1位の時
return rankingLength // それ以外

■ result のFormula

let(
    num,toNumber(prop("calc_number")),
    if(
        not(num > 0),
        "",
        num + " 位"
    )
)

// Typescriptで書き換え
const num = Number(calc_number)
return num <= 0 ? "": `${num} 位`

■ 動作のフロー

ランキング自動生成フロー.png
ランキング自動生成フロー

さいごに

今後のDatabase automationsに期待すること

現状、Database automationsでは実は絶妙に手が届いていないところや、実現してほしい部分があります。

  1. Edit pages in...にて別ページを指定する際に、トリガーとして変更したページのpropertyを利用
    • これができるようになると、次のようなことを実現することができる
      • チームのTaskDBと個人のTaskDBがあるときに、個人のTaskDBを更新するとチームのタスクDBの該当のページ(レコード)を更新
      • 工数管理DBが更新されると、更新された対象ProjectDBページ(レコード)の更新
      • etc...
  2. アクションでAPIの実行
    • コレができるようになると、独自システムとの連携やSlack通知を更にリッチにしたり、GASとの連携を行い、ほぼリアルタイムで計算自体をGoogleSpreadSheetに任せてNotionは表示する数値だけ取得するといった事が可能になり、実質できないことがほぼなくなると言っても過言ではなくなります

これらの変更がされるかどうかは不明ですが、もし実現されたら、今回はたった9つの事例だけでしたが、10や20では効かない数の利用方法が考えられるようになります。(最高ですね)

最後に一言

今回もとても長い記事になってしまいましたが、Database automationsの利用実例を元に
「こんな感じのことできないかな?」「こんな使い方できそう」
といったアイディアの種を感じ取っていただければ幸いです。

We Are Hiring!

ABEJAは、テクノロジーの社会実装に取り組んでいます。
技術はもちろん、技術をどのようにして社会やビジネスに組み込んでいくかを考えるのが好きな方は、下記採用ページからエントリーください!
(新卒の方のエントリーもお待ちしております)

careers.abejainc.com

*1:[2023/11/14]Notion 2.35: Introducing Q&A by Notion AI (now in beta)

*2:Notion 2.33: Automate workflows

*3:Database automations - Notion Help centerより抜粋

*4:Formulaプロパティはとても便利ですが、プロパティ内に複数のFormulaがすでにある場合や、長大な計算をするFormulaがある場合は表示が遅くなったりAPIでデータを取得するのに時間がかかるようになったりしてしまうため、注意が必要です。

*5:共同編集するような人がいなかったので、サンプル画像では、私が個人的に運用しているプロセカNotionからVirtualSingerの方々に来てもらいました

*6:計算処理は処理時間が長いので、別のDBにしてRelationを張ってLookUpで参照するほうがスムーズに閲覧できるという裏技があります

*7:設定方法がここらへんから複雑すぎるので、動作のフローだけ記載します

*8:私が個人的に運用している音ゲー情報まとめサイト「プロセカNotion」から、マスター譜面のコンボ数ランキングとそのランキング順位計算結果を表示