Pipedrive automation conditions: test active changes and passive filters

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Separate the change from the state

Pipedrive distinguishes active conditions, which depend on an update, from passive conditions, which describe the current state of an item. For an update-triggered automation, a passive condition such as a deal being in the proposal stage does not identify which change should start the run. Pair it with the relevant monitored field or an active condition so the business event is explicit.

Write a small trigger matrix

Assume a fictional sales process should create a review activity when a deal moves into Proposal and its value is present. Use synthetic deals and state the expected outcome before saving the automation. This is an editorial fixture, not a live Pipedrive test.

Inspect the history and the source record

Pipedrive documents that update triggers can monitor selected fields and that the automation history identifies fields involved in a run. If nothing appears, confirm that the automation was active, the item met every condition and the triggering user could see the item and any filter used by the automation. A private filter can create an access failure for another user.

1. Name the business event and the item type.
2. Select only fields that can represent that event.
3. Add passive filters for required state, ownership or completeness.
4. Run positive, negative and unrelated-update fixtures.
5. Inspect the item changelog and automation history.
6. Reconcile created activities or field updates and remove the fixtures.

Accept a single explainable run

Accept the automation when the intended change produces exactly one expected result, unrelated edits do not run it and excluded records remain unchanged. Document feature availability and usage limits from the account rather than assuming every plan has the same automation capacity.