Validation Rule on Parent Object blocking any activity on Child records?

Question

I have a Validation Rule on Account, that when reaching a certain stage, several fields need to be filled out. A user couldn't log activities on Contact related to this account due to this Validation Rule error. Is there a way to ensure that the Validation Rule error would only influence the object it works on, but the User can still work with Child Objects and for example add Activities related to this record?

Validation Rule :

AND(
NOT(Approved__c),
ISPICKVAL(Type,"Partner"),

OR(
ISBLANK(Company_Legal_Name__c),
ISBLANK(Shareholder__c),
ISBLANK(Executive__c),
ISBLANK(BillingAddress),

AND(
ISPICKVAL( Partner_Stage__c ,"P4"),
ISPICKVAL(Partner_Stage__c ,"P5"),
ISPICKVAL(Partner_Stage__c ,"P6"),
ISPICKVAL(Partner_Stage__c ,"P7")
)))

Answer 1

The purpose of validation rules are to prevent bad/invalid data. It can be annoying, but your validation rule here is doing its job properly.

Validation rules do only work on the SObject that they're defined on.

Through some combination of triggers, workflow rules, process builder, and flows, you have a chain of execution that starts with an Activity, and ends up performing an update on an Account (which results in the validation rule in question being evaluated).

Probably the ideal solution here would be for you/your user to take the opportunity to fix the data on your Account(s) so that it is no longer invalid. Your validation rules and other business processes should be responsible for making sure that bad data cannot be entered in the first place. Failing that, the next best option is to fix bad data when you find it (spreading the work out over time and across many people).

You could choose to make changes to the various bits of automation (triggers, workflow, process builder, and flows) so that it can detect when it would try to update an Account in an invalid state and then not perform that update, but that's not an ideal solution for a few different reasons:

• It's fairly likely to necessitate a move from declarative solutions, like workflow rules, to Apex
• The more of these exceptions/carve-outs you have, the more difficult it becomes to add the next one (or even make changes to existing code/declarative solutions)
• You're not fixing the issue, you're kicking the can down the road. It'll be a lot more difficult to deal with needing to fix/update tens of thousands of records (and part of that involves determining which records are problematic) than it is to deal with it as it comes