Hi Omer,

The best way to achieve this is to use an After Change rule for setting a Field. Here you'd want to use the current_update for the Failure Type field to check for if its changed. If so set the Information field to null.

Then whenever the Failure Type is changed whatever the value in the information field will be removed.

For example:

Hello, Dave,

Thank you for your feedback.I need to use current_update, but there will be a situation like this: even if the related field is the same, it will make the other field null.However, when the related field changes, the other field should be null.Current_update does not seem to meet this situation.

Hi Omer,

I might be missing something but by using the current_update.<fieldName>.IsChanged that then allows the related text field to be reset to null. So as long as the list field isn't changed the related text field can still be modified. But once the user tries to modify the List field that is the only point where the rule would kick in and reset the related text field.

Let me know if that's not what you're trying to achieve.

Hi Dave, 

What I want to do is actually the following, for example, in the screenshot I shared, I selected the value number 1 and wrote 123 in the more information field. If the value I selected from the list (this should be in the entity link) is different from the same value (for example, I want to select the list element number 2), I want to make the information field null; but current_update.Ischanged does not seem to work correctly here. 

Best Regards

Hi Omer,

Thanks for the additional screenshots do you also have the Business Rule you've created just to check the logic you are using and see why this isn't working for you.

Hi Dave,

Yes, I have created rules. I share the screenshots of some of the rules I created with you below.  

Best Regards

Hi Omer,

I can see the issue that you are having and have a feeling its due to the fact you are using UserOptions as opposed to actual fields within a record. When I first sent the rule to you I based it upon fields within a Custom Record type and not using an Offering. After trying the same rule within the Offering I can see the same issue as you've mentioned. This is due to User Options are grouped together which has an impact on how this rule can then be run.

I'll check to see if there is another way to achieve what you are wanting to do. Or else it might be to have fields instead of User Options as a workaround.