Promotion Process/Request in Windchill 9.0 and 9.1

[cc-2]

Hello

we have tried to switch our promotion process for a particular context 6 months ago with 9.0M050,

We added in the domain policy the necessary objects, added username in roles etc..

A user can now create a promotion request but once created, the promotion approver never receives a notification and it is not listed in his/her assigments list. When looked at the object, one can see the promotion request as related object but even the promotion approver cannot edit it, approve or reject. There are things missing.

PTC told us it was a bug, actually they said there is a SPR (forgot the number) but it is the same thing. We were under the impression that it would be fixed in 9.1. We have updated our system 2 weeks ago and are now using 9.1M050 but the same issue still exist and PTC confirms there is a SPR:

I am really puzzled at the situation. Promotion Process is part of the basic workflow of PLM system. This is out of the box functionality. It is hard to believe that this simple task. Create a request for promotion, direct it to the approver and the approver accept or reject it (I used it in PDMLink 8), cannot work in 9. 9.0M050 is about 2 years old and PTC still have not solved that issue.

I have accepted them if we were the only company who wanted to use it !!! They did not like the joke.

If you have 9.0 or 9.1 Do you use promotion request in your company. If so, how did you make it work ?

Any feedback welcome

Thanks

PS: If they can't make a process so simple work, I wonder what we are going to find when we start using the Change Management Process with its 3 level admins

[cc-2]

the SPR is 1980693

[mitch.tolson]

It sounds as thought this is a policy/access control issue, or rather a lack of access control configuration.

Remember that with the promotion request there are two sets of objects in play, the primary business object (the object which you are promoting) and the newly generated promotion request object itself.

In order for assignees to receive tasks, the system needs to know who they are for each activity. With that said, start by investigating the OIR’s setup at your primary business object’s container (likely the product or library). Specifically, look at the lifecycles and team templates for both the promotion request object and the primary business object (be that EPM Documents etc).

Also, look at the promotion request itself in the process manager. Click on the activity in question and it’ll list who should be receiving the activity. I presume either the role or participant is blank. If it’s the role, no roles have been defined for that activity. If the participant section is blank, it’s likely the team template used (and defined in the OIR) is not linking the role to the participant.

At a high level, I’ve configured the custom promotion process, for my company, to have the roles called at each activity within the promotion request WF (no participant, team etc is called at the activity). A general shared team is defined at the org level for EPM Document Promotion in which the promotion request object’s OIRs, at the container level, looks to. Each container’s team has the roles to participant mapping. This allows for a “floating common process” across several containers and libraries, where the participants differ for a given role. There are definitely many ways to accomplish this, I hope this helps and can give you some starting points.

Mitch Tolson

PLM Supervisor – Dynacraft, PACCAR Inc

-

206-999-9226

[cc-2]

OK thanks,

we will look at those points.

Best regards

[cc-2]

Hello

Despite the SPR 1980693, our problem resided in wfprocess object which can be found in wfexecutionobject.

We set it to All states for Members with permissions, Read, Download, Modify, Create.

This is in addition to the Promotionnotice object which needs some settings.

It seems to work OK now.

Thank you all