Group,
I am looking for a collaborative discussion & maybe "best practice sharing".
I have been constantly working on Change Management workflow devleopment in my company for 2.5 years. I thought I made these workflow instructions look pretty slick with variables showing up here and there...HTML formatting...etc, etc. Finally a few months ago...I think I went overboard. I reached the 1333-character limit in the workflow Instructions, as outlined by CS61259. My rendered workflow assignment is shown in the screenshot below. Perhaps too much detail in the instructions that should be offloaded to separate training document?
What I'm looking for in this discussion are use cases of workflow assignment modifications & customizations. What are they? What have you done to render good-quality instructions for the users read & understand, and how?
Just looking to share experiences for some users to pick up on that other users haven't thought of before. And along the way, maybe some of you have thoughts about how I can clean up my own instructions so users don't have a book to read when they click into one of my workflow assignments. 
Note: Pictures are worth 1000 words. Posting pictures of the renedered task like I did below is great, if you can.
For the last 8 years or so, we have used embedded HTML in the workflow template task template instructions to include a GIF process map as well as scrollable work instructions. The GIF and work instructions live in the codebase, allowing us to have as many characters and images as we like. We can also change the instructions and images without having to restart the workflows.
Note how the base URL changes in the workflow Start transition allowing every server to get a unique server name without having to change the workflow code. The name of the server is saved in a preference or property of each system, but accessible by API to insert into the workflow as a variable for use in the task instructions.
Al Anderson
Solar Turbines Incorporated
One thing I have done here in Alcon to externalize instrutions into the XML files sitting in the codebase. This has worked very well for us. We do not have to through verification process because the workflow template is not changed. The instructions can be changed instantly and these changes are server independent.
Al, I like the idea of embedding the images for the process flow...That is my next thing to do 🙂
I removed out of the box tabs which we do not use here in Alcon..
We also put PBO number as first thing in the task name, which is the most useful thing I think for the users to sort their work. We also have link created which takes them PBO report about the change (View CR Report) and display description of the change for user convenience.
I thought of another idea to get around the 1333-character limit in the workflow task instructions (as outlined in CS61259).
If there is a group of common text that is displayed on all tasks, assign that text to a variable. Then in the instructions, call out the variable. I'm not sure how taxing this is on the system, but it is functional. A screenshot is included below. I also include the source code to populate {instructionFooter}. This can be put in an Execute Expression robot or somewhere in the workflow template.
instructionFooter = "<hr size=\"1\" width=\"100%\" color=\"#000\" noshade /><b>To view the ECO form, Affected & Resulting objects, routing history, Implementation Plan, and team:</b>\n" +
"- Click on the hyperlink above to the Change Notice information page.\n" +
"- On the Change Notice information page, select the <b>Enerpac ECO Information</b> tab.\n" +
" - The ECO form is in the <b>Attachments</b> table.\n" +
" - The Affected & Resulting objects are in the <b>Change Summary</b> table <i>(use the <b>Enerpac Default</b> table view)</i>.\n" +
" - The ECO routing history is in the <b>Tasks for Change Process</b> table.\n" +
" - The ECO team is in the <b>Members</b> table.";
We prefer to keep the task page clean and simple and have removed all instructions. Instead we have a "click here for instructions" hyperlink which takes the user to the relevant page in our Windchill User Wiki. I find it helpful not to hard code detailed instructions. That way we can offload the creation and continuous improvement of user documentation to non Windchill admins, and we don't need to role out new versions of the workflow just to make edits to instructions.
Similar story for workflow email notification.
Ok, still using 9.1 but will see if I need this in 10.x soon. This is to date my grand achievement. I needed a single workflow that can route a parallel task to an set of roles not known before the workflow started. I used a signoff task that contained 20 role variables as slots or placeholders for roles. A manager picks from a workflow task from a list of team templates (just sets of roles) from the Product context (I have documented this other places). The workflow then takes those roles and populates them into the 20 slots. The unused slots just deadend to the administrator since undefined. When the signoff task fires, it looks up those roles from the change object team and delivers the task to those users defined by those roles. I used to have to modify and create a special workflow for each area that had a different signoff team. Now I have one workflow for the entire system and each product can have more that one team to choose from.
Still with me? The conditional does some cleanup task based on behaviours out of the box. First, when the emails are sent out using role variables, it does not use the role variable value when telling the user what role they are participating as. I therefore do not let the signoff task email the user but rather have this conditional create email messages for them. The users does not see a difference. Second, the extra tasks that deadended to the adminstrator would clutter the assignments list. I found a way to delete those thereby having the task only wait for the actual signatures of the roles that were populated in the task.
If you have fought the workflow editor with branches and conditionals to fire tasks when certain conditions were right or had the user define each time who from the pool needed to sign, this solves all of that. Just a simple task with a drop down list, pick which team needs to sign, and that its. The task is delivered to only those roles and the people who fill those roles in the Product. Again, to date, my best work. And if you are wondering, it can be looped back through meaning that if it loops back, you can choose a different team and it operates the same as the first time.
