Script Executed on Unity Form requires Submit before updated fields are accessible by other scripts

[Warren_Evans1]

We are attempting to execute a unity form custom action script that populates another section of the form, and is executed via a condition button located within a row of a repeater section. What we are finding is that this data is not accessible when the next script, executed via an ad-hoc task, is run. The form "reloads" when the script is executed and our populated data is no longer present. Additionally, in diagnostics we can look at the values retrieved and they are all coming up blank.

Additionally, when we manually enter data into the form fields we get this same behavior. Unless we submit the form before executing the task, the data entered does not remain after the form gets "reloaded", and the script does not have access to the data.

When updating the form we use a CustomActionFormModifier and execute ApplyChanges once all of our field modifications are done. We take the form instance directly from the args.

Is this expected behavior? Why is the data populated by the IWorkflowScript accessible from a UnityFormCustomActionScript but not vice versa? Why is data entered manually not accessible by an IWorkflowScript until we execute a submit? Is there some action that needs to be run within the script in addition to ApplyChanges? Forcing the users to submit before each script is executed adds a large amount of additional clicks and time to the process, so if there is any way to avoid this we would like to know about it.

[Adam_Kuhn]

Hi Warren --

Unity Form Custom Action Scripts interact with the Form Instance, not with a document, and only the form field values are visible; conversely, Workflow scripts execute on documents, and the Keyword values are exposed but not form field data. I do not believe the two can work in tandem in the way you've described, unless I'm misunderstanding the process.

Best,

Adam Kuhn, API Analyst

[Nevin_Steindam · Accepted solution]

I'll expand on Adam's comment a bit and add some suggestions:

Workflow scripts are designed to run against the *stored* values for a document. As you're seeing, you can't even run ad hoc tasks against a form with unsaved changes. This is just how ad hoc tasks work in general - Any rules or actions could be run in a task, and it's easy to see how messy that would get if every Workflow action had to allow for saved or unsaved keyword values. In short, your Workflow script can see keywords and form values, but they will not be values that the user is currently changing.

On the other hand, the Unity Form custom action always runs against a form that is currently open for editing. It looks at the values currently in memory. If you looked at the keyword values in the database, they may not reflect the user's current changes. And even more importantly, this might be a brand new form that has not yet been saved as a document in OnBase. If the interface depended on a Document object existing behind the scenes, that would get confusing.

I'm not sure what your business case is, so I don't know what you are trying to do by running both a custom action script and a Workflow script. But here are a few strategies I can suggest:

• Make sure any keywords your custom action needs to work with are on present your form as fields. If the keywords don't need to be on the form otherwise, make the field hidden.
• If your script needs to see the keyword value saved in the database, even if the user may have edited it, then you can do other tricks with custom actions. For example, make the keyword available for editing, but have a second hidden field that the original value can be copied to as soon as the form opens.
• If you really, really need to see the document object, your script can make a document query to look for it. Keep in mind that if the form is being created for the first time, there will NOT be a document to find.
• You can define a System Event in OnBase Studio which triggers when the form is saved. This may give you a chance to do some of the work that you're depending on with your ad hoc task. It can run Workflow rules and actions, including another script. For example, the task can check if the document is currently in a certain queue, and do the work accordingly. The System Event could also save the document handle to a hidden field on the form, if you need that information to perform a document query like I mentioned above.

[Adam_Kuhn]

As always, Nevin has the best advice!

[Warren_Evans1]

Essentially, there are a couple of web services that this form needs to interact with. Data from an OCR'd form comes in and gets correlated versus data retrieved from this web service, and is then either modified or a new object is created. In total there are 6 different webservice calls. Two of these calls involve opening a web page for the user to then interact with. Ideally, we were going to use custom actions to drive the user interaction, but because we have to open an external web page for 2/6 calls we opted to just put everything within the ad-hoc tasks. Even with those ad-hoc tasks we are still using some unity form custom action scripts to move data around within the form, which i guess is whats causing our issues.

Is there a way for us to display a web page to a user from a custom action script (or some other unity form tool)? If that is possible, we can just refactor our solution to use custom actions instead of this combination of scripts like we have now.