Let’s say a person actions a Process Instance in your workflow, but the item seems to “disappear” unexpectedly — routed to a special queue for workflow administrators because of an error condition. It would certainly be nice if the “actioner” was notified about the problem too, right?

This is a recent problem for our analysts. Something goes sideways with a service call and the item they were working disappears. They look for it, then notify me, and I generally find it in my admin queue.

I’m betting they’d like some heads-up without the hassle.

In my solution, I’ve created a Process Data Field called “Actioner” to receive the identity of the person who submitted the form through the SmartForms Client Event. The SmartForm contains a hidden field to store the Fully-Qualified Name (FQN) of the current user. The SmartForm transfers that FQN value into the field in the submit button’s click event, and the field value gets sent back to the workflow process later in the lifecycle. The workflow process consumes the “Actioner” later on by rinsing the value through a standard AD User SmartObject and plugging the returned e-mail address into an alert message.

The code changes in the SmartForm were:

1. Add a hidden textbox to the View containing the “Submit” button; let’s call this “txtActioner.”

2. In the Rules for the same View, add a Transfer Data Event to the submit button’s click event handler; use the Context Browser to transfer the FQN of the Current User from the System Values folder into txtActioner. (I chose FQN for its flexibility — especially in case the business might desire to capture analysts’ names as an audit measure later.)

The code changes required in the workflow process were:

1. Create the “Actioner” Process Data Field

2. Modify the SmartForms Client Event to send data from the SmartForm back to the Process Instance (see the image below; “Task Update” is the name of the View).

If you plan to consume the FQN as an e-mail message addressee, then in the context browser of the E-mail Event, navigate to the AD Users SmartObject in the Environment Browser and select the GetUserDetails() method, then map your Actioner data field to the input.

 

Finally, make sure your SmartForms View is saved before you try to configure the workflow Process, and is checked in before you attempt to deploy the Process.

 

I’m going to make changes similar to these where a Client Event precedes an Activity in which error routing is a possibility. Good luck and reach out if you have any questions!