Showing results for 
Search instead for 
Did you mean: 

Release Status progression in workflows - TC 11.3


Hi Experts,


How do you implement/ recommend Release status progression in workflow templates i.e. how to append/replace/delete statuses.

I looked into following options


1.Use OOTB handlers in same workflow?

2. Create 0 step subprocess workflows to switch status

3. Write your own custom handler.


Let me write down challanges I faced with each option


1.  Use OOTB handlers in same workflow?

 with this approach we have two options


(i) Use EPM-create-status on start action of 'Status -Task' and append/replace


    If creating new status each time, in case of rejections there would be multiple instances of same release object on ROOT task; ex this is very simple scenario  (actual scenario includes multiple statuses and review tasks and branches)


Start -> assemble ->submit for review (gets IN-Review status) ->  Review task  -> if Ok, gets Approved status


                                                                                                              reject, goes back to assemble task


Now in above scenario in case of multiple rejections - There will be multiple In-review status objects linked to Root task


Behavior observed in TC11.3


first I have put EPM-set-status -action =delete // to delete exisitng statuses from target


If I use EPM-set-status -action = append -status=In-Review => this will append ALL instances of In-review to target

If I use EPM-set-status -action = replace -status=In-Review => this  will put first instance of IN-review instance on 

                     targets; thus execution time will not match with Released date and effectivity



Note-  EPM-set-status -action =delete only removes status from targets and does not delete releasestatus object from Root task.


(ii) Use EPM-create-status on start action of ''ROOT-TASK' and append/replace whereever needed later

To avoid mulitple instances of same release status object ; I tried creating only one instance of each release status object(I may need in the workflow) 


with this approch in TC 11.3 I observed a bug.

Example: Create In-review, Approved, Released => Three statuses on root task


As soon as you will assign any one status (say in-review) to targets - this date released and effectivity will be copied to rest of statuses also. Thus irrespective of execution time for other statuses Date released and effectivity will be same for all statuses/targets. 


Thus I ruled out approach #1.


2. Create 0 step subprocess workflows to switch status


This is how we have it currently in production


This gets too complex too manage


  • Too many associated workflows
  • Stuck workflows – sub-process gets stuck after process initiation and does not even start ( in a more complex scenario - real time observation)
  • Complex Audit Reports
  • Slow Impact Analysis tab etc

Thus we thought of going for Approach #3


3. Write custom handler to append/delete/replace


There is OOTB API only to ADD(append) release status but not to delete or replace.

Replace and delete are more complex scenarios as we may have to delete previous RELEASE STATUS object if the target it is being replaced/deleted from is the LAST object referencing it.

GTAC has also confirmed it to be a complex thing and our objective is not to write complex code and spend time and money in its testing and maintenance.

GTAC says there is existing ER already


When I approached GTAC for issues/bugs found with first two approaches they closed first one saying approach 2 as workaround and vice -versa but not comitting on issue reported.


I have provided simple (using OOTB handlers) workflow templates to GTAC for both the issues and they could replicate it.


This is a long post and I may have made typo errors; please excuse. I will go through it again and will correct if required.





Re: Release Status progression in workflows - TC 11.3

Solution Partner Phenom Solution Partner Phenom
Solution Partner Phenom

You may want to investigate handlers that come with PLM-Easy. Specifically, the TCPB_RH_checkStatus and TCPB_RH_checkObject. Both are quite useful but checkStatus directly addresses your scenarios. PLM-Easy is used mainly in Germany and I don't know if its available in the US but is worth checking into.


Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11 | SW 2016 | Creo 4 | TcUA 11.4
Evaluating: AW 3.4