xDM

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.

Thanks, 

Brent VA

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). 

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?