Need help with Code. Set Affected Objects on the CR from IN WORK to Under Review

Forum|Forum|24 days ago
March 13, 2026
2 replies
245 views

Version: Windchill 12.1

Use Case: Creating a demo workflow to show users that Revised items can be set from IN WORK to UNDER REVIEW at the start of the Change Request workflow.

Description:

Help please.

Note a code guy.

Just need a workflow robot to change the state of the Affected Objects on the CR that are IN WORK to UNDER REVIEW.

We need the proposed changes to be locked so they cannot be edited while the Approval phase is happening on the CR.

Some of the replies to this topic were published during the recent read-only period. We have manually republished the missing posts to preserve the integrity of the topic. Learn more.

April 3, 2026

The Community team

Bus_System Administration

avillanueva

23-Emerald I

Any reason you are changing states on the Change Request workflow? This is not standard practice to make state changes on items there. It should be further down the line in the Change Notice or Change task. There is example code in com.ptc.windchill.pdmlink.change.server.impl.WorkflowProcessHelper. That is where the OOTB workflow code is managed.

This is very old code but we used to see calls to methods like this: WorkflowProcessHelper.setChangeablesLCState((wt.change2.WTChangeOrder2)primaryBusinessObject,"UNDERREVIEW");

Normally the PBO was assumed to be a CN and it impacted resulting items, not affected items.

L

lgrant

Author

16-Pearl

Thanks, it's been a while since I worked on a workflow so little out of my lane.

I just need (I think) a "Execute Expression" to be placed into the workflow so that I can drop that code you sent.

I may just have my audience just pretend the affected objects are set to Under Review and cannot be edited.

avillanueva

23-Emerald I

Before deploying @Fadel good suggestion, strongly suggest you talk with your clients about NOT changing states of items during the CR workflow. If you have a released object and you add it to this CR, it's state would be altered and it shouldn't. It should remain released. The future item (newly revised item) is what would be changing state and where changes would be seen. That should be done on the CN workflow to resulting items.

Fadel

23-Emerald I

Use below code as pattern in a expression robot ,it has been tested minimally and its only for wtparts :

wt.change2.WTChangeRequest2 cr = (wt.change2.WTChangeRequest2)primaryBusinessObject;
try
{ 

wt.fc.QueryResult changeableObjectList = wt.change2.ChangeHelper2.service.getChangeables(cr ,false);
 wt.change2.Changeable2 changeable2 = null;
while(changeableObjectList.hasMoreElements()) {
 wt.fc.WTObject obj =(wt.fc.WTObject) changeableObjectList.nextElement();
 wt.change2.RelevantRequestData2 relReqData2 = null;
 if(obj instanceof wt.change2.RelevantRequestData2) {
 relReqData2 = ( wt.change2.RelevantRequestData2)obj;
 wt.change2.Changeable2 ca = relReqData2.getChangeable2();
 wt.part.WTPart cap= (wt.part.WTPart) ca;
 wt.part.WTPart part = (wt.part.WTPart) wt.lifecycle.LifeCycleHelper.service.setLifeCycleState(cap , wt.lifecycle.State.UNDERREVIEW);
 part = (wt.part.WTPart) wt.fc.PersistenceHelper.manager.refresh(part); 


 }
} 


}
catch( Exception wte )
{
 wte.printStackTrace();
}

Buiꓘa

L

lgrant

Author

16-Pearl

Thanks for your help. I will test today.

Back to the why. This is Medical Device.

Currently, the company has a technical review outside of Windchill and the assumption is that the change will be made, they only uses the CN for all change activity. The items are revised in one of many change tasks. Since they do not use the CR, the proposed change (red-line attachments) is approved in the CN task and then again post revision. They also send the parts to ERP after the revise action with a future effective date. The next step is validation and that can fail. There is a second phase of CT's that are used to create downstream activities. At the very end of the CN workflow is a resend to ERP with resolve date.

The result is an overloaded CN process with a disconnect between the redl-ine and the resulting change. They also need to use custom code to create an approval team for the CT's.

What I am proposing is using the Problem Report/Peer review as the technical review (can it be done) then the CR to review the actual next revision (should it be done) and then the CN for Implementation tasks (when should it be done). Currently the users are not able to Revise outside of the CN and I am proposing that they can revise outside the change process (Released to IN Work) to allow for collaboration and technical review before formal review. Since they would be submitting the In Work into the CR for CCB approval of the proposed change, that version needs to be locked from edits during the review phase.

There will be some situations where the Revision could happen in the CN (not taking away that ability). for large changes (100 parts, and Spec doc's, CAD etc) it is difficult to associate the proposed change (red line in attachments) to the object being changed.

My goal is to review/rework/approve within the CR. It is a large impact to the company the further along in the change that a correction is needed or cancelled.

Windchill, as far as I know, does not provide a good way to assure users that a red-line will be exactingly the resulting change. If the red-line for a word doc (track changes) is used, the users still needs to check-out/check-in or replace content and that would next iteration would need to be confirmed. Annotations can be used for CAD but still the model/assembly would need to be updated post approval.

It is also my experience that the CR is a lot easier to understand for most users without all the navigation steps on the CN. Currently the CN is even more complicated with a long list of Implementation Task templates to manage all the different Change Tasks that are needed and a clever but complicated custom code change team builder for the CT.

1_Change-process.pdf