K2 Five - Please share your experience

Pros:

• HTML5 Designer - It's much snappier, and works better across browsers.
• HTML5 View Flow - Finally not tied to IE11/Silverlight! Even legacy workflow view flow!
• Better Workspace - It's still not as flexible as I would like (particularly the Worklist... why still no field chooser?) but it's much better than 4.x.
• Split/Merge - This makes it so much easier to perform parallel tasks and proceed only when all (or some combination) are complete.
• Timers - These replace activity start rules, and it's really nice they pulled these out so you can use one Timer to control the start time of an arbitrary number of steps that follow instead of having to edit each individual start rule.
• Legacy/New Workflow Interoperability - This works pretty much flawlessly. You can call a new workflow from legacy via IPC, and you can call an old workflow from a new one via CallSubWorkflow. This makes it very easy to replace legacy workflows with new ones in a piecemeal fashion.
• Legacy API Consistency - The legacy APIs all work fine with new workflows, with the exception of Activities (see Activity removal con below).

Cons:

• Decisions - Theoretically a good idea to make workflows more like flow charts, but in practice they make View Flows much harder for layman users to read since the decision paths are completely separate from the Step that provides them. I much preferred line rules.
• Activity "removal" - Steps (events) are now king in new workflows. Some (few) steps can be stacked to make a pseudo-activity but it's very messy and what you can/can't stack seems arbitrary. Worse, activities are still there in the backend, you just can't change the names. If you use the API for things like custom worklists that show workflow state you will have to switch them to using Event names, and for co-existing with legacy workflows this may require a lot of event renaming to match activity names. They could have gotten around this by defaulting the activity name to be the name of the first/only Step, but instead they are just "Task 1", "Task 2", etc.
• New Workflows, View Flow - It's completely separate from the legacy view flow and it completely lacks any metadata. You cannot click on anything to get details about data field values, error/success, etc. All you get is the pretty pictures. This makes it currently super difficult to debug workflows, especially since:
• New Workflows, no Visual Studio integration - This means no code-behind, and no VS debugging. No server events whatsoever really, except you can fake one via smartobject steps that just pauses the step and waits for a ServerEvent.Finish API call.
• New Workflows, no Copy/Paste - This is a huge time waster. I'm sure they'll add it eventually but for now there is no way to duplicate Steps even within the same workflow, all must be configured from scratch.

In the end this release is mostly window dressing. It is very much full of front-end changes. Shockingly little has changed in the back end. Workflow processes are the exception, and even they are really mostly the same on the back end (as is easy to confirm via inspection by API, and opening up package archives). Overall I think it's definitely a step forward. I've started converting some of our workflows from legacy to the new format and the resulting workflows are cleaner in terms of logic (not so much in terms of visual layout). The new designer takes getting used to, but it is far more stable than the old one. It might behoove some people to wait for 5.1 assuming they add things like View Flow metadata and Workflow Copy/Paste but for a point-zero release it's pretty robust.

The upgrade was simple, no harder than a cumulative update and just took a little longer. I don't remember how long exactly but it couldn't have been too long as it didn't stand out in my mind. So far the only bug that affected us was that until FP6 workflow folders with periods in the name had the periods replaced with spaces when deploying the workflow. Fix packs have fixed other bugs but I hadn't really noticed any of them.

Interesting, I hadn't noticed the Activity Display Name field. We were using just Activity Name in 4.7. And now that I go back and look, it seems like one of the recent fix packs has also made Activity Name match Activity Display Name rather than just "Task 1" etc. All my newer ActivityInstanceDestinations are as I expect they should be. Scratch that one off the list then!