Great question!
In my experience this varies greatly based on company culture, Laserfiche administrator preferences, complexity of changes, and cost of failure. At the end of the day, when it comes time to make the leap from dev to production, it is just that, a leap. A thorough understanding of your environments and workflow is required to make it as calculated as possible.
A good exercise in promotions is to download Laserfiche's workflow templates. Install them into your dev environment, test them. Then move them into your production environment. These will show you the basic places to pay extra attention to when migrating.
*If your dev environment is it's own unique beast, migrating into a separate repository in dev, which mirrors production, would probably be a good step.
Major Changes/Rewrite of activities and design -or- dev environment is not a close mirror of production
- Disable production workflow
- Promote from dev the entire workflow
- Review each activity for pointers to development areas
- Enable (Denote version history encase you have to roll back)
*Risks: After promoting, may have to touch many activities completely unrelated to your change or feature just to ensure it migrates successfully.
Minor additions, changes, or tweaks to sequence of activities
- Denote modifications, ensure changes are accommodated in production (any new requirements for folders, metadata, security, etc)
- Open production workflow, make modifications within production workflow, re-publish
*Risks: May not catch all the activities needing to be changed to accommodate the new feature.
Additional options to add to either method
- a group or peer review before action is taken:
- to help catch other possible points of failure
- singular communication
- ensure a contingency plan is in place
- disable automations and manually trigger sections
- After making some updates, I like to ensure things work part by part so I'll disable the workflow from automatically firing and setup wait activities so I can watch in slow motion if everything is working fine, then manually nudge into the next part
- route all communications to yourself - temporarily
- I'll replace any to: cc: or bcc: communications to myself and put the final version in the comments, this is to protect against your workflow sending data you did not expect, at times you did not expect it. If everything works, I'll forward the email on to the official person and inform them them "this is the communication will come from workflow@wherever.com which will be automated the next time this is run, everything look ok?"
- export the xml file and run a search for development specific pointers
- ie: server names, development only accounts or metadata
- Make changes incrementally, verify each one works
- Treat the first time any workflow runs in production like removing the training wheels from your kid's bicycle!
*edited to add link to templates