You are viewing limited content. For full access, please sign in.

Question

Question

Update Form Variables While Assigned to A User/Team

Forms Workflow
Updated June 2, 2017
asked on May 30, 2017 • Show version history

I have a Forms process that shows the current status of a new employee, what additional forms they have not submitted, and when the last time they were reminded regarding their missing forms.  During a particular step where the process is assigned to HR I have a timer on the workflow that goes out and checks for changes in the new employee (status, submitted forms, ...), updates the variables in the form accordingly, and if it has been more than 24 hours, sends them a reminder to submit their missing forms.  

The process is working fine except that when workflow runs Retrieves the Form Content it gets the initial variables that were assigned when the form first came into the "In-Process On-Boarding" task and none of the updated ones.  If I look at the variables on the instance for the form right now here is what I see:

This includes the reminder it just sent today at 6:19 AM and shows that the variable for when they were last notified was also updated to 6:19 AM.  However when I look at the workflow when it runs again it shows neither of these and instead shows the initial variables.

Why would workflow pull different variables than Forms is showing as the current variables and instead pull variables from 5 days ago?

0 0

Replies

replied on May 31, 2017 • Show version history

As I look more into this, it appears that Workflow does not truly get passed the Submission ID of the activity that triggered it.  In the screenshot below you can see that the workflow is called by the "Check for Updates or Reminders" activity that has a Submission ID of 4561:

 

But in Workflow it shows it was started by Submission ID 4306:

 

Submission ID 4306 just happens to be the step before where the process last called Workflow and sent a Welcome Email:

 

Thus Workflow seems to be getting the variables passed to it from an old Submission instead of the actual Submission that is calling it.  I've tried setting the values in the Retrieve Form Content workflow activity for the Submission ID it uses to both "The most recent submission (when the workflow started)" and "The submission with ID: %(SubmissionID)" and they both come back the same.  

I am not sure if this is a bug or what but it appears so long as the Form is assigned to a user task, the Workflow activity will only pull the values associated with the last Submission ID before the User task.  I may have to query the database directly for the latest Submission ID for the Instance ID and then query it that way as the data Forms passes to Workflow does not seem to work for updating a form's variables that are in process.  Has anyone else had success in updating variables repeatedly via a timed workflow while a task is assigned to a user task?

0 0
View 2 previous replies
replied on May 31, 2017

Well, I found a work-around.  I ended up adding a Custom Query activity at the start that found the latest Submission ID for the Instance of the form:

 

I then used that Submission ID in the Retrieve Forms Content and it was able to pull back the latest variable values.  In the shot below you can see in red the Max Submission ID I got from the query and how using that pulled the latest Last Notified date/time and the list history that includes the reminder sent out at 7:18 AM.

 

This is dependent on the table names/design not changing between versions so I am hoping Laserfiche fixes this issue so a Form activity calling a Workflow actually passes it's Submission ID and not the last one before it was assigned to a User Task.  Hopefully this helps someone else who has this same need and has run into this issue.

2 0
replied on May 31, 2017

Can you open a support case with the Forms process and Worfklow (or a simplified version that reproduces the issue)? There's quite a bit of details we're probably not seeing in the screenshots above to try to reproduce the issue.

0 0
replied on June 1, 2017

Here is the simplified process without all the emails, approvals, and extra variables:

  1. Form submitted
  2. Form then flows to a Service Task that triggers a workflow to assign the current date/time to the Last Notified variable in the form
  3. Next it goes to a User Task that assigns it to a Team
  4. This User Task has a timer on it that runs every hour and when it runs it:
    1. Does not disrupt the User Task
    2. Triggers another Service Task that updates the Form variables
    3. Goes to an End Event

 

In this scenario, that hourly triggered workflow would use the Last Notified variable to see to if it has been more a day and if so it would update the Last Notified to the current date/time.

0 0
replied on June 1, 2017

I looked into it some more. Forms passes the "most recent submission ID" to Workflow as an input parameter when running the service tasks, Workflow doesn't look it up. This most recent submission ID is calculated from the perspective of the current location in the process. The timer and subsequent activities flow out of the user task and never back in, so their flow starts in the user task. That flow never comes back to the user task. Based on that, in the user task, the most recent submission is the one that came before the user task, hence the first service task submission ID.

Now, there is the matter of the form in the user task displaying the updated values from the second service task. That's inconsistent with the behavior described above for determining the latest submission data. One way to fix it would be to make it consistent, but that would prevent this type of process design. The other would be to change how we determine the context for the latest submission ID to make it work like you initially expected it to. Arguably, they could both work, but picking one or the other might break existing processes. So definitely a bug, but not an easy fix. (I don't have a bug reference for you just yet because I'm still trying to figure out what the best way to file it is. It will link to this thread, so Tech Support can still find it if you want to ask about its status later).

One thing you can do is instead of using a repeating timer on the user task, change the timer on the user task to a one-time timer. Then add another timer after the "Check for Updates and Reminders" service task. Connect this second timer to the gateway so it creates a loop flowing back into the gateway. That way, you still get the desired behavior (as long as the user task is still running, you get the periodic service task. However, this way, the context for calculating the latest submission ID changes to the most recent run of the service task, which will give you the expected submission ID. The user tasks still displays the latest data (due to the inconsistency mentioned above).

Hopefully all this made sense, let me know if it doesn't.

1 0
replied on June 2, 2017

That does make sense.  I am live with my SQL work-around but I will try your method on my next roll out of this process.  Thank you for looking into this and researching the best way to adapt to it as I don't want to break other methods that existing processes have come to rely on.  

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...