I'm trying to understand how a change notice could be used in place of a promotion request.
point 1: Think you have to use Change activities and plan cause you can not link directly Business Objects to the Change Notice in order to apply actions through the workflow ... or may be investigate to the new Change configurable links.
point 2: there's no target state in Change Mgmt. It is more drived with transitions of related Business Objects lifecycles , or even you can implement in your own workflow your own logic. So you can mix in one Change Notice , business objects in different lifecyclestate and "promote" them to different target states...
Point 3: Roles are more driven by the Change Notice team roles and/or Container team Roles.
OOTB , roles are Change Admin I and Change Admin II, etc ...
but depending of your implemented workflow , you can imagine whatever you need....
Simple observers for mail distribution, or even more than one approvers with different branching depending of the Change complexity ...
Some comments to @GregoryPERASSO's list
Point 2 - You can have selectable Target States in Change Tasks. These were first supported in 10.1 M010. I am attaching an example video (Note - the video is a clip from a larger demo - but one can see the Release Target selection). These are more flexible then promotion request as they can have different targets for different objects. Even the OOTB transition targets can have different targets for the release of a CT.
Point 3 - The roles in a CT workflow can be determined based upon the role and resource pool mapping for the CT - no necessarily by the CN. In 10.2 M030 we additionally added ability to have Resource Pool mapping all the way down to the Context team Role - not just the context team providing some good granularity
You can investigate "embedded change task" if you're just starting out. It could be a good solution for light-weight changes/releases. Reduces the complexity of the "data model" for the end user. Makes it seem "simpler" for them if you're just getting started using Change Objects. But, of course, you can go the opposite way too. You could have multiple Change Tasks related to your Change Notice. It all depends on your business configuration.
The "promotion" happens by the Change Notice expression robot in the workflow running the:
That command will change the state of the objects as you have defined in the lifecycle.
We personally use 1 CT per 1 CN. And I wish I turned on the option for embedded change task. We might still take a look at that in the future. The only thing the CT workflow does is sync on the CN workflow and sets the state of the CT as the CN progresses. All of the user tasks are handles in the CN workflow.
Additionally, we resolve roles/team members from a team template that is chosen during CN creation. However, most companies map them in from the context that the CN object is created in.
@BenPerry I am curious. I suppose if we set the preference to "Embedded Change Task" that is for all ECNs created after the change of preference? I used this at another company, but it seemed some in the same organization created individual implementation plans/tasks also.
Yes - I think this is more of a preference for how data is displayed as opposed to actual functionality.
If I set the embedded change task preference to YES, then I can see Affected Objects and Resulting Objects directly from the Change Notice for all existing CNs and all future CNs ... with one caveat. The Change Notice must have 1 CT.
If I go back and look at a CN that was created a long time ago that has 2 CTs, then the preference doesn't work. It reverts to previous functionality for that CN. It also doesn't prevent me from creating a CN with multiple CTs. And if I do create CN with multiple CTs, it will display them all individually instead of showing the Affected/Resulting objects tables directly on the CN information page.
Either way, when creating a new CN, there is still a step in the wizard for the CT. So I guess I should retract my previous statement. This preference doesn't really fully resolve the more complex data model.
@BenPerry The preference explicitly only supports embedded CT when there is only 1 CT. Starting with 11.0 M010 and the configurable relationships one can now define a CN type where there is 1 and only 1 CT allowed which would make having a light weight CN straightforward.
@JeffZemsky So with 11.1, we can configure ECN's to have multiple Change Tasks, and others with an Embedded Change Task? I'm wanting to be certain I understand what you are saying.
@JHall Typo corrected - meant 11.0 M010
Good question Jim - if you set the Embedded CT preference it would be in place for all CN types. However once any CN has more then 1 CT it is ignored. What this would enable is a CN type - call it Simple CN where you are only allowed to create 1 CT. This would force this CN type to ALWAYS use the Embedded CT preference.
@JeffZemsky That's really interesting.
I wonder if the Embedded Change Task preference were in place, but other ECN templates were available, you could easily create the simple ECN, but also have the more complex ECN's readily available?
Could it be the best of both worlds?
Windchill 11.0 M030
WGM 11.0 M030
Inventor Pro 2017
Two major, major downsides of using CN + CT instead of promotion continue to be:
- User confusion: two objects, with two workflow processes, with two teams
- OTB, cannot create CT without having assigned people to "do the work" (Assignee and Reviewer)
Some commencts on @MikeLockwood's reply
A - There actually need to be two workflows or teams. The work could all be done from the CN workflow as well as controlling the CT state and the release of the data just using the CT as a container. The CT would still have a team, but would only be needed for access control purposes.
B - The assignee and reviewer can be setup based upon resource pool definition starting with 10.2 M030 - use the Multiple assignee and reviewer option to allow these (even if only assigning one user for each). That is assuming one is going to use the CT workflow.
Again - these are not hard rules - just several ways it can be configured based upon needs
Side question about embedded change task.
When customer chooses this preference, the Change Notice information page displays the Affected Objects table, and Resulting Objects table in lieu of the Implementation Plan table.
However, for native task form templates (where CN is the PBO), we cannot achieve the same functionality for workflow tasks from the CN. It would be nice to be able to close that gap and provide consistent UX. I'm seeing this in 10.2 M030. Have those tables been made available for native task form templates (when CN is the PBO) in later versions of Windchill? Or are they still missing?
You can reference case C13281629.