# Pipedrive automation not triggering: the deals it never saw

https://salesbond.app/blog/pipedrive-automation-not-triggering/
Published: 2026-10-04 · Updated: 2026-10-25

A Pipedrive automation usually stays silent for one of five reasons: the deal does not match the trigger and its conditions, the automation was not active for that user before the change, the deal came from an import or an API request that does not qualify, the triggering user cannot see the deal or the filter, or a bulk edit hit a frequency limit. The awkward part is that a run which fails its trigger conditions is discarded and never shows in the automation history, so there is no error to read ( [Pipedrive: troubleshooting automations](https://support.pipedrive.com/en/article/troubleshooting-automations)). Start the check at the deal itself, not at the history tab.

Below is the order we check in, from the most common cause to the rarest. We have written about [automations that die with their owner](https://salesbond.app/blog/pipedrive-automations-owner-audit/) and about [a bulk edit that fires automations you forgot](https://salesbond.app/blog/pipedrive-bulk-edit-safety/). This one is the opposite failure: the automation that should have fired and didn’t.

## The follow-up task that was never created

An invented scene, with a shape we keep meeting. Marcus Hale runs a seven-person sales team. In the spring he built an automation: when a deal’s stage changes to Proposal Sent, create a call activity “Follow up on proposal” for the deal owner, due two days later. It works, and he stopped asking about proposals.

Tessa Lindqvist joined on the first of September. On Tuesday, September 15, she moved her first real deal to Proposal Sent. The call should have been due on Thursday. On Thursday her activity list has nothing for that deal. She assumes there is a delay and gets on with her calls. Marcus sees the automation running for other reps all week and is not looking for a run that is missing.

The deal sat in Proposal Sent with no next activity until Thursday, September 24, nine days, before anyone asked the buyer what they thought. That is the cost of a silent automation: no error, no failed step, just a deal with no next step in the stage where the next step matters most.

The cause was the first item on the list below. Two minutes to find once Marcus knew where to look. Nine days because nobody was looking.

## Not retroactive, and only for the people it is switched on for

First confirm that the automation is active for the user who made the change, and that it was active before the change. Pipedrive’s guide says it in one line: confirm the automation is active for you; automations do not work retroactively ( [Pipedrive: troubleshooting automations](https://support.pipedrive.com/en/article/troubleshooting-automations)).

Two different failures hide in that sentence.

The retroactive one is easy to picture. The deal moved on Monday, the automation was switched on Tuesday, and it does not go back for Monday’s deal. If you turned an automation on mid-quarter, the deals already sitting in the stage never got thier task. Nobody will tell you. The filter that finds them is plain: open deals in that stage with no next activity.

The “active for you” failure is Tessa’s. Marcus built the automation to run for a chosen set of users, the people on the team in the spring. Tessa was not one of them, so her stage change was never an event the automation saw. To Marcus it looked like a working automation, because it was, for everyone else. He added her to the user list, created the call by hand, and the buyer turned out to have a question about page two of the proposal that nobody had answered.

The deactivated-owner case is in [the automation owner audit](https://salesbond.app/blog/pipedrive-automations-owner-audit/); the point here is narrower. When someone joins, add them to the user list of every automation that is supposed to cover them, in the same sitting as [their permission set and visibility group](https://salesbond.app/blog/pipedrive-new-rep-access-permission-sets/).

One more thing a rep cannot do for herself: the history tab only shows executions of automations you created yourself ( [Pipedrive: automations history](https://support.pipedrive.com/en/article/workflow-automation-history)). Tessa could not have checked. Marcus could, but only for runs that happened, and hers did not.

## When the condition simply wasn’t met (and why history won’t show it)

Once the automation is active for the right user the next question is whether the deal matched the trigger and the conditions. Open the deal’s History > Changelog and read what changed and when. Deals, people and organizations show the full changelog in the detail view; other item types do not ( [Pipedrive: troubleshooting automations](https://support.pipedrive.com/en/article/troubleshooting-automations)).

This is where the history tab stops being useful. An execution appears in history only when it meets all trigger conditions and completes its first action. Executions that fail the conditions are discarded and not shown in the list ( [Pipedrive: troubleshooting automations](https://support.pipedrive.com/en/article/troubleshooting-automations), [automations history](https://support.pipedrive.com/en/article/workflow-automation-history)). So “nothing in history” fits two very different stories: the event never reached the automation, or it reached it and failed a condition at the door. Either way the deal looks the same.

A condition deeper in the automation is different. If the run passed the trigger, performed its first action and then hit a condition step that was not met, it shows as Stopped. A wait-for-condition step runs for up to seven days, and if the condition is still not met, the automation stops ( [Pipedrive: automations history](https://support.pipedrive.com/en/article/workflow-automation-history), [automation limits](https://support.pipedrive.com/en/article/automation-limits)). Stopped runs can be found with the Stopped filter in the history tab (same source). Discarded ones cannot be found at all.

So the practical rule: read the trigger conditions against the deal’s changelog, field by field. The usual culprits are quiet: a condition on deal owner after a reassignment, on a custom field the rep never filled in, on a pipeline the deal has left. The automation is doing what it was told; it was told something narrower than the manager remembers.

And do it quickly. Execution history is kept for 15 days; for an automation with delay steps it is kept longer by the total delay configured, so a two-day delay means 17 days ( [Pipedrive: automations history](https://support.pipedrive.com/en/article/workflow-automation-history)). After that even the Stopped runs are gone.

![Five-step check order for an automation that did not fire, from user activation to bulk edits and frequency limits](https://salesbond.app/wp-content/uploads/2026/10/pipedrive-automation-not-triggering-2.png)

## Deals that arrive through a form, an API or an import

Marcus’s automation watches a stage change made by a rep. Many watch creation instead, and those go quiet when deals arrive from somewhere other than a person typing.

For items created by an API request or a third-party form, Pipedrive lists three conditions: the automation was active before the item was created; the new item matches the trigger and conditions; and the fields passed in carry valid, detectable values, such as the field names, the owner and the status. The guide’s example is the one we see most: the automation triggers when a deal is created and owned by you, the integration creates the deal under another user, and nothing fires ( [Pipedrive: troubleshooting automations](https://support.pipedrive.com/en/article/troubleshooting-automations)). The integration is not broken. The deal is simply not the the deal the automation was told to wait for. Records created through Zapier have [their own failure mode, duplicates](https://salesbond.app/blog/pipedrive-zapier-duplicate-records/), covered separately.

Imports are stricter. Most imports do not trigger automations at all, even when the imported fields match the automation’s logic. The exceptions Pipedrive documents:

| How the item was created or changed | Does an automation fire? |
| --- | --- |
| Import that updates leads, with an event trigger (for example, the lead owner changes) | Yes |
| Import that adds or updates date fields on activities, deals, organizations or people, with a date trigger (for example, “a day after the deal was created”) | Yes |
| Any other import | No |
| API request or third-party form | Only if the automation was active first, the new item matches the trigger and conditions, and the fields it passes carry valid, detectable values |

Source for all four rows: [Pipedrive: troubleshooting automations](https://support.pipedrive.com/en/article/troubleshooting-automations).

The consequence is mechanical. If you [import a spreadsheet of deals](https://salesbond.app/blog/pipedrive-update-records-spreadsheet-system-id/) from a trade show, the “new deal, create first call” automation creates zero calls, and those deals start life with no next activity. Not a reason to avoid imports, a reason to run the next-activity filter right after one.

## Visibility: the trigger runs as a person who cannot see the deal

This one produces no symptom until you go looking. If the user whose action triggers the automation does not have access to the filter or to the items involved, the automation fails ( [Pipedrive: troubleshooting automations](https://support.pipedrive.com/en/article/troubleshooting-automations)). Pipedrive’s fix is two settings: change the filter’s visibility from private to shared, and make sure item visibility and the “See other users’ data” permission let the triggering user see what the automation touches.

The private filter is the classic. A manager builds an automation against a filter he made for himself. For him it works. For a rep whose stage change is supposed to trigger it, the filter does not exist, and the rep has no way of knowing a filter is even involved.

We prefer shared filters for anything an automation depends on, named so the dependency is visible: “AUTO: proposals awaiting follow-up” rather than “Marcus proposals”. A private filter under an automation is a setting only one person can see, it fails the same quiet way as an automation only one person owns.

## Bulk edits and frequency limits: “Stopped” and the ones you never see

The last place to look is the one with actual error messages. A bulk edit can trigger automations, and when it involves a large number of items it can exceed the frequency limits: up to 10,000 executions within ten minutes per company, and up to 5,000 within ten minutes for a single automation. Executions stopped by a bulk edit show as “Stopped” in history, and the error in Pipedrive’s list is ReachedRateLimit, with the message “Maximum automation execution frequency limit reached” ( [Pipedrive: automation limits](https://support.pipedrive.com/en/article/automation-limits), [troubleshooting automations](https://support.pipedrive.com/en/article/troubleshooting-automations)). This is the reverse of [our bulk edit article](https://salesbond.app/blog/pipedrive-bulk-edit-safety/), where the automation fires 150 times when nobody wanted it to. Here it fires until the limit and stops for the rest, and those are the deals with no task. The rest of the [automation limits by plan on Growth](https://salesbond.app/blog/pipedrive-automation-limits-follow-up/), from wait steps to the 90-day total, are in a separate piece.

Two cases are harder, because they leave no trace. When automations create loops between each other, or one automation triggers many others, the executions are ignored and not shown in history at all ( [Pipedrive: automation limits](https://support.pipedrive.com/en/article/automation-limits)). If a stage change is supposed to cascade through three automations and the third one creates the follow-up task, the task can go missing with nothing in teh history tab to explain it. Flatten the chain: one trigger, one automation, actions in sequence.

A bulk edit can also run with automations deliberately skipped: during large bulk actions, admins can skip automations to avoid overload or unnecessary triggering ( [Pipedrive: troubleshooting automations](https://support.pipedrive.com/en/article/troubleshooting-automations)). Sensible for a cleanup. Less so when an admin bulk-moves forty deals into Proposal Sent and skips the automation that creates their follow-ups. Agree as a team which bulk edits run automations, and write it down next to the automation. (A failed email step is a different problem, visible in history; we covered [the gaps failed emails leave](https://salesbond.app/blog/pipedrive-failed-emails-follow-up-gaps/) separately.)

## A short routine that catches silent automations before a deal goes quiet

Everything above is reactive. The routine we actually run starts from the deals and asks the automation to explain itself.

1. Once a week, open the deals list filtered to open deals in the stages your automations cover with no next activity scheduled. Each one is a human who forgot or an automation that did not fire. Sort by owner; a cluster under one name is usually the “active for you” problem.
2. For each of those deals, open History > Changelog and read the change that should have triggered the automation. Compare it with the trigger and conditions, field by field.
3. In the automation itself, check who it is active for. Do it the day anyone joins or changes role.
4. After any import, run the same filter immediately. Plan the first activities for imported deals by hand.
5. Before a bulk edit that touches a trigger field, decide whether automations should run, tell the team, and look for Stopped runs in the history tab afterward.
6. Make every filter an automation depends on shared, and name it as a dependency.
7. Check the history tab’s Stopped and Failed filters within the week. After 15 days most of the evidence is gone.

That routine checks the automation. Something still has to check the deal, because automations are only one way a deal ends up with no next step. We build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. Deal Health checks every deal in the connected CRM against the enabled rules, assigns a health score, shows the specific violations and explains what to do. A notification might read, for example: “no next activity is scheduled and the expected close date has passed.” If a missing follow-up task is what brought you here, [check your CRM with SalesBond](https://salesbond.app/).