Notion recently gave us the ability to call native automation from inside databases. However, the range of what we can do is extremely limited. What we need is the ability to perform more complex operations that make use of other properties and tables. What we need is a way to call external scripts that are directly tied to native notion automation.
The diagram below walks through one solution to this problem. It has the benefit of exposing the automation that we want to call directly inside of Notion automation. I’ll cover the steps in more detail below, then follow it up with a video demonstration.
Native Notion Automation (1&2)
Anywhere that I can create native automation, I have the ability to write to another table. I’m adding automation on a table called PM Default Tasks any time the Due Date changes. In response, I’m adding a page to the database PM Automation. The property Origin is my title, and I’m writing where the automation came from. The property Scenario is the script that I want to fire, and it comes from a related table I’ll cover below.
However, the fact that I’m using a relationship property means all of my scripts are available for selection inside of a dropdown where I define my native Notion automation.
Notify Slack (3)
The PM Automation table also has native Notion automation enabled. In this case, any time a new page is added, we are going to send a message to Slack. However, Notion imposes a roughly two-minute delay between the event and when the signal goes to Slack. It can be frustrating to wait sometimes, but we use this delay to our advantage below (steps 5&6).
You can use the free version of Slack because we don’t care about history here. I created a channel called #pm-dashboard that I write to. The only reason for notifying Slack is that there is a free add-on called “Outgoing WebHooks” that lets us trigger external code in response.
Slack Fires a WebHook to Our Automation Launcher (4)
In this case, Slack fires exactly one WebHook that will call our Automation Launcher scenario in Make.com. I wrote a separate article on How to Fire Webhooks from Notion that covers these steps in greater detail.
Launcher Determines What Automation to Run (5&6)
The Launcher scenario does a search on the PM Automation database, looking for any records with a status of “Request.” It pulls the requests off from oldest to newest, one at a time. The first thing it does after the router is remove any duplicate requests that may be sitting in the queue. Because of the two-minute delay before Slack notifications, duplicate requests should be eliminated before extra webhooks are even fired.
Launcher Fires The Desired Automation (7&8)
After the second router, we update the status of the current request in PM Automation database to “Processing,” then call the desired webhook to initiate the automation from step 1. This automation is expected to listen on its own webhook and to return a code 200 response, which looks like a standard webpage with bare text. If the called automation does not return a specific response, we’ll get “Accepted” as a default.
Save the Automation Response (9)
The final step of the Launcher automation is to take the webhook response from our target automation and push it back into the PM Automation database, along with updating the status of the request to “Done.”