Skip to main content
L
lgrant16-Pearl
16-Pearl
January 22, 2026
Question

What are you using for Administrative Type Changes (iteration at end state)?

  • January 22, 2026
  • 2 replies
  • 246 views

Version: Windchill 13.1

 

Use Case: An identified administrative correction is needed (non form/fit/function) within the business confines of what is allowable. System needs to all an iteration of an object at its current end state.


Description:

What are other using for this situation?

I have seen a few ways to do this from using a CR or a Peer Review or just a workflow on a document.

In short, what I am looking at is a simple process with a few system checks at the start to make sure the proposed admin change is within the company business rules.  We have the workflow iterate the object and then when it moves forward we flip the lifecycle to a Single State lifecycle. That has an ad hoc permission for the assignee to modify at that state. At that step we add a comment to be displayed in the history table of the object. Once the task is completed we flap back to the Lifecycle called on the OIR and set the state back to the same state it was submitted.

What we want to avoid is publishing to downstream systems (LMS, MES, ERP), we want to keep the DMR rev history unchanged. Maturity on the NHA will display the same BOM configuration.

 

 

lgrant_0-1769092323401.png

 

    2 replies

    avillanueva
    23-Emerald I
    avillanueva23-Emerald I
    23-Emerald I
    January 22, 2026

    For us, in these limited cases, its a just do it. We have a group of admins with some elevated rights to handle this. I like the formality of your proposal that you put in gates and checks and rights are only granted when needed. I do not think it needs to be as complex to change the entire but I see why you are doing this, so that you can grant rights to that state and its not part of the normal business flow. This avoids adding it to the base default lifecycle and having to refresh all objects to the latest version. 

    What you might consider is adding this as an action to the drop down so that it can be triggered by users. UI can collect the data and kicked off the workflow. You might also want to consider adding the ability for a collection of objects or a way to update the collection in the workflow loop. You may find while someone wanted to update one thing, you need to update others to keep in sync like WTParts and Drawings. 

    joe_morton
    18-Opal
    joe_morton18-Opal
    18-Opal
    January 22, 2026

    I agree, this is an elegant solution. Thanks for sharing!

     

    For us, we have admins (such as myself). If a user needs something done out of the normal business workflow, they can enter a request in a separate system outside of Windchill. An admin can then either make the necessary updates directly, or set the required object(s) to an editable state for the user to update. If the admin makes the change, we'll record the other system's request number in the comments. Typical users wouldn't enter any comments. Your solution is much better for traceability.

    L
    lgrant16-PearlAuthor
    16-Pearl
    January 22, 2026

    To add to this, currently I am with a medical device manufacturer and so we need to have a clear history of all changes. We should not have an admin group that just makes changes and perhaps add a comment at check in. We need a change object (whatever that is) that has a description, justification, attachments (red lines, annotations etc.) with some review/approval record.

     

      Terms & ConditionsCookie settingsAccessibility statement