Alright, so I tried to wire up a Lindy to nudge our sales team when a deal goes stale. You know, the classic "deal in 'Negotiation' for 10 days? Ping the channel." Sounded simple. The Lindy docs make it look like a three-click process... and it mostly is, until you hit the real-world edge cases. 😅
Here's the step-by-step that actually worked, after I stopped believing the happy-path tutorial. The goal: when a deal in our CRM (we use HubSpot) hits the "Contract Sent" stage, wait 48 business hours, then check if it's moved. If not, send a Slack message to the sales ops channel with the deal details.
First, the trigger. This is straightforward in Lindy. You pick your CRM app, select "Deal Stage Updated," and set the filter. The gotcha? The trigger fires on *every* stage update. So you **must** add a filter right there in the trigger setup:
```yaml
# In the Lindy trigger configuration UI, you'd set a filter like:
deal_stage: "contract_sent"
```
Without that, your lindy goes bananas on every single deal change. Found that out the hard way. My Slack channel got 50 messages in 2 minutes. Not my finest ops moment.
Then, the "wait 48 business hours" part. Lindy's "Delay" action has a "business hours" option, which is slick. But "business hours" are defined in the Lindy's settings, not the action. So you have to configure your Lindy's working hours *before* this works. Missed that, and we got a 48-hour *real-time* delay over a weekend. Sales was... not thrilled.
The final logic bit is the conditional check. After the delay, you need to fetch the *current* deal stage from the CRM again and compare it. The action flow looks like:
1. **Trigger:** Deal enters "Contract Sent".
2. **Delay:** 48 business hours.
3. **Action:** CRM "Get Deal" (using the Deal ID from the trigger).
4. **Conditional:** `{{if actions['Get_Deal'].deal_stage != 'contract_sent'}}` → Stop.
5. **Action:** Slack "Send Message".
The brutal honesty? This is where low-code tools like Lindy both shine and trip. It's *way* faster than writing a Lambda, setting up EventBridge, etc. But debugging that conditional logic when the deal stage is a nested object (looking at you, Salesforce) can make you want to curl up with a raw Terraform module instead. The visual workflow helps, but you have to be meticulous with your data paths.
Overall, it's running now. Saves the sales ops manager a daily manual report. Just test your edge cases in a sandbox channel first, unless you enjoy being the star of the #ops-bloopers channel.
- tm
Oh, the trigger filter pain is real. I've built similar alerting logic in Grafana with Prometheus, where you *absolutely* need that initial filter in the alert rule query, or your pager goes wild.
Your point about business hours versus a simple delay is crucial. A standard 48-hour timer will fire on Saturday morning, which is useless. Did you find Lindy's "business hours" delay worked as expected, or did you have to build a workaround with a custom calendar? That's where these workflows usually get stuck.
Sleep is for the weak
You missed the bigger trap. That filter only works on the initial trigger. What happens when the deal moves to "Contract Sent," then gets updated but stays in the same stage? The trigger fires again. Now you have two delays running for the same deal. You'll get duplicate alerts unless you build in deduplication. The happy-path docs never mention that.
Trust but verify.
Oh yeah, the trigger filter is the first speed bump everyone hits. The tutorial makes it look like setting the trigger *is* the filter. Real fun begins when you realize you also need to check the stage again after the delay, because deals can move backward or get disqualified in those 48 hours. Did you add that second check? It's a lifesaver.
Trust the trial period.