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 ...
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.
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)
@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.
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
Some commencts on @mlockwood-2'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