1

I have a requirement in which for Inactive accounts if user try to edit or create a new task then it should not allow user to save the task. It should throw some validation message. On the task object there is a field 'Related To' which gives me All the accounts but I can not apply filter criteria for this kind of field.SO I am trying to write a validation rule on task which should throw an error message when the account status is inactive. I am trying to write like this:

OR(whatid!=null,Account.Inactive=true)

but in the validation rule I am not able to find Account.

Is there any way where I can get the Inactive field value so that I apply it in validation rule?

Or I have to do coding in this scenario. Please suggest

3

You cannot reference the related Account's fields while writing a validation rule on the Task. The Task object WhatID is polymorphic which means it could be refer to several objects. On the whatid at least you cannot reference related fields like you can with ownerid which is polymorphic as well

The only reliable option will be to make use of an Apex Trigger that prevents the creation of the Task.

  • 1
    Note that some polymorphic fields can be referenced in formulas, but WhatId does not seem to be supported. – Adrian Larson Sep 12 '16 at 11:44
  • Good point, like lead owner ? – Eric Sep 12 '16 at 11:50
  • Yeah I don't know if it's supported on any field besides OwnerId. It's just no longer universally true that you can't pull relationship information through polymorphic relationships. – Adrian Larson Sep 12 '16 at 12:04
  • Thanks Eric,Adrian for the confirmation will try it via apex code. – Dhananjay Patil Sep 12 '16 at 12:10
  • Although you can reference the Account's fields - they don't show up in the insert field dialog but you can actually manually add those the formula - the Account Id is not filled in until saving the record to the database, and therefore rendering it useless to reference them. – Steven.B Aug 29 at 14:37
0

Having a similar requirement I stumbled upon the same problem. There is a hidden AccountId field, which allows you to reference related Account fields. This field is filled for you by Salesforce, but only after saving it to the database (as the WhatId field is polymorphic Salesforce doesn't know yet where to look for the related Account).

If you would run a before insert and an after insert trigger on Task or Event only logging the values in Trigger.new, you will notice that there are two fields that have changed in between: the ActivityDate and the AccountId. Apparently SF does some processing itself in between to populate these. The validation rules are evaluated before this happens so this AccountId field is empty in your validation rule. See also the order of execution:

  1. Executes all before triggers.
  2. Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any user-defined validation rules. The only system validation that Salesforce doesn't run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.

...

  1. Saves the record to the database, but doesn't commit yet.
  2. Executes all after triggers.

...

  1. Executes workflow rules.
  2. If there are workflow field updates, updates the record again.
  3. If the record was updated with workflow field updates, fires before update triggers and after update triggers one more time (and only one more time), in addition to standard validations. Custom validation rules, duplicate rules, and escalation rules are not run again.
  4. Executes processes and flows launched via processes and flow trigger workflow actions. When a process or flow executes a DML operation, the affected record goes through the save procedure.

...

  1. Commits all DML operations to the database.

I suspect that your AccountId is populated before step 6 or maybe 7. This means that in a workflow field update for example the Account fields are available for referencing. However, as noted in 12, these won't run validation rules again.

Your remaining no-code option is to create a checkbox field on Activity called Account is inactive, create a process that checks the Account's Active field, and if not, ticks your Account is inactive checkbox. On Task you create a validation rule that evaluates just this checkbox. (Although by this you could also directly check the original Account's Active field as it should be available by this point - I haven't tried that out though).

The major downside of this approach is the ugly error message you get:

We can't save this record because the “Account inactive validation” process failed. Give your Salesforce admin these details.
This error occurred when the flow tried to update records: 
FIELD_CUSTOM_VALIDATION_EXCEPTION: This account is marked as inactive.. You can look up ExceptionCode values in the SOAP API Developer Guide. Error ID: 238050955-206580 (-58786743)

...and of course the accompanying email you will get delivered nicely in your inbox every time someone hits your validation rule.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.