Validate Mandatory Fields on GlideRecord update?

[Chris Sanford1]

I am working on a requirement where when a release task is closed, it should automatically update the parent release to the next state. I have a business rule that runs on the release task after update. The tricky part is, it should not update if the mandatory fields on the parent release are not all populated. I am making the fields in question mandatory with UI policies on release table.

One idea I had, was to use data policies instead of UI policies to enforce mandatory, as they run on the server side. But one issue I encountered is the annoying 'Data Policy Exception' messages that show up on the page, often multiple times and I can't seem to figure out how to get rid of them. I tried a try-catch around the GlideRecord update but that didn't work. Also as a more critical issue, the state flow automatic script I have for the next state seems to run regardless of the update to the next state failing.

The only other idea I have is to check all the mandatory fields field by field in the business rule. This would not be a clean solution as I have multiple UI policies with different conditions whose logic I would have to copy into the business rule, and also if the UI policies were ever changed in the future the business rule would have to be updated with it which seems difficult to maintain.

So is there a cleaner solution to this problem?

[Shishir Srivast]

ah I got it now, shouldn't the release task be created if any of the mandatory field is not filled?

[Chris Sanford1]

Yeah, I guess most people don't have this kind of requirement. But see my reply to Sanjiv. Basically when the release gets to a new state, they want the system to create a task to be closed, and require new fields to be submitted all before the state progresses again.

[SanjivMeher]

I think the way your workflow is setup is not correct.

You should have all your mandatory field entered by user before creating task. In most of the cases all the required details are entered at the first stage itself. There will be very few fields that needs to be entered in subsequent which can be handled easily 

[Chris Sanford1]

Yeah, I wish my workflow was that simple. But the process owners want certain fields to only be visible and mandatory in a later state. Hence the UI policies. There are actually multiple states, each of which introduces new visible and mandatory fields and generates a release task that must be closed at the same time. I was just simplifying for the readers. I think the thought behind it is that all of the information may not be known at the time the release record is created.

[SanjivMeher]

Then I would add a business rule to abort action on release task table, based on task name if certain field is empty in certain stages of the parent Releases.