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

Question

Question

Updating Live Forms

asked on October 7, 2020 Show version history

This seems like a dumb question...

 

I have several live processes that are heavily used. When I need to make updates, I've been waiting for the weekend, unpublishing the process, making the changes, and then publishing again.

 

Clearly, it would be easier/better/more time efficient if I could make changes during regular working hours, especially since some take me several hours to complete.

 

I did see in another post that it's possible to download a process, make changes, then upload it again (overwriting the old copy so the changes are applied). We do have a development site that is used for new forms, but many of our live processes call multiple workflows that haven't been built in DEV (and just building those out would take a long time). So it hasn't made sense to use DEV to edit these processes that are already live (many were built before we even had a DEV site).

 

What I wondered...

In our live site, if I made a copy of a process, made changes to that copy, and then changed the names so that the copy with the changes ended up with the same name the live form had originally, would that work? These processes have hundreds of tasks in progress at any given time.

 

How do you handle this at your organization? Is there something obvious I'm missing?

Thanks in advance!

0 0

Answer

SELECTED ANSWER
replied on October 7, 2020

There are two cases here:

If you are trying to make changes to a form, one option would be to copy the form, make changes to the copy, then once you are ready, swap out the old form for the new form in the message start event or user task. Since the form is using the same variables, the data will load the same in the new form. 

If you are trying to make changes to the process, I would not recommend copying the process. Once you copy the process, it "disconnects" from the original and you won't be able to easily merge changes back in. I would recommend downloading the process and importing it into your dev server. Instead of rebuilding all your workflows, just create a workflow in dev with the same name, that just has a short delay, or set's business process variables with dummy test data. That way, the WFs do run in dev, but it just sends back some fake data so the process can continue. Once you make all the changes in your process, you can download it out of dev and overwrite your production process, which will keep the WF tasks tied to the production counterparts with the same name. 

4 0
replied on October 7, 2020 Show version history

I hadn't thought of creating "dummy" workflows to use in our processes on the DEV site, but I think that will be the best solution.

 

Thank you so much for taking the time to reply!

1 0

Replies

replied on October 8, 2020

Jared gave a great answer. Here's another approach that may be best in some circumstances. Once when I needed to make heavy changes to a working forms process, I copied the process on the production server, made the changes, and tested. Then when I was ready to implement the new process, I changed the starting URL on both processes so that when a user wanted to submit a starting form, they would find the start of the new process instead of the old.

2 0
replied on October 8, 2020

This method works as well, but does separate the data a bit. For reporting, you can always build a report with both processes and link the variables so they appear in unison, but for places like the Monitor page and Insights reports, you would be starting fresh with the copy. 

3 0
replied on October 8, 2020

This makes sense and is extremely helpful. I feel like I have a much better understanding of how things are connected now. Thank you!

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

Sign in to reply to this post.