Hello, so I am trying to set something up where if a Data Steward performs an Override edit on a record loaded externally we have an Attribute called Override Reason that is then required to be filled in. So instead of a Mandatory bit on the attribute I would be validating, in the context of an Override edit, that this value is filled in.
This is not the same as Pre or Post Consolidation validation in that I only want it applied in the case of this type of edit, to ensure a reason is given for overriding previously loaded data that came through an automated interface.
thank you again for posting your interesting use cases in our community!
I tested this successfully:
ViewType <> 'SA4L' or OverrideReason is not null
This should answer your needs!
That sounds like an awesome solution, and I never would have sorted that out without your input. Thanks much ! I will give this a try today (this technique should come in handy for other things too). - Brent VA
Alas...it did not work for me. I think I can see why also. The setup for an Override works, that is if I do one and try to exit without an entry it will validate until one is filled in, that's great. But if I then UNDO the override, or simply open a record for Edit but don't change anything, it will not let me press "Finish" to save without an override even though one is not currently applied to the record.
Let's look at the formula in this case:
"ViewType <> 'SA4L' or StewardOverrideReason is not null"
If the view type is not the Golden Record type it should allow an edit. In this case I am in that view so it checks the condition "StewardOverrideReason IS NOT NULL". This is always checked, so it prevents ANY edit session from exiting once opened unless the edit is discarded, even if the record has no override.
I think what I need is something like this, but I get an error trying to do it because the Has Override value does not appear to be contextually available validating in this view.
"ViewType <> 'SA4L' or (StewardOverrideReason is not null OR HasOverride= 0)"
When I do this I get these errors in model validation:
So then I tried an alternative approach to use the "b_hasoverride" internal column name instead of the friendly "HasOverride" name, using the formula "ViewType <> 'SA4L' or (StewardOverrideReason is not null OR b_hasoverride = 0)". In this case it gives me the error that this version of the column is not available either but it's a different error...and implies that the HasOverride should actually work in context as I thought. The new error lists it as available, implying that it should work but it does not as described above:
The formula editor does error the forumla out if I open it (doesn't like the HasOverride column).
Hi Brent, I got your point.
Then, how about using a hash function based on all possible overridable columns, to update your validation like this (sample with PostgreSQL MD5 function) :
ViewType <> 'SA4L' or StewardOverrideReason is not null or MD5(att1||att2||att3...) = MD5(GoldenRecord.att1||GoldenRecord.att2||GoldenRecord.att3...)
This should ensure that the current authored value is different than the existing golden record value to raise the validation error.
I have tested the described use-case succesfully in my environment.
I hope this helps !
I think hashing is great, but there's around 40-45 or so attributes. I would find this hard to maintain and be concerned that it would be missed when adding or (manually) removing attributes. I will tinker with this more and see if there might be another way. Out of curiosity, how does the UI know there is an Override turned off or on?
Hi Brent, understood.
The UI might not persist the data into the database during authoring, but only when the user will click the next or finish button, so this might not be user friendly to not be aware that he should have filled in another value before clicking.
When values are persisted, this is stored in the SF table, where '1' flags are stored for the attributes that had the pencil clicked.
So I would recommend building your custom function to retrieve the user list of attributes from an entity, and apply the hash based on this function's return, as I did not find any built-in field to know that an override occured during authoring.