Alright, I've been poking around OpenPipe's docs and UI, and I see these three terms thrown around: triggers, actions, filters. The marketing copy makes them sound like distinct magical entities, but in practice, the lines seem... fuzzy. Or am I missing something?
Let's cut through the fluff. From what I can reverse-engineer, it looks like this:
A **trigger** is the event that kicks off a pipeline. It's the "when." Something happens—a new user signs up, a deal stage changes, a form is submitted. OpenPipe sees that event and starts the process. Simple enough, I suppose.
An **action** is the "what." It's the thing the pipeline actually *does* when triggered. Send an email, update a field in Salesforce, create a task in HubSpot. This is where the work gets done, presumably.
Now, the **filter** is where it gets interesting, and where most vendors get sloppy. A filter is the "if." It's a condition placed *between* the trigger and the action. So the event fires (trigger), but before it does the work (action), it checks a rule (filter). For example: Trigger is "deal stage changes to Closed-Won." Filter is "deal amount is greater than $10,000." Action is "send a congratulatory email to the account exec."
My immediate skepticism: isn't a filter just a conditional trigger? Or a gated action? The distinction feels semantic, but I'm betting the implementation details matter for debugging and, crucially, for pricing. If they charge per "action," but you have five filters before one action executes, does that count as one or five? I can't find a straight answer.
Can someone with actual logs or hands-on experience confirm this mental model? Better yet, show me a case where this taxonomy breaks down or leads to a real "gotcha" in the workflow.
Data skeptic, not a data cynic.
Ah, you got the gist of it, but your reverse-engineering missed the real-world mess where the lines bleed. The *theory* is clean: trigger (when), filter (if), action (do). The *practice* is where OpenPipe (and every tool like it) gets weird.
Your filter example is spot-on, but the sneaky bit is when a "filter" is actually another hidden trigger. For instance, a filter checking "deal amount > $10k" might need to *listen* for the amount field to change as its own micro-event, which blurs the line with a trigger. I've seen pipelines where the "filter" logic gets so complex it should have been its own pipeline, but hey, that's how vendor lock-in starts, isn't it?
The real kicker? Wait till you try to debug a pipeline where the action fails silently because a filter you thought was evaluating to 'true' was actually looking at a null value from a third-party API lag. Suddenly your clean distinctions don't matter - you're just knee-deep in logs. Fun times.
You've got the core separation spot on. That "when, if, what" framework is exactly how we try to present it to keep things clear.
Where folks often get tangled up is by packing too much logic into a single filter. A filter should be a simple gatekeeper, like your deal amount example. If you find yourself chaining multiple "and/or" conditions or, worse, trying to do data transformations there, that's a signal the logic belongs in a separate action or even its own pipeline.
Keeping that separation clean makes troubleshooting a breeze. When something breaks, you can quickly see if the trigger fired, which filter (if any) stopped it, or if the action itself failed.
— isabel
That troubleshooting tip about checking if the trigger fired, filter stopped it, or action failed is really helpful. So if something's broken, you'd just check the pipeline logs in that order?
It makes sense to keep filters simple as gatekeepers. I think my confusion came from seeing examples online where people *did* cram a bunch of logic into a single filter. Your point about that being a sign to make a new pipeline is a good rule of thumb. Is there a visual indicator in OpenPipe itself to warn you when a filter is getting too complex?
Checking logs in that order is the right move, but good luck if your trigger is polling an API with no webhooks. That "did it fire" question can become a week-long investigation.
>Is there a visual indicator...when a filter is getting too complex?
Ha. No. These platforms thrive on letting you build Rube Goldberg machines inside a single node. Complexity is a feature for the sales deck. If you want a warning, stick to a rule of thumb: if your filter logic needs its own unit tests, it's not a filter anymore.
SQL is enough
Exactly. The "did it fire" question with API polling is a special kind of hell. You're stuck checking timestamps in two systems and hoping your retry logic actually works.
Your rule of thumb on filters is the only warning you'll get. I'd add another: if you're using a filter to *modify* data before an action, you've already lost. That's what data transformation steps are for, when a platform actually provides them.
These tools sell on "clarity," but they make their money when you build something so intricate that unpicking it to switch vendors costs more than just staying put.