cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Propagate data from Change Notice to Change Activity

Propagate data from Change Notice to Change Activity

It seems the propagation functionality fell just a little short, data can be propagated from a Problem Report to a Change Request, and from a Change Request to a Change Notice, but not from a Change Notice to a Change Activity. Just take it one more step and allow the data to be propagated.

11 Comments
ybagul
1-Newbie

I would like to add one more thing.

There should be some configuration available for propagating soft attribute values on Problem Report, Change Request and Change Notice as well.

JørnAHansen
2-Guest

At first I thought: "Yes, wonderful, I'll vote for that ... "

but then thinking a bit more about it, I'm not so sure. Propagating the information, e.g. the Change Notice Description creates a copy of information. The question is then what happens if later on someone updates the CN description. Will people working "locally" on the Change Activity notice the update? Also depending on your process if you use several Change Activities in your Implementation Plan on the CN you will get even more copies.

At least for this scenario with the Description field I think adding an Alias Attribute on the Change Activity that is simply a lookup of the current up to date information on the CN is a better solution. I didn't think about this before I saw this post so Jonas Shawanesse‌ thanks for posting the Idea, I will explore a bit on the Alias Attribute idea now

Oliver Droop‌, Yogesh Bagul‌, Jonas Shawanesse‌ any further thoughts on the more specific scenarios you have in your business? I think to get PTC to implement something useful across customers we need to explore this a bit deeper.

OliverDroop
11-Garnet

Jonas,

can you elaborate a bit more which information you would like to propagate from the ECN.

Objects -> OOTB

IBAs -> to control e.g. Activity WF?

Name -> if propagated it should be for the first activity only and controled by a preference

The first activity is always related to the required engineering work and often the description would make sense. However it should be only pregenerated and overwritable. For additional activities these are often downstream and description/name should be different than the ECN itself.

ybagul
1-Newbie

I guess attributes with similar identifiers are candidates for propagation. After propagation, user can always modify values for attributes as it works today.

kpritchard
4-Participant

I'd definitely like to see the Default Change Task (Change Activity) Name Preference allow for the Change Notice Name to propagate rather than some dumb text like "Default Task".  There are generally quite a few single Task Changes that would be greatly simplified by this.  I have done this by workflow code (Get Change Activities, If Name = "Default Text" then get the name of the parent Change Notice and set Change Activity Name to this value).

The counter to this is the inherent laziness of the human species...  Problem Reports are Issue and Idea capture mechanism, Change Request is "should we do" and Change Notice/Change Tasks are the detailed "What/How we do".  When you get to the execution work package that is a Change Task and the Name and Description have propagated as-is from the Problem Report you have a problem because the text does not provide instruction or outline scope, just identifies an issue.

To be truly effective the information presented must evolve rather than merely propagate.   

JeffZemsky
17-Peridot

Not sure I understand what you want to propagate from the Change Notice itself?  The Changeables are captured at the Change Task already and you have quick access to the Change Notice from its given task.  If you want an attribute a better alternative might be to consider an alias attribute to display the information without having to re-created.

Keir - for your use case - the Change Task name should give the user some idea of the task.  Putting the CN name might not help that.  Again for this case you might consider adding an Alias attribute to show the CN Name at the Change Task level.

kpritchard
4-Participant

Use case is based on several thousand Change Notices, many with single Tasks and User feedback of frustration with needing to enter seemingly redundant information twice...  as in for a single Task Change what information would be different between the Change Notice and the Change Task?  Not worried about getting Notice information to display at the Task level, just wanting to streamline the single task change notice data entry.

When you have multiple Activities/Tasks within a Change Notice it makes sense that they would be different, and the Users do update the information that I have propagating via workflow code.  They do this generally by copying everything, trimming as needed and pasting into additional tasks and adjusting the information as they new Tasks created.

JeffZemsky
17-Peridot

Keir - for that need have you considered using Change Notice templates where you can prefill the Name field of the task with some information and the user will then only have to put in a little amount of detail?

BrianSullivan
5-Regular Member

Jeff,

Keir is very much correct.  We deal with smaller customers that almost always have One Change Task to One Change Notice.

The Entry for Change Notice "Name" and Change Task "Name" are identical.

Currently:

You can set the Default Change Task Name via the "Default Change Task Name" preference.  We set that for almost every Customer to something like: "Select the Edit Icon and change the Name"  The Preference should have an OPTION, which allows you to Select Change Notice Name by Default, whether you call that propagation or not.

A common Workaround would be to add Java Expression to start of Change Task Workflow to pull the Change Notice Name and Populate into Change Task Name Field.  I like the above comment... and may add check if User left Default Value then change to match CN Name....

But we should not have to do this.

This is just an annoyance, users can copy/paste, retype or if assigning the Change Task to themselves (Most common) leave the Default Name... but the reviewer downstream gets a name that is useless.

To Keir:  A Workaround we do a lot is to append the Change Notice Number into the Name of the Change Task as primarily the reviewer needs to close a Hot CN and needs to know the Task is related to which CN via the system generated Emails or on Home Page.Tasks list (Yes an alias Attribute could help on the Home Page but the Name/Subject is already There.)

kpritchard
4-Participant

Brian - workaround done was Java code similar to what you described... If Task Name == default text then set Task Name = Notice Name, otherwise leave as-is.

PTCModerator
Emeritus
Status changed to: Acknowledged