Alright then, let's see how concisely I can put this.
At its fundamental core a Workflow is just a sequence of tasks for users to do work, with some extra functionality thrown in. Windchil PDM-Link comes with several basic pre-built ones out of the box for Engineering Changes. Here's the OOTB Change Request for PDM 10.1 M040:
All of those items with a double-face icon (like Submit Change Request or Schedule CRB Review) is a work task that will be sent to a specified member of the Team a.k.a members list of the Change Request, which I'll explain further in a moment. Those tasks show up in a user's Home Page and can also send direct email notifications to the users when they get them, to the email address set directly into the user's account. There are also Conditional and Or statements that are possible, code scripts, routing choices...it's quite flexible and the interface to set them up is very similar to Microsoft Visio. The main thing is just figuring out what fundamental process (independent of the tool) you want to follow. The primary purpose of a workflow like the above is to define how an object "moves" through the system, i.e. through its Lifecycle States. A Workflow like the above will only be useful if you actually connect it to something, which I'll explain below.
I don't know how well the following was covered in your training so I'll just dive right in. There's a distinct sequence of steps/functions that happen whenever you create ANYTHING in a PDM system, and I do mean anything, and understanding this will definitely help you see where Workflows come in. You start with the OIR, or Object Initialization Rule. This is the starting blueprint for any object including Parts, Change Requests, etc...and there are two critical pieces of it that you have to pay attention to related to Workflows. The following is an example OIR for Change Requests from OOTB:
There's quite a bit more to it but that's kind of "extra fluff" that you don't really need to worry about starting out. There are two very key aspects shown above that you DO need to pay attention to; those lines for lifecycle.id and teamTemplate.id, which are Change Request Life Cycle and Change Request Team respectively.
First, the Lifecycle Template, which was shown above as the Change Request Life Cycle. This is kind of the "backbone" of an object which defines what States it can be in (like Open, Under Review, Accepted, Rejected, etc)...and it is also where you connect a Workflow to an object. You basically have two options, a Workflow-Controlled object like a Change Request by default, or a Non-Workflow Controlled object like a Part by default. Here's the OOTB Change Request Lifecycle:
A brand new object always starts at the very leftmost State, Open in this case. You can have a Basic template or an Advanced template, the only real difference being whether or not you have Workflows linked to it. For a Basic one with no connected workflow your only option for "moving" the item through the system through its States are through basic functions and trigger signals which is that list of 9 options on the left. Think of each Transition option as a flare shot from a flaregun of a unique color. The Change Request will constantly be looking for the signals, and when it sees one it will instantly try to move according to what instructions it has been given for a flare of that color. The options of Set State and Revise are fundamental functions found in the Actions menu of most objects, with Set State letting you "hard-kick" an object to a different State and Revise ideally only having one Destination state. Change is a specific code mini-script built into a Change Task or Change Notice. Refine is another one that doesn't by default come in anything but you can use it. You pick the allowed transitions for every state by filling the checkbox of where you want the part to go (in the example above, if the Change Request sees the Promote signal it will stay at Open. Nothing else is defined). KEY NOTE: If an object sees a trigger signal that it does NOT have a definition for it will generate an error. If this object is linked to a Workflow the entire workflow freezes and errors out. ANOTHER KEY NOTE: If an object is connected to a workflow and that workflow has a Set State robot in it that tries to set the object to a State its Lifecycle Template does not have, it will also error out and freeze. When you're in the setup function of the Set State robot it does not go hunting through the system looking for Lifecycle Templates that the workflow is connected to in order to find valid state values, it will show the list of every defined State you have in the entire system so make sure to pick ones you have defined for use in the object's Lifecycle Template.
Now, to actually get a Workflow connected to something you have to set it to an Advanced one, and switch to the Workflow tab of the starting State:
What this means is, whenever any Change Request including newly created ones go into the Open state (which new ones start at) the CR will grab a snapshot copy of the Change Request Workflow, attach it to itself and turn it on, which would immediately start pinging out assignments. You would then likely have the Workflow via set-state robots move it through its States, and you have a lot more control. KEY NOTE: Do NOT have your workflow put the CR (or relevant object) into a State that has a connected Workflow several times. EVERY SINGLE TIME the CR goes into that State with a connected Workflow it will grab a fresh snapshot copy of the workflow and turn it on, WITHOUT terminating any others, so you will end up with multiple simultaneous workflows working on the CR sending out assignments, attempting to change the State of the CR, etc....it's a complete mess.
If you do use an Advanced Lifecycle with a connected Workflow there is one more key piece, the Team Template which was listed in the OIR above which was Change Request Team. You get to these via Org or Site/Utilities/Team Administration. Here's our Change Request one (this is not OOTB):
The roles for the actual team are in the Selected Roles list on the right. PDM-Link is designed to have multiple Contexts, i.e. primary product folders, with independent user teams meant to manage that data. For example, in an automotive company you may have one team do the electronics, another do the injectors, another the fuel tank, etc...specialists in each field so they should focus on those designs, and therefore the context Teams will have different members. When a Change Request is created, what it will do is look at the Team Template above, look at the host Context it was created in, grab everyone listed in the roles of the Template from the host context Team matching roles and attach that copy to itself. Normally every User Task in the Workflow is set to a Role, and as long as you have made sure that Role is on the team Template so it gets automatically filled at the start by the correct person it will send the task to that person (or persons if you have several). Note, the Workflow and Team are independent snapshot-copies of the originals. If you update the Workflow code while the CR is running it will not see the update unless you reset it (usually by a Reassign LifeCycle function and selecting it to go to the initial State. This does terminate the current active Workflow so you don't get multiple running copies). If you change the membership of the host Context Team the CR will still be working off of its copy taken at creation and won't see the change, and KEY NOTE: If you have been defining access rules via the Policy Administrator based on context roles, being in one of the role copies on a CR team does NOT grant the same access at all. So if you remove a member completely from a host context but they are still on the team snapshot copy of the CR, when their role is called and they get the assignment they likely won't have access to the task. If this happens they often will see (Secured information) for the task name and host context. You either have to get them back into the host context team in an appropriate role or reassign their task to someone else who is in the context team.
Now, in general for the OOTB objects and workflows:
- A Problem Report is an optional initial process object with a workflow connected to it which can be raised on a part. This is meant to be a quick gut check/notification of a problem which can be terminated quickly if the idea is a bad one. No real in-depth work has been done yet nor any major resources spent.
- A Change Request, which can be immediately started from an approved Problem Report, is meant to be a cross-functional in-depth impact assessment of a change, mainly meant to answer the question "Should we do this change, yes or no?". Again, before any major work/resources have been done/spent on modifying designs you can see if it's a good idea. For example, if a change to an assembly will make it 5% more efficient but double the production cost that might be something you want to halt early before too much has been spent. These are frequently team-reviewed (OOTB by the role Change Review Board) and then a final approver gives the Yes or No answer. If it is a Yes:
- A Change Notice is started from a Change Request, though there is an option in the system Preferences to allow CNs to be created without a CR. This is the central "collection hub" of the actual work tasks to put a proposed change in place, as well as an initial cross-functional planning meeting (OOTB by the role Change Implementation Board) designed to answer "How do we implement this change, both in the database and physically?". By itself the CN does virtually nothing, but you always connect to it at least one:
- Change Task. This is a direct work package for an assignee, with reviewers. KEY NOTE: Out of the box, a Change Task is the only thing in the system with the key Change trigger signal (i.e. flaregun) meant to release Parts and corresponding CAD data.
In the end you have to consider how stuff will move through the system. Without a connected Workflow an object (like a part) will not "move" through the system through its States without either manually-triggered functions (and you can very directly control the access to those functions via the Policy Administrator, user Profiles and the Configure Actions for Role function in Contexts) or it has to be connected to a Change Task that has the key trigger signals built in to send to it if it passes reviews. This is coupled with the aspect that normally people train their Operations groups to NOT use file and part data that isn't at a fully released State. So, plan it out: How will the data that your Operations group needs to build product get created, reviewed and properly released?
That's basically it with all the main connecting pieces. Sorry if this seems a bit much but I always try to show all the details. Did that give you all the answers you were looking for?
