Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X
Running into challenges with OOTB Change Mmanagement Workflow...
I'll use a PDM-Link/MPM-Link example to illustrate;
cleanest approach would be for a Change Notice Implementation Plan to be made up of two Change Tasks, one to modify the eBOM (Design) and one to modify the mBOM. Problem is... it's OK for both to get delivered at the same time (concurrent, collaborative, shorten developmenttimelines yep, got it) but by rights theeBOM should be "Released" before the Manufacturing Engineers sign off on the mBOM. OOTB Workflow executes the Change Transition forthe resulting objects in all Change Tasks (wtChangeActivity2)via 2 Workflow Robots(synch on CA complete and setpromotables)
Tech support solution is separate Change Notices, but I've got to believe there's a better way without breaking the bank.
I can see that it's easy enough to soft type the Change Task (Design type, Manufacturing type, etc.) but then you'd need same-but-different robots tocall same-but-different Java methods (and pass the type).
Has anyone run into this? How has this been addressed?
Is there any way to see what the code for an existing Java Class (Method) looks like?
Many Thanks!