Attempting to uninstall NPSP Recurring Donation in a Sandbox, was able to resolve all Component Type dependencies that were blocking the uninstall, except last one which reads:
Component TypeName Problem
Custom Field | Recurring_Donation | Can't uninstall package because an external component is referencing a component in this package. Remove the reference, and then retry uninstalling this package. Workflow Rule Filter:
There is no name associated with the Workflow Rule Filter:
which makes it difficult to track down. I have downloaded all meta.xml files and reviewed all Flows and Triggers etc but can not find any reference to NPSP components.
#Nonprofit Success Pack #Uninstall NPSP
Hi Babak - that 'Workflow Rule Filter:' with no name is the classic uninstall blocker, and the reason your Flow/Trigger review came up empty is that it isn't a Flow or a trigger - it's a classic Workflow Rule, which is a separate metadata type you haven't looked at yet.
What's happening: somewhere you have a Workflow Rule whose criteria (the 'filter') references a Recurring Donation field from the package. The uninstall error points at the filter but can't surface the parent rule's name, which is why it's so hard to trace.
How to find it fast:
1. Retrieve the Workflow metadata for all objects and grep for the field. Via CLI: sf project retrieve start -m Workflow (or retrieve the Workflow type in Workbench), then search the .workflow files for the Recurring Donation field's API name (it'll be in the npe03 or npsp namespace). That pinpoints the exact rule immediately - far faster than clicking through Setup.
2. Prefer the UI? Go to Setup > Workflow Rules (not Flows) and review every rule - and crucially the inactive ones too, since inactive workflow rules still block an uninstall. Check each rule's criteria for a Recurring Donation field, plus any Field Updates that target one.
3. Don't forget cross-object rules: the blocking rule might live on a different object but reference the Recurring Donation field in its criteria or a field update.
Once you find it, remove the field from the rule's criteria (or delete/deactivate the rule if it's obsolete), then retry the uninstall.
Two things that trip people up: (a) it's Workflow Rules specifically, not Process Builder or Flow, so the metadata type to retrieve is Workflow; and (b) inactive rules still count. The CLI-retrieve-and-grep in step 1 is by far the quickest way to end the hunt.
Hope that cracks it!
