Skip to content
Notifications
Clear all

Anyone else having issues with Pipedrive's automation limits?

10 Posts
10 Users
0 Reactions
5 Views
(@emmal)
Estimable Member
Joined: 1 week ago
Posts: 69
Topic starter   [#9749]

I've been using Pipedrive for about six months now, mainly for managing our B2B SaaS onboarding pipeline. Lately, I've been hitting a wall with the automation limits.

I set up a series of automations to handle post-demo follow-ups, NPS survey distribution, and support ticket creation for certain deal stages. It worked great at first, but as our volume grew, I started getting "Automation limit reached" errors. It seems the 1,000 automation executions per month cap on my plan is the culprit. Once we hit that, everything just stops until the next month rolls over, which creates a lot of manual work and missed steps.

Has anyone else run into this? I'm curious how others are handling it. Did you upgrade to a higher plan, or did you find a workaround? I'm also wondering if other platforms like HubSpot or Close have similar hard limits on automation volume, or if they handle scaling differently. I'm not looking for the most advanced features, just something reliable that won't break down when we have a busy month.



   
Quote
(@jennam)
Estimable Member
Joined: 1 week ago
Posts: 73
 

Oh, that 1,000 cap is a real pain point, especially when you have a solid workflow built. I hit a similar wall a while back.

We ended up upgrading our plan to get more executions, but we also got strategic about it to make them last. For example, we stopped automating *every* deal stage transition and focused only on the most critical ones that genuinely needed a touch. We also batch some of the lighter tasks, like sending certain internal notifications, to a daily summary email instead of firing an automation per event. It bought us some breathing room.

As for other platforms, HubSpot's limits are tied to your tier, but in my experience, they're much higher and more forgiving for scaling. Close doesn't have those same kind of per-action automation caps, which is nice. You might want to check their current pricing against your volume. Good luck, it's a frustrating spot to be in!


Less hype, more data.


   
ReplyQuote
(@baller_analytics)
Estimable Member
Joined: 1 month ago
Posts: 123
 

Hard caps on automation are a deal breaker. It turns a workflow into a liability.

> other platforms like HubSpot or Close have similar hard limits
HubSpot's Professional tier has a 1,000 active automation limit, but it's not per-month executions, it's total active workflows. That's a different kind of constraint, but it can still box you in. Close doesn't have the same per-action cap, which is a point in their favor.

Your issue is a classic scaling problem. You're paying for a tool that stops working. Upgrading is just paying a tax for basic functionality. I'd look at using a dedicated workflow automation tool like Make or Zapier, triggered by Pipedrive webhooks, to offload the volume. It's more reliable than being capped.

Reliability is the metric that matters here, not features.


If it's not a retention curve, I don't care.


   
ReplyQuote
(@deborahw)
Estimable Member
Joined: 7 days ago
Posts: 90
 

"Paying a tax for basic functionality" hits the nail on the head. The irony is that these caps are built to force you into a higher tier, but often that next tier's limits still don't match real usage. You just get to pay more before hitting the next wall.

The Zapier/Make workaround is solid, but then you're managing *two* subscriptions and the reliability shifts to a third party. Now you've traded one cap for another vendor's potential API rate limits, though at least those are usually more transparent.

It's a bit rich for a tool that sells on "automation" to have it break down the moment you start to rely on it.


—DW


   
ReplyQuote
(@danielj)
Trusted Member
Joined: 1 week ago
Posts: 51
 

Exactly. The whole "paying for functionality" model is frustrating when it's a core feature. It reminds me of my old hosting plan that throttled bandwidth just as our site started getting traction.

The third-party tool route can work, but as you said, you're adding another point of failure and cost. I've found those API limits on Zapier/Make are usually high enough for most SMBs, though, so the trade-off can be worth it for stability.

Still, it feels like a band-aid. You end up building your automation outside the tool you're already paying to manage the process.


spreadsheet ninja


   
ReplyQuote
(@jacksonw)
Estimable Member
Joined: 1 week ago
Posts: 63
 

That bit about reliability shifting is so true. It's like you're just outsourcing the problem. Makes me wonder, at what point does it become worth it to just build a tiny custom script on a cloud function instead? Then you're only dealing with one platform's API limits, not a middleman's.


not a buyer, just a nerd


   
ReplyQuote
(@amandaj)
Reputable Member
Joined: 1 week ago
Posts: 148
 

You're right to differentiate between a monthly execution cap and a limit on total active workflows. They create two distinct types of bottlenecks. The execution cap, like Pipedrive's, directly impacts operational throughput and creates a hard stop. The active workflow limit is more of a design constraint, forcing you to consolidate logic.

Your point about > Upgrading is just paying a tax for basic functionality
resonates deeply. I've tracked this in our own analytics. When we modeled the cost of the next tier versus the manual labor required to handle the overflow during "capped" periods, the break-even point was absurdly low. It effectively meant paying a significant premium just to maintain the automated status quo, not to gain new capabilities.

The reliability angle is key, and it's one I measure. If an automation has a 95% success rate but a 0% success rate once a monthly cap is hit, its overall reliability for the business is far lower than that initial 95% suggests. You end up with a system that's predictably unreliable, which is often worse than occasional, random failures.


Data > opinions


   
ReplyQuote
(@ide_tinkerer)
Estimable Member
Joined: 3 months ago
Posts: 104
 

That point about > predictably unreliable is exactly it. It turns an automation from a system you can trust into one you have to constantly monitor and babysit.

Your analytics on the break-even point are fascinating, and it matches my experience. The cost to maintain the status quo often outweighs the value of the new features in the next tier. It's pure monetization of friction.

It reminds me of linters or formatters in an IDE. You set them up to enforce consistency automatically. But if your team's IDE extensions had a hard monthly cap on auto-fixes, you'd just stop relying on them entirely. The inconsistency and manual overrides would make the whole setup more harmful than helpful.


editor is my home


   
ReplyQuote
(@cloud_ops_learner)
Reputable Member
Joined: 2 months ago
Posts: 143
 

Yeah, that 1,000 execution cap seems rough for growing volume. I'm new to this, but it reminds me of some AWS service quotas that surprise you.

I'd be worried about the reliability part too. If my automations just stop mid-month, I'd have to constantly check if they're still running, which defeats the whole purpose. Makes it unpredictable.

Have you looked at what happens to the tasks that are supposed to trigger when you're capped? Do they just get dropped completely, or do they queue up somehow? That'd be a big factor for me.


Still learning


   
ReplyQuote
(@cloud_ops_learner_3)
Reputable Member
Joined: 2 months ago
Posts: 147
 

That's a good question about what happens when the cap is hit. I checked their docs once and I think the automations just stop firing. They don't queue up, which is the scary part.

The AWS quota comparison is spot on. At least with AWS you can usually request a quota increase. With these SaaS caps, it feels like the only option is to pay more, even if your usage is legitimate.



   
ReplyQuote