function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Aaron RodgersAaron Rodgers 

Checking values of related list before changing status of contract

Hi All,

Can someone please shed some light on how to create a validation rule ( or alternative ) to check if values in a related list contain certain values before letting the contract status be changed to closed??

Eg, contract status cannot be changed to closed if values in the related list "parts to be supplied" still have values of "not supplied" next to them
Virendra ChouhanVirendra Chouhan
Hi Aaron,

In validation rule you cant access the child object's field so you have to validate it into the trigger.
Like take your example :
  1. Write a trigger on contract with before update event.
  2. Check that if Contract's status is closed then query on the related object.
  3. After that check the value in the related object's record.
  4. And then write adderror on it to display error messag
K_McRaeK_McRae
Aaron,

You could create a rollup field of the parent record that does a count of the children with a filter criteria of "not supplied".

This will give you, at the parent record level, the number of child record that are set to "not supplied".

Your validation rule can check that the value of this rollup field is zero before progressing.

cheers,
Keith
SwarnasankhaSwarnasankha
Hi Aaron!

Now the solution depends on what kind of a relationship the child entity (related list) has with the Contract object.
  • In case the relationship is a Master-Detail Relationship then the solution suggested by K_McRae is the best fit.
  • In case the relationship is a Lookup Relationship then the solution suggested by Virendra would be the way to move forward.

In case the current relationship is a Lookup then I strongly suggest you consider the option of converting it into a Master-Detail especially if you are not very hands-on with coding or do not have developers in your implementation/support team. The conversion would be pretty easy with the only exception of handling any child entity records which are not associated with a Contract - this too is not a very difficult data update exercise.

Again you will certainly need to weigh out how this change will impact if you plan to use this child entity in any future enhancements where it may be linked to another Parent.

Hope this helps you in making the decision a little easier.