Allow Synchronous workflows to refresh the user's form

[JoeNewstrom]

Currently certain types of data updates performed by Synchronous workflows require a form refresh in order to be viewed. There are some (currently unsupported) methods to use JavaScript to update the form, but this should be a core addition to synchronous workflows (at least as an optional Workflow Activity). To do so in a supported manner would enhance synchronous workflow functionality.

[D365Ideas_Admin]

Can you provide me with scenarios where this is failing? Is this a create or update? What entity ? What are you trying to do in the real-time/Sync workflow that is not reflecting back in the refresh form?

[D365Ideas_Admin]

Thanks for your suggestion. Real-Time workflows was designed to run on the server . It is difficult to design a workflow workflow system that runs on different clients ( think phone, mobile ..) Further , we wanted transaction consistency when data is brought into the system through API. I however understand your viewpoint on latency between user action and response. I would suggest two options for a requirement around client real-time. Use business rules where the rules need to run only on client. If they need to run on server as well, you could do what you have done (invoke the workflow by saving ) or you could create a custom action that is invoked using a web service request when user moves away from a field or fills parts of the field. We are looking into combining business rules and real-time workflows so that it can be authored once and you get both behaviors if desired for a future release.

[D365Ideas_Admin]

Can you provide me with scenarios where this is failing? Is this a create or update? What entity ? What are you trying to do in the real-time/Sync workflow that is not reflecting back in the refresh form?

[JoeNewstrom]

Sure. Basically, the issue is that the "real time" workflows don't fire until the changes are committed to the server. Because users understand "real time" to mean "as I am performing the action" this creates confusion as to why changes initiated by Workflow do not commit immediately upon the action that initiates the workflow (for instance, if the workflow kicks off "on change" of a boolean, the workflow really commits when the boolean changes *and* after navigating away from the page, manually refreshing the page, manually saving the page, or when autosave happens to kick in. This introduces a perceived latency in the workflow from the perspective of a non-developer user because the change happens and there is an unpredictable period of time before their changes will be seen. I've gotten around this by binding a very simple reload() javascript function to fields that initiate real time workflows. The function commits changes on forms where the form type is not undefined and is not a Create form, and sets the focus to where the user was before the change. It works as follows: function reload() { //only run on existing records, exclude create and undefined form types if (Xrm.Page.ui.getFormType() != 0 && Xrm.Page.ui.getFormType() != 1) { var currentControl = Xrm.Page.ui.getCurrentControl(); Xrm.Page.data.entity.save(); if (currentControl != null) { currentControl.setFocus(); } } } I get that this is not a bug. I do feel that the functionality as advertised is confusing to end users since there is a relatively complex set of conditions required to actually kick off a workflow after changes are made (at least for workflows initated by an on change event).