As I mentioned in the related post linked below, the overwrite feature in Forms 10.3+ is meant to be used with a test/dev Forms server. We use GUIDs for the process ID AND each element ID so we know which process you are trying to overwrite as well as any changes you made to each individual element. When you copy your process to create DEV - Process Name, the GUIDs are changed and the two processes cannot be used to overwrite each other.
Related post: https://answers.laserfiche.com/questions/156127/Copying-changes-from-one-process-to-another-process#156136
Some options:
- To answer your question, it is possible to open up the XML of the production process, find the GUIDs for the process ID and each element ID, and try to manually map them to the XML of the updated Dev process. To take this route one step further, you could try to write a script that takes in both XMLs and updates the Dev XML to use the production GUIDs, but you'd have to be very careful to map each element to the proper production GUID. I don't recommend this method.
- You could try to use copy and paste instead of overwrite. If you are making changes to one section of the process, you could make the changes to your Dev process, then copy those changes into the production process. This would allow you to make and test changes to the Dev process and bring them over to the production copy easily and with less room for error. Once you paste in the changes, you simply have to hook the updated section of the process in with the production process.
- The best solution would be to stand up a Dev Forms server, download processes from production into the dev server for testing, then upload the updated processes back into production. This will retain the GUIDs and allow the overwrite to happen as intended.
How overwrite works
For the most part, active instances will remain active and working even if the process gets updated underneath it. This is true whether you update the process by manually making changes and saving it, or overwriting it with another process. The behavior in regards to active instances is the same.
The biggest problem would be if you deleted a user task or other step where active instances were currently on. This may come up more often if you choose option 2 above with copy and paste. If you copy and paste a chunk of your dev process into the production process, it's more likely that you'll have to delete part of the production process to replace it with the new test process. Make sure not to delete anything from production that has active instances on that step.
Majority of these issues can be solved by good production update/overwriting practices. Instead of deleting the old pieces of the production process and replacing them with steps from the dev process, put both in the production process together for a short time.
For instance, consider a case where you have User Task A and you want to replace it with User Task B. Instead of deleting User Task A, adding User Task B, then overwriting the process, consider a different strategy. Add User Task B alongside User Task A. Then reroute the process so the incoming step now goes to User Task B instead of User Task A, but leave the outflow of User Task A connected to the next step. This way, all new instances will go to User Task B, but any active instances on User Task A will remain and can go to the next step without a problem. Once all active instances are off A and using B, you can clean up the process by deleting User Task A for good.
Use this iterative approach to updating processes and you should be able to make changes for all future instances while keeping any active instances healthy.