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

Question

Question

Best practices for how to move between Workflow and Forms multiple times throughout a process?

asked on September 8, 2016

My goal is to use Forms as a "front end" for a workflow, because the user interface is so much more straight forward than having end-users enter metadata in Laserfiche. I am really just looking for advice on what the best practices are when doing this, to keep the Workflow and Forms processes as clean and maintainable as possible. There doesn't seem to be a lot of options for having the two interact, so my current method is sort of... messy.

 

Anytime there is a step in a workflow where a user needs to enter metadata for a Laserfiche document, there is a Forms process with a form containing the fields that need to be entered. When this form is submitted, it saves a metadata-only file to a specific folder in Laserfiche, which the Workflow is waiting for. It then pulls the metadata from that and uses it to fill the fields on the Laserfiche document that the workflow was started with. It works, it's just cumbersome and as far as I can tell, requires a separate Forms process for each step that I want to be completed with Forms.

Any general advice for moving between the two would be appreciated.

1 0

Answer

SELECTED ANSWER
replied on September 8, 2016 Show version history

I have version 9.2, and I can tell you that this gets much easier with version 10.1, which we just got on our Test Environment. The communication between Workflow and Forms becomes more of a two-way street. What I do with version 9.2 is to use the SQL Database as the middle man. I have forms processes that split up into different sections in some cases, activate workflows as they drop in the repository and their variables are accessible through the Retrieve LF Forms activities. Then when I have modified variables via workflow I can update the database, and have the next form in the process (or the same form in another step of the forms process) be populated via a lookup to that database. You can use the 'Update Data' or 'Insert Data' activities in workflow to update values, etc. Each version of the form that is loaded will pull the latest values, so that helps keep the communication going with WF and Forms. If you do get version 10, you won't need this...you can access variables from Forms in WF, and then send them back to a Forms process right from the Workflow itself while it's running. Pretty cool stuff.

0 0
replied on September 9, 2016

We do actually have WF 10. My issue with using the retrieve and set business process variables activities was a lack of a way to make WF or Forms wait for one another. But I guess that's not really much of a problem if you just make separate workflows for each workflow step, that a completed form can initiate. 

0 0
replied on September 9, 2016

One thing you can do is put a step in right after you submit a form and call the workflow from the Forms process model with the Workflow Service Task.  This way you can check the box to 'Wait until Workflow is finished' before proceeding, sometimes that helps.  What I do for example with the New Hire process I have in forms is to start with a submission form, split it into 8 different forms for various sections in the business, and as they are submitted they drop values into the repository...certain sections will kick off a workflow, and then when all the forms are submitted I have a workflow gather all the variables and send them back to the database for a final lookup by forms in a "verification form", which then will have all the sections on the final form for review.  I know it's still not ideal, but you can use those workflow calls from Forms to make the process wait when you need it to, and you can put activities in your workflows to make the workflows pause until another submission comes in from Forms by having it go to a specific folder and have a wait condition for it.  I'm sure there are other ways, hope this helps a little.

0 0

Replies

replied on September 8, 2016
I have version 9.2, and I can tell you that this gets much easier with version 10.1, which we just got on our Test Environment. The communication between Workflow and Forms becomes more of a two-way street. What I do with version 9.2 is to use the SQL Database as the middle man. I have forms processes that split up into different sections in some cases, activate workflows as they drop in the repository and their variables are accessible through the Retrieve LF Forms activities. Then when I have modified variables via workflow I can update the database, and have the next form in the process (or the same form in another step of the forms process) be populated via a lookup to that database. You can use the 'Update Data' or 'Insert Data' activities in workflow to update values, etc. Each version of the form that is loaded will pull the latest values, so that helps keep the communication going with WF and Forms. If you do get version 10, you won't need this...you can access variables from Forms in WF, and then send them back to a Forms process right from the Workflow itself while it's running. Pretty cool stuff.
0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.