How can I expand the Promotion Request?

[pkuhnt]

Hello togehter,

I a newbee here in the forum and in the work as an admin for the database. We just launched a Windchill 11 System early this year in our R&D-department.

Atm i´m working on the "Promotion Request Approval Process" and i hope you can help me.

I try to expand the workflow so that the old versions of an objekt will be set in the lifecycle "old" in the end of the process. But i can´t even find the tasks/actions in the process where the lifecycle is set on "released".

I hope i explaind my request good enough and you can help me with some advice or an link, if there is an solution all ready.

sincerely

Philipp

[JeffZemsky]

Not sure I understand your use case here.

Promotion Requests work on Versions.  There is no concept of Affected and Resulting as in on a change where one might have Revision A as Affected and Revision B as Resulting.

In a Promotion Request you have version of a Part A.1, A.2, A.3 and A.4  if you have version A.4 on the Promotion Request what is the use case to change the lifecycle state of older versions?  In most cases you would be using a config spec of Latest, Latest with State, Promotion Request,etc. which would not consider these older versions.

Even in a Change with Affected/Resulting with good Config mgmt practice it would not be recommended to change the state of prior Revision eg its still Released, just not the latest Revision and should still be compatible if you are using good Configuration Management practices.

[pkuhnt]

Hey Jeff,

first thanks for the quick answer.

I think you got my point right and maybe im wrong with my logic, but if we have a version A.3 ind LCS "released" and A.4 in "worked on". Now we want to release the A.4 version for the production. Shouldn´t be A.3 in the lcs "out dated" or "run-out" ?

So if i understood you right we should cosider an other workflow for chaning older versions lcs?

Have a nice weekend.

Philipp

[JeffZemsky]

@pkuhnt if A.3 is "Released" good config mgmt would be to revise it to B.1 before doing work.  Of course there are exceptions where you need to make administrative fixes to A.3 to create an A.4 but that would be an exception case.

In this situation Config spec such as Latest or Effectivity will consider A.4 not A.3 in the process so there is really no need to update the state on A.3.

[MikeLockwood]

Hi Phillipp, Just adding my two cents that what Jeff says is very important - and worth all needed effort in planning your system.

[pkuhnt]

Hey Jeff,

sorry for my late reply, i was ill.

I think we spoke about diffrent case, because of the problem with the definitions of version & reversion.

We don´t use A & B in our company...

The Situation I mean is exactly your example. We have an objekt in A.3 "released" and we do a change on it, aitomatically it goes on B.1 "In-Work". Now we want to change teh LCS of B1 in "released" and equal to this A.3 should go in "old".

Thanks for your time.