& Construction

Integrated BIM tools, including Revit, AutoCAD, and Civil 3D
& Manufacturing

Professional CAD/CAM tools built on Inventor and AutoCAD
Integrated BIM tools, including Revit, AutoCAD, and Civil 3D
Professional CAD/CAM tools built on Inventor and AutoCAD
In this lesson, we’ll discuss how you can use a Change request workflow to obsolete an item. Since items cannot be deleted from Upchain, making an item obsolete effectively marks it as something not to be used anymore.
A Change request workflow is the only thing that can be used to obsolete an item in Upchain.
Note that an item must be in a development state to be made obsolete using a Change request workflow. If you require other items to be made obsolete, then you must reach out to Upchain support.
IMPORTANT: Consider whether this workflow is necessary at your organization and who should be involved in signing off on obsoleting items.
In this video, we’ll show you how to create a Change request workflow to obsolete an item.
Transcript
00:09
In this video, we'll show you how to create a change request workflow to obsolete an item.
00:15
Let's take a look.
00:20
Items generally exist in a state of development, meaning they can be viewed and worked on or released,
00:28
meaning they are read-only and assumed to be in a finished state.
00:38
No items can be deleted from Upchain, so that full traceability and history is always maintained.
00:46
However, they can be removed from any project they belong to, which effectively hides it from users on that project.
00:54
And if it is removed from all projects, that effectively hides it from most users.
01:04
In most cases, simply removing an item from a project is enough to hide it from most end users.
01:11
But what happens if someone accidentally revises a released item?
01:19
Remember that Upchain generally insists that you work with the latest version of items and the files inside them.
01:26
If a released item suddenly has a newer version, this new version might start popping up in places it's not meant to.
01:37
For example, in the web application, you'll see a yellow warning symbol beside items that are no longer the latest version.
01:45
And when CAD users download something, they may see a warning indicating there is a newer file version in a newer item version.
01:55
So if this new version was created by accident, it likely isn't desirable to have it brought into a working cBOM or eBOM.
02:09
The obsolete status is a useful way to mark an item as not to be used, please ignore, no longer in use and so on.
02:19
It can also be used for items that need to be retired due to things such as industry standards having changed,
02:28
could be the suppliers have discontinued production of that particular item,
02:33
or perhaps even better designs have been determined at your organization.
02:39
Items that become obsolete stay in the bill of materials they were part of, and obsolete items can still be downloaded and viewed.
02:47
But by applying this status to an item, Upchain ignores it when looking for the latest version of an item.
02:56
Please note that Upchain can only turn an item that is in a development state to obsolete.
03:03
If an item is released, this cannot be made obsolete with the change request workflow.
03:08
If this is your situation, then you must reach out to Upchain support to obsolete your released items.
03:18
We'll create the new workflow from scratch to obsolete our items.
03:24
We'll name it "obsolete item", and it falls under the change request object.
03:39
Let's add in the start primitive, since that is required, and we'll update the start button text to say "send for obsolete".
03:50
And, of course, we need to stop primitive since that is also required.
03:57
Now, the key step that we need in this workflow is the update primitive.
04:03
This is the primitive that has the ability to change the item status to obsolete.
04:11
So let's configure that.
04:24
Of course, this is not enough for a complete workflow.
04:29
Like other change request workflows,
04:31
we should include another update primitive at the start to update the status of the change request to, in our case, pending approval.
04:49
We should also add another update primitive to update the status of the items temporarily to "Approval Pending".
05:04
This is so that no one can accidentally modify these items while it is part of a change request.
05:15
We'll also include a decision step so that the items cannot simply be made obsolete on a whim and must pass through another user's approval.
05:28
In this example, we'll set this decision as the generic decision task type.
05:38
We'll require both sets of comments.
05:44
The happy path will be to approve the request to "Obsolete", and the exception path will be the rejection path of the request.
05:55
We'll update the task description as well so the assignee is clear on what they are deciding.
06:14
We'll assign this to the project manager role since they should have complete oversight of the entire project.
06:23
We'll also allow workflow cancellation and send an email notification.
06:33
For our complete happy path, let's also include a final update primitive that will update the status of the change request accordingly.
06:49
In our case, we'll set it to "Completed", indicating that the items have been made obsolete and the workflow was successful.
07:01
Lastly, we'll connect the primitives together.
07:03
Again, we always start with a happy path by clicking from the start primitive to the destination primitive using the little square connector points.
07:15
The happy path is green.
07:17
And so if the project manager approves the decision, the workflow follows this happy path all the way to the end.
07:24
If they reject the decision to obsolete the item, let's simply return the items to a development state.
07:34
And we'll also mark the change request to canceled indicating that the request to be made obsolete was unsuccessful.
07:48
And we'll connect up the exception path.
07:55
So this is a nice simple workflow that involves one person to review the request to obsolete the items before the items are finally made obsolete.
08:08
Lastly, let's publish this workflow for our end users to use.
08:23
Now, let's test this workflow on an item.
08:27
We'll perform a search.
08:30
And here, you can see we've got two versions of this item, a released version and a newer version that was created by accident,
08:39
in our case, and is in a development state.
08:43
If we navigate to the released items project,
08:53
and look at it within the context of its bill of materials, you'll notice the yellow warning symbol indicating there is a newer item version.
09:01
In order to ensure the latest version is not accidentally brought into this bill of materials,
09:10
let's send this newer version to the obsolete workflow.
09:20
So we'll send the item to a change request.
09:27
We'll choose our published obsolete item workflow.
09:34
Like other change requests, the item does need a revision note, even though it's not being released or versioned up.
09:47
We'll save the changes and start the workflow.
09:57
You can see the button text that we configured is what appears on the button.
10:09
You can see that the item and the change request are both in a pending state.
10:15
And there are now two buttons available to the project manager to either approve this workflow and obsolete the item or reject it,
10:24
and this would cancel it outright.
10:27
We will click the "Obsolete Item" button, enter in an approval comment, since we also configured that requirement in our workflow.
10:57
And there you can see the item has now been made obsolete.
11:05
If we now look at the released item again, within the context of its project and bill of materials,
11:16
you can see it no longer shows a yellow warning symbol indicating there's something newer.
11:21
This is now the latest version of the item as far as Upchain is concerned.
11:30
So, this is how you can obsolete items that are still in development.
11:35
You can, of course, include additional decision points or tasks to your workflow,
11:39
to ensure your organization's workflow and business process is still followed,
11:44
but this should give you the foundation of what you need to build into this workflow at your organization.
Video transcript
00:09
In this video, we'll show you how to create a change request workflow to obsolete an item.
00:15
Let's take a look.
00:20
Items generally exist in a state of development, meaning they can be viewed and worked on or released,
00:28
meaning they are read-only and assumed to be in a finished state.
00:38
No items can be deleted from Upchain, so that full traceability and history is always maintained.
00:46
However, they can be removed from any project they belong to, which effectively hides it from users on that project.
00:54
And if it is removed from all projects, that effectively hides it from most users.
01:04
In most cases, simply removing an item from a project is enough to hide it from most end users.
01:11
But what happens if someone accidentally revises a released item?
01:19
Remember that Upchain generally insists that you work with the latest version of items and the files inside them.
01:26
If a released item suddenly has a newer version, this new version might start popping up in places it's not meant to.
01:37
For example, in the web application, you'll see a yellow warning symbol beside items that are no longer the latest version.
01:45
And when CAD users download something, they may see a warning indicating there is a newer file version in a newer item version.
01:55
So if this new version was created by accident, it likely isn't desirable to have it brought into a working cBOM or eBOM.
02:09
The obsolete status is a useful way to mark an item as not to be used, please ignore, no longer in use and so on.
02:19
It can also be used for items that need to be retired due to things such as industry standards having changed,
02:28
could be the suppliers have discontinued production of that particular item,
02:33
or perhaps even better designs have been determined at your organization.
02:39
Items that become obsolete stay in the bill of materials they were part of, and obsolete items can still be downloaded and viewed.
02:47
But by applying this status to an item, Upchain ignores it when looking for the latest version of an item.
02:56
Please note that Upchain can only turn an item that is in a development state to obsolete.
03:03
If an item is released, this cannot be made obsolete with the change request workflow.
03:08
If this is your situation, then you must reach out to Upchain support to obsolete your released items.
03:18
We'll create the new workflow from scratch to obsolete our items.
03:24
We'll name it "obsolete item", and it falls under the change request object.
03:39
Let's add in the start primitive, since that is required, and we'll update the start button text to say "send for obsolete".
03:50
And, of course, we need to stop primitive since that is also required.
03:57
Now, the key step that we need in this workflow is the update primitive.
04:03
This is the primitive that has the ability to change the item status to obsolete.
04:11
So let's configure that.
04:24
Of course, this is not enough for a complete workflow.
04:29
Like other change request workflows,
04:31
we should include another update primitive at the start to update the status of the change request to, in our case, pending approval.
04:49
We should also add another update primitive to update the status of the items temporarily to "Approval Pending".
05:04
This is so that no one can accidentally modify these items while it is part of a change request.
05:15
We'll also include a decision step so that the items cannot simply be made obsolete on a whim and must pass through another user's approval.
05:28
In this example, we'll set this decision as the generic decision task type.
05:38
We'll require both sets of comments.
05:44
The happy path will be to approve the request to "Obsolete", and the exception path will be the rejection path of the request.
05:55
We'll update the task description as well so the assignee is clear on what they are deciding.
06:14
We'll assign this to the project manager role since they should have complete oversight of the entire project.
06:23
We'll also allow workflow cancellation and send an email notification.
06:33
For our complete happy path, let's also include a final update primitive that will update the status of the change request accordingly.
06:49
In our case, we'll set it to "Completed", indicating that the items have been made obsolete and the workflow was successful.
07:01
Lastly, we'll connect the primitives together.
07:03
Again, we always start with a happy path by clicking from the start primitive to the destination primitive using the little square connector points.
07:15
The happy path is green.
07:17
And so if the project manager approves the decision, the workflow follows this happy path all the way to the end.
07:24
If they reject the decision to obsolete the item, let's simply return the items to a development state.
07:34
And we'll also mark the change request to canceled indicating that the request to be made obsolete was unsuccessful.
07:48
And we'll connect up the exception path.
07:55
So this is a nice simple workflow that involves one person to review the request to obsolete the items before the items are finally made obsolete.
08:08
Lastly, let's publish this workflow for our end users to use.
08:23
Now, let's test this workflow on an item.
08:27
We'll perform a search.
08:30
And here, you can see we've got two versions of this item, a released version and a newer version that was created by accident,
08:39
in our case, and is in a development state.
08:43
If we navigate to the released items project,
08:53
and look at it within the context of its bill of materials, you'll notice the yellow warning symbol indicating there is a newer item version.
09:01
In order to ensure the latest version is not accidentally brought into this bill of materials,
09:10
let's send this newer version to the obsolete workflow.
09:20
So we'll send the item to a change request.
09:27
We'll choose our published obsolete item workflow.
09:34
Like other change requests, the item does need a revision note, even though it's not being released or versioned up.
09:47
We'll save the changes and start the workflow.
09:57
You can see the button text that we configured is what appears on the button.
10:09
You can see that the item and the change request are both in a pending state.
10:15
And there are now two buttons available to the project manager to either approve this workflow and obsolete the item or reject it,
10:24
and this would cancel it outright.
10:27
We will click the "Obsolete Item" button, enter in an approval comment, since we also configured that requirement in our workflow.
10:57
And there you can see the item has now been made obsolete.
11:05
If we now look at the released item again, within the context of its project and bill of materials,
11:16
you can see it no longer shows a yellow warning symbol indicating there's something newer.
11:21
This is now the latest version of the item as far as Upchain is concerned.
11:30
So, this is how you can obsolete items that are still in development.
11:35
You can, of course, include additional decision points or tasks to your workflow,
11:39
to ensure your organization's workflow and business process is still followed,
11:44
but this should give you the foundation of what you need to build into this workflow at your organization.
How to buy
Privacy | Do not sell or share my personal information | Cookie preferences | Report noncompliance | Terms of use | Legal | © 2025 Autodesk Inc. All rights reserved
Sign in to start learning
Sign in for unlimited free access to all learning content.Save your progress
Take assessments
Receive personalized recommendations
May we collect and use your data?
Learn more about the Third Party Services we use and our Privacy Statement.May we collect and use your data to tailor your experience?
Explore the benefits of a customized experience by managing your privacy settings for this site or visit our Privacy Statement to learn more about your options.