Workflow triggers feature

[paolodamico]

In a general sense, this feature refers to the functionality where you can trigger certain actions outside the PostHog environment when certain actions are triggered. It extends on our current messaging webhook & Zapier functionality. This also greatly builds on our plugins functionality. It could even be seen as the data-out part of the plugins functionality.

Context

Currently if you want to create workflows based on actions taken by a user, you would have to connect Zapier (n8n coming soon) and then create workflows in there based on actions triggered on PostHog. Some examples of such workflows include:

• Welcome email after a user signs up or becomes a paid customer.

• Link user information between platforms (e.g. create customer record on orbit.love or customer.io when a user signs up).

• Notifying customer support about a user action on Slack. An example from an actual user, they trigger a Slack message when a user requests an onboarding kit. The CX team then sends them their physical team and would love to be able to mark that request as processed.

• Sending unusual activity / fraud alerts.

• Goal: Strengthen our strategic position of a single platform to make products successful (removing the need of yet another product). Increase retention of teams by providing more value that could even be considered mission-critical.

• Assumptions: A few assumptions for this feature set,

  • We can cover 80% of use cases with basic trigger functionality. Or, there's a select few use cases that already provide a bunch of value.
  • The value of having this in a single platform outweights the cost of creating your own manual workflows (vs. integrating with something like Zapier that already includes a bunch of integrations out of the box).
  • Teams are using PH as their primary source of behavioral information. If you have a pipeline in the middle (like Rudderstack or Segment), it might not be as attractive.

• Success metrics: A few ideas on how to measure success for this,

  • Number of workflows created and active.
  • Number of teams with workflows.
  • Retention of teams with workflows vs. teams without workflows

In a general sense one key question that needs to be raised for a feature like this is whether it makes sense to build a version ourselves or to strengthen our integrations with other software that focuses on this.

Current numbers

• Currently from a sample of only cloud users, 1.6% of projects have enabled some sort of webhook.
• From the sample above, 6.5% of actions trigger a webhook.

Target user

One thing that it's particularly important to keep in mind is our target user. We're looking for the technical user, and particularly not the marketing or customer success team. The reason this is of particular importance is that for non-technical users, a key value of a feature like this comes from the built-in integrations, and it's definitely not our core to build the myriad integrations that dedicated tools that n8n or Zapier have.

Another important consideration is the question/assumption of whether technical users will have the use case for these integrations. A case could be made that these integrations are mostly targeted for business, CX, marketing, sales teams, ... which in turn require the out-of-the-box integrations previously mentioned.

Initial Ideas

• Most basic version is allowing to trigger vanilla HTTP requests after certain actions are triggered. We would need some basic data transformation too as no other service will have the same data structure as we do.
  • As we're creating this feature for technical users, we could even create something light on the UI side (maybe even code-based?)
• Allow scheduling / delaying actions in the workflow.
• Provide stats on number of triggers, historic triggers (for debugging), and a version control system for changes in workflow configuration.
• Allow creating a library of workflows, we could then have something similar as to what we have for plugins, in which community workflows can be created. For instance, if I create a workflow to create a customer record on Hubspot after a user sign up, I could share that workflow for anyone else to use them.
• Allow more complex decision functionality. This could be particularly served using a code editor, which would in turn allow for even more complex logic. Examples: if/then logic, wait for webhooks, parse other data formats (e.g. HTML, XML, CSV, ...), ...
• Track down success metrics for workflows. For instance, if I send an email, track down opening and clickthrough rate. If I send a churn prevention campaign, track down if users come back to the app.
• Feature flag (A/B test) flows. Allow to determine a FF state on the go to trigger different workflow steps for users.
• A radically different approach would be consider a tight integration with OSS that already does this. We could for instance allow a very easy installation of n8n in the same instance that gets already shipped fully linked to PostHog.

What others are doing

• This is in essence a more basic version of what Zapier (docs) and n8n (docs) do. Some key features worth mentioning: you can filter stuff on trigger actions and conditionally take different next steps depending on event props, you can make vanilla HTTP requests (e.g. to obtain/enrich your information, trigger some action on another system ...) at any time, you can manipulate the data at all times (e.g. if the service you're reaching uses a different currency format), you can add timing considerations (e.g. timeouts / cool downs / scheduling), automatic retries, and trigger history.

  

• Braze (relevant docs) (targeting mostly marketing campaigns) has a relevant event-triggering functionality where you can fire campaigns based on a schedule, after an action or after an API request.
  

• Mixpanel used to have a messages & experimentation feature now deprecated, which allowed sending emails, push notifications, ... to users, as well as A/B testing different variants and measuring relevant campaign results.

• Leanplum & Airship are more targeted downstream products for messaging & engaging customers. These mostly fall out of the scope of this feature, but added here to provide context on stuff that might be too specialized to support.

Wireframes

This time I decided to include some wireframes to spice up the discussion and get more ideas/feedback flowing.

Workflow list

Workflow details (UI-based)

Workflow details (code-based)

[Twixes]

This is a cool idea, but right now I'd just… tell a user to write their own plugin. Just the "Initial Ideas" looks like a TON of work. And the first and foremost "Most basic version" point is realized by plugins already.
I just don't really see how to fit this into the product right now. Think we should get other things (like actions, webhooks, plugins) right, both product and engineering-wise, before picking this thought up.

[paolodamico]

Re @Twixes. So as a quick preamble, I'm also leaning towards this might not be the best thing to work on right now, however I do think it's important to separate the feature discussion from a prioritization discussion. The goal of this issue is discussing potentially what the feature can do, not whether we should start building it right away (this release [#3287] I'm working on us running through a bunch of features to decide what to build next; from these discussions, we could use our new prioritization framework, to decide what to actually work on, and also depending on what stuff everyone wants to pick up).

A few additional comments,

• I don't think the basic version is covered by plugins just yet, one key distinction I think is worth considering is triggering a workflow from actions, not raw events.
• An interesting approach that could come up from this is maybe adding a few UI/UX elements, rewording stuff a bit, and basically using the same plugins engine but with a different branding.
• I also think this could potentially supersede and encompass webhooks.

[Twixes]

I think the biggest point here is making plugins fire on specific actions. That way we could make webhooks a plugin + do a lot of the stuff mentioned above. I'm not sure where to best handle that in the lifecycle of an event though. @mariusandra WDYT?

[mariusandra]

Cool feature, though I do agree with the sentiment that it's probably not the next thing we should work on. Mainly because there are some technical blockers that @Twixes touched upon (actions and webhooks into plugins).

Theoretically this "workflows" could even be implemented as a proper frontend plugin, but we don't have those yet either :).

[posthog-bot]

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.