Validation Rules issue

Bugs & Issues
1

Hello,

I think I found an issue with the Validation Rules processing (or at least, a grey area).

I’ve created 4 fields which should not be able to be changed if 2 of them are not set. In order to modify the 2 fields “at the same time”, I’m using a button which ask the user to fill the 4 fields.

Then, I have a Validation Rule that trigger on the 4 fields and that the Validation formula is :

IsEmpty([Step 1 DB].MandatoryFieldA) = false and IsEmpty([Step 1 DB].MandatoryFieldB) = false

Theoretically, on my Button form, when I click on Run, all my fields are changed at the same time. But it seems that the Validation Rules engine evaluate the situation right after the first field change. That’s a big limitation on my Workflow process.

Could you please review this process in order to take into account the situation of all triggered fields at the same time ?

2

So you need to block changes if the two fields are empty?

If so, then shouldn’t your validation rule be

IsEmpty([Step 1 DB].MandatoryFieldA) and IsEmpty([Step 1 DB].MandatoryFieldB)

?

Alternatively, if either being empty should block changes…

IsEmpty([Step 1 DB].MandatoryFieldA) or IsEmpty([Step 1 DB].MandatoryFieldB)

3

By the way, just wondering why use validation rules rather than making these fields required fields?

4

Ok, that’s correct. My logic was wrong.

What about if my Fields A and B are set and I want to :

  1. Prevent the User to change one of my 4 fields ?
  2. If the User wants to clear the 4 fields, he needs to do it from a Button ? So, when Field A and Field B are set, it should not possible to change them individually.

This fields are only required when starting a schedule process. They aren’t required for the entity creation.

5

When planning validation rules, I think it can be best to enumerate (or at least consider) all the possible actions that a user might attempt to take, and make a clear decision on which should be blocked and which should not.
It seem like you have 4 fields, two of which seem to be more important than the others (mandatory). So let’s call the fields M1, M2, O1 and O2 (optional fields).
Each field can go from empty to filled (E→F), filled to empty (F→E) or its value can be changed (FC) or unchanged (EUC or FUC).

Here’s an example of an action event:

M1 (E→F)
M2 (EUC)
O1 (FC)
O2 (FUC)

This notation means mandatory field 1 is being filled with a value, at the same time that optional field 1 is having its value changed. M2 remains empty and O2 keeps the same (non-empty) value.
Assuming that you can enumerate all the possibilities (and decide which should be blocked and which not) then defining the necessary validation rule(s) shouldn’t be that hard :crossed_fingers:

Note: At this stage, it doesn’t really matter whether the user is making the changes with a button or on the UI, but I can understand that you might end up defining validation rules such that a user can only do a specific desirable action via a button (i.e. an action that requires simultaneous updates to multiple fields)

Anyway, as I see it, your need is somewhat described here:

but I am uncertain of the details - it seems ambiguously worded.

“If the User wants to clear the 4 fields” - do you mean ‘if the user wants to clear any of the 4 fields’? or ‘if the user wants to clear all of the 4 fields’?

“when Field A and Field B are set, it should not possible to change them individually.” - what is ‘them’ in this sentence? Do you mean ‘it should not be possible to change either of Field A or Field B’ or ‘it should be not possible to change any of the aforementioned 4 fields’?

Anyway, maybe there’s a top level use case you could provide which might help us align on what is being worked towards… an example of what the ultimate goal is - maybe with more meaningful names that ‘mandatory field A’(!) - so that we’re in the same headspace

6

Sorry, what I mean is that in all cases, the End User should not be able to fill or clear individually one of this 4 fields.

  • M1 cannot be filled if M2 isn’t filled.
  • M2 cannot be filled if M1 isn’t filled.
  • O3 or O4 cannot be filled if M1 and M2 aren’t filled.
  • M1 cannot be cleared if M2 isn’t cleared.
  • M2 cannot be cleared if M1 isn’t cleared.
  • O3 or O4 cannot be cleared if M1 and M2 aren’t cleared.

What I’ve done for now is that I’ve hidden the fields and I’m only displaying my two buttons. This will not prevent someone to create his private views and to add the fields but it become complicated to try to solve this issue with the validation rules. I think that at some point, an upgrade of the Validation Rules with workflows will help.

7

Don’t the cases you have described the validation rule logic you need to implement?

i.e.

Validation Rule triggered on a change to M1, M2, O3 or O4, with blocking logic as follows:

prevM1 = empty AND M1 != empty AND M2 = empty
OR
prevM2 = empty AND M2 != empty AND M1 = empty
OR
prevO3 = empty AND O3 != empty AND (M1 = empty OR M2 = empty)
OR
prevO4 = empty AND O4 != empty AND (M1 = empty OR M2 = empty)
OR
prevM1 != empty AND M1 = empty AND M2 != empty
OR
prevM2 != empty AND M2 = empty AND M1 != empty
OR
prevO3 != empty AND O3 = empty AND (M1 != empty OR M2 != empty)
OR
prevO4 != empty AND O4 = empty AND (M1 != empty OR M2 != empty)

8

I appreciate your help and probably it works but I think it adds too much complexity to avoid a situation that perhaps will happen 1 time in a year. I would like to completely cover the situation but I resigned to something simpler that will cover 90% of the problem I’m trying to solve.

Fibery master the connection and building of processes at some point but when you want to create some detailed functionalities (small “apps” on processes or workflows) and add some constraints too avoid some situations, Fibery lacks, you need to add many complexity (with or without code). That’s just a feeling I have sometimes when I build things in Fibery.

But this is not negative, it is a “you built so much since we are on Fibery and we want more advanced features in order to build more advanced things”. I’m sure that at some point, this kind of manipulations will become easier.

Thanks again for your effort.