Introducing NotionApps Workflow Foundation

We are building something new for the NotionApps community: NotionApps Workflow Foundation.

Workflow Foundation is a new workflow engine designed to help builders turn their apps into richer, more responsive business tools.

Status: This feature is still under active development.
We are sharing it early because workflow tools are only useful when they match the real way people work. Your feedback will help shape how Workflow Foundation grows.


Why We Are Building It

NotionApps builders already create useful portals, forms, directories, trackers, internal tools, and lightweight business applications.

But many real workflows need more than collecting and displaying data.

They need things like:

  • Notifying the right person when something needs attention.
  • Updating records after a user takes action.
  • Opening the right screen after a form or button event.
  • Showing or hiding controls based on the situation.
  • Waiting for a deadline before escalating work.
  • Giving builders clear visibility into what happened and why.

Workflow Foundation is our first major step toward making that kind of automation native inside NotionApps.


What We Are Exploring

The current direction gives builders a way to create workflows from inside the app builder, attach them to app events, configure steps visually, publish them, and monitor what happens after they run.

Early workflow capabilities include:

  • App-aware triggers for form submissions, button actions, record events, scheduled events, and webhooks.
  • Context-aware pickers so builders can choose screens, controls, data sources, and fields by friendly names instead of hunting for hidden IDs.
  • Record actions for creating and updating Notion-backed data.
  • Notifications through email and webhook steps.
  • Live screen actions such as opening a screen, showing a message, refreshing data, or showing and hiding controls.
  • Conditions that evaluate submitted data or earlier workflow output.
  • Wait steps that pause work, save workflow state, and resume later.
  • Timer escalation so overdue work can follow a different path.
  • Builder activity tools so app owners can see workflow status, inspect runs, retry failures, cancel active work, and resume waiting runs.

The goal is not to force builders into complicated automation logic.

The goal is to make common workflows approachable, while still leaving room for advanced builders to extend what is possible.


A Practical Example

Imagine a client intake app.

When a client submits the intake form, Workflow Foundation could:

  1. Show the client a confirmation message.
  2. Create a follow-up task for the internal team.
  3. Notify the reviewer by email.
  4. Wait 24 hours.
  5. Escalate the task if no one has handled it.

Or imagine a request review app.

When a manager clicks Approve, the workflow could:

  1. Update the request status.
  2. Refresh the request list.
  3. Open a review detail screen.
  4. Show or hide controls based on what should happen next.

These are the kinds of app-level workflows we want to make easier to build without leaving NotionApps.


Builder Control Matters

One important design principle is that builders should be able to control their own workflows.

The builder experience is being designed so app owners can:

  • Create workflows.
  • Attach workflows to app screens, buttons, forms, records, and data sources.
  • Configure steps with guided fields.
  • Publish, pause, resume, disable, and delete workflows.
  • View workflow status.
  • Inspect individual workflow runs.
  • Retry failed runs.
  • Cancel active or waiting work.
  • Resume waiting workflows when work is ready to continue.

There will also be an admin operations view, but that is intended for global support and intervention.

Builders should not need admin access to understand or manage their own workflows.


We Want Your Feedback

This is where the community can help shape the feature.

We especially want to hear:

  • What workflows do you wish your NotionApps apps could run today?
  • Which triggers matter most to you: form submissions, button clicks, record updates, schedules, webhooks, or something else?
  • What actions would make the biggest difference: notifications, record updates, screen changes, approvals, assignments, comments, external integrations, or escalations?
  • Where do workflow tools usually become too complicated for you?
  • What would make this feel easy enough for non-technical builders?
  • What should advanced users be able to customize?
  • What status, logging, or troubleshooting details would you need to trust a workflow in production?
  • Which integrations should come after email and webhook support?

We are particularly interested in real examples.

Even a rough description like this would be incredibly helpful:

“When this form is submitted, I need this person to review it, then this screen should open depending on the answer.”


A Note on Development

Workflow Foundation is still in progress.

Some capabilities may change as we test the builder experience, refine the workflow engine, and learn from feedback.

Our focus right now is to get the foundation right:

  • Make workflow creation understandable.
  • Avoid requiring builders to type hidden IDs or large JSON blocks.
  • Give builders useful visibility into workflow status.
  • Support dependable execution, retries, waiting, and escalation.
  • Keep advanced extension possible without making the everyday experience feel technical.

Help Us Shape It

If you build with NotionApps, we would love your input.

Tell us what you want to automate.

Tell us what feels confusing.

Tell us what would make Workflow Foundation valuable enough to use every day.

This is a chance to help shape a major new layer of NotionApps before it is finalized, and we want it to reflect the workflows our community actually needs.

Thank you for building with us.

1 Like