& 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 might plan out a change workflow before trying to build one in Upchain. We’ll then discuss some of the possibilities that Upchain can provide within a Change request workflow, and then begin configuring item checks into a workflow in Upchain.
Think about the sorts of things you already include in the release process at your organization and write it out in a process flow diagram.
In this video, let’s discuss the sorts of things you may wish to include in your workflow and lay out an example workflow here. This will provide the foundation for how we build the workflow in Upchain later on.
Transcript
00:08
In this video, let's discuss the sorts of things you may wish to include in your workflow and lay out an example workflow here.
00:16
This will provide the foundation for how we build the workflow in Upchain later on.
00:22
What does it mean to be released?
00:25
We're not talking about released in the Upchain sense, but released at your organization.
00:31
Before you can start to build a workflow in Upchain,
00:34
you need to consider what your desired business process is and what each step of that process looks like.
00:40
Ask yourself these questions.
00:43
What does it mean for an item to be released at your organization?
00:49
What sorts of things must be true for an item to be considered finished?
00:54
What should happen if items do not meet certain criteria?
00:57
Should the workflow end or give the user a chance to fix them before proceeding?
01:03
How many people are involved in the review process?
01:07
Who will have the final sign off?
01:10
These are some of the questions to help you get started in thinking about your desired business process.
01:20
At our example company, here is a possible process that might be followed to release items.
01:26
In addition to ensuring the designs are correct,
01:28
the designer must confirm that all manufactured parts have all necessary information filled in, including a name, description, and material.
01:39
The designer must confirm that all off-the-shelf parts have all necessary information filled in,
01:45
including a name, description, manufacturer, and the manufacturer's catalog number.
01:53
The designer must ensure that all manufactured parts and assemblies have an up-to-date 2D drawing associated with it,
02:01
complete with all necessary views, dimensions, bill of materials, title blocks, and revision blocks.
02:08
The designer must ensure that all assemblies have been rebuilt and updated with the latest parts and subassemblies,
02:15
and they have gathered the necessary weight, density, and simulation results.
02:22
The assembly is then passed to the lead designers assigned to the project or at least one person must review and sign off on the data.
02:34
The assembly is then passed to the manufacturing team to review, and at least 75% of them must approve and sign off on it.
02:44
The assembly is then finally passed to the project manager to review and provide the final approval and sign off.
02:52
If anyone identifies issues in the data, it is sent back to the designer to fix the data before the review process starts again.
03:00
These acceptance or rejections must be properly documented for future audit purposes and lessons learned sessions.
03:10
Here is the same process mapped out in a flow diagram.
03:16
Manufactured items are checked for their correct information, off the shelf items are checked for their correct information.
03:26
Drawings are checked to make sure they are present for assemblies and manufactured items.
03:31
Assemblies and drawings are checked so that they are up to date with the latest model information,
03:36
and then the review process begins, starting with the lead, lead mechanical designers, the manufacturing team, and finally, the project manager.
03:47
If any reviewer identifies issues, the data is sent back to the designer to fix it and the review process starts again.
03:57
So, you can choose any method you wish to map out your desired process as long as it is clear and addresses any possible outcomes at each step.
04:14
In the above example, this process might be quite cumbersome and could span several days depending on how much data there is to sift through.
04:24
There would be a lot of time spent ensuring the data was not only present, but also valid.
04:31
Upchain can help with a lot of this process by ensuring this exact same process is followed every time an item is released,
04:39
so that no specific checks are missed.
04:42
It can also help ensure all necessary data is present so that every item released with this workflow is at least consistent.
04:53
It is important to remember though that upchaining cannot check the validity of your data,
04:59
but it can at least check that certain data is present so that the reviewers involved can focus on qualifying the data.
05:09
Let's consider the following primitives that can provide the kind of functionality we're looking for in our workflow.
05:20
The object decision primitive checks each item for specific attributes or files and produces a task for each item that fails this check.
05:31
It can also prevent the workflow from continuing until the necessary attributes are or files are present and filled in.
05:39
This primitive can be used for steps 1 to 3 in our workflow.
05:46
The system primitive contains an option to check that all assemblies and drawings are up to date,
05:53
and can even fix anything that is out of date for you if you desire.
05:58
This primitive can be used for step 4 in our workflow, as well as the final step to release the items.
06:14
The decision primitive is used to assign tasks to a single person or to everyone with a specific role on the project team or a group of people.
06:24
You can further specify how many people must complete this task before it'll move on.
06:32
This is a good primitive to use to track acceptance or rejection comments,
06:36
and loop your workflow back to the appropriate step to try again, rather than cancel the workflow outright.
06:44
We will use this primitive for each of our review steps 5 to 7.
06:50
We'll also, of course, include the other necessary primitives, including start, stop, and update as they exist in the current system workflow.
07:06
This video should get you thinking about what might be possible with Upchain,
07:11
and how you can start to translate your existing business processes for releasing items into a change request workflow in Upchain.
07:20
Please review the Upchain help documentation to review the capabilities of these different primitives as well as the additional primitives available.
07:28
But don't worry about fully understanding them now.
07:31
We'll start to configure this workflow in Upchain in this lesson.
07:35
So, keep going.
Video transcript
00:08
In this video, let's discuss the sorts of things you may wish to include in your workflow and lay out an example workflow here.
00:16
This will provide the foundation for how we build the workflow in Upchain later on.
00:22
What does it mean to be released?
00:25
We're not talking about released in the Upchain sense, but released at your organization.
00:31
Before you can start to build a workflow in Upchain,
00:34
you need to consider what your desired business process is and what each step of that process looks like.
00:40
Ask yourself these questions.
00:43
What does it mean for an item to be released at your organization?
00:49
What sorts of things must be true for an item to be considered finished?
00:54
What should happen if items do not meet certain criteria?
00:57
Should the workflow end or give the user a chance to fix them before proceeding?
01:03
How many people are involved in the review process?
01:07
Who will have the final sign off?
01:10
These are some of the questions to help you get started in thinking about your desired business process.
01:20
At our example company, here is a possible process that might be followed to release items.
01:26
In addition to ensuring the designs are correct,
01:28
the designer must confirm that all manufactured parts have all necessary information filled in, including a name, description, and material.
01:39
The designer must confirm that all off-the-shelf parts have all necessary information filled in,
01:45
including a name, description, manufacturer, and the manufacturer's catalog number.
01:53
The designer must ensure that all manufactured parts and assemblies have an up-to-date 2D drawing associated with it,
02:01
complete with all necessary views, dimensions, bill of materials, title blocks, and revision blocks.
02:08
The designer must ensure that all assemblies have been rebuilt and updated with the latest parts and subassemblies,
02:15
and they have gathered the necessary weight, density, and simulation results.
02:22
The assembly is then passed to the lead designers assigned to the project or at least one person must review and sign off on the data.
02:34
The assembly is then passed to the manufacturing team to review, and at least 75% of them must approve and sign off on it.
02:44
The assembly is then finally passed to the project manager to review and provide the final approval and sign off.
02:52
If anyone identifies issues in the data, it is sent back to the designer to fix the data before the review process starts again.
03:00
These acceptance or rejections must be properly documented for future audit purposes and lessons learned sessions.
03:10
Here is the same process mapped out in a flow diagram.
03:16
Manufactured items are checked for their correct information, off the shelf items are checked for their correct information.
03:26
Drawings are checked to make sure they are present for assemblies and manufactured items.
03:31
Assemblies and drawings are checked so that they are up to date with the latest model information,
03:36
and then the review process begins, starting with the lead, lead mechanical designers, the manufacturing team, and finally, the project manager.
03:47
If any reviewer identifies issues, the data is sent back to the designer to fix it and the review process starts again.
03:57
So, you can choose any method you wish to map out your desired process as long as it is clear and addresses any possible outcomes at each step.
04:14
In the above example, this process might be quite cumbersome and could span several days depending on how much data there is to sift through.
04:24
There would be a lot of time spent ensuring the data was not only present, but also valid.
04:31
Upchain can help with a lot of this process by ensuring this exact same process is followed every time an item is released,
04:39
so that no specific checks are missed.
04:42
It can also help ensure all necessary data is present so that every item released with this workflow is at least consistent.
04:53
It is important to remember though that upchaining cannot check the validity of your data,
04:59
but it can at least check that certain data is present so that the reviewers involved can focus on qualifying the data.
05:09
Let's consider the following primitives that can provide the kind of functionality we're looking for in our workflow.
05:20
The object decision primitive checks each item for specific attributes or files and produces a task for each item that fails this check.
05:31
It can also prevent the workflow from continuing until the necessary attributes are or files are present and filled in.
05:39
This primitive can be used for steps 1 to 3 in our workflow.
05:46
The system primitive contains an option to check that all assemblies and drawings are up to date,
05:53
and can even fix anything that is out of date for you if you desire.
05:58
This primitive can be used for step 4 in our workflow, as well as the final step to release the items.
06:14
The decision primitive is used to assign tasks to a single person or to everyone with a specific role on the project team or a group of people.
06:24
You can further specify how many people must complete this task before it'll move on.
06:32
This is a good primitive to use to track acceptance or rejection comments,
06:36
and loop your workflow back to the appropriate step to try again, rather than cancel the workflow outright.
06:44
We will use this primitive for each of our review steps 5 to 7.
06:50
We'll also, of course, include the other necessary primitives, including start, stop, and update as they exist in the current system workflow.
07:06
This video should get you thinking about what might be possible with Upchain,
07:11
and how you can start to translate your existing business processes for releasing items into a change request workflow in Upchain.
07:20
Please review the Upchain help documentation to review the capabilities of these different primitives as well as the additional primitives available.
07:28
But don't worry about fully understanding them now.
07:31
We'll start to configure this workflow in Upchain in this lesson.
07:35
So, keep going.
In this video, we’ll demonstrate how to configure the primitives we’ll need in the workflow to check our items for missing attributes and drawings, as well as ensuring all assemblies and drawings are up to date with the latest model information.
Transcript
00:09
In this video, we'll demonstrate how to configure primitives to check our items for missing attributes and drawings,
00:15
and how to configure a primitive to ensure all assemblies and drawings are up to date with the latest model information.
00:21
So, let's take a look.
00:24
Let's start putting together the workflow that we outlined in the previous video.
00:29
We'll start by duplicating the existing system workflow for change requests.
00:37
This is so that we can keep the existing beginning and end steps, but add our own steps into the middle.
00:45
Let's clear out some of the primitives and connectors we don't need to make room for what we're about to add.
00:55
Remember, every workflow must have a start and stop primitive.
01:00
We'll configure the start primitive with our own custom button text, send for release.
01:11
Remember that it is also useful to have these two update primitives at the beginning.
01:17
The first updates the status of the change request to work in progress, and the second updates the status of the items to approval pending.
01:25
This ensures items cannot be accidentally edited since they're no longer in a development state while submitted for release.
01:34
The first thing the designer must do is ensure that all manufactured parts have all necessary attributes filled in.
01:41
In our case, the name, description, and material.
01:45
We can use the object decision primitive for this.
01:50
This primitive checks each item for specific attributes and can prevent the workflow from continuing until the necessary attributes are filled in.
01:60
A separate task is created for each item that fails a check and the task must be completed,
02:06
in other words, the attributes must be filled in before the workflow can continue.
02:15
Remember, Upchain won't be able to check that the values are correct, just that there is something filled in to each attribute field.
02:23
Let's configure this primitive.
02:26
The type must be set first.
02:29
This we'll set to associate multi-item attribute task.
02:35
The name sounds confusing, but it means the primitive will check for specific attributes in your items,
02:41
and create individual tasks for each item that fails the check.
02:52
Now let's work through the options top to bottom.
02:56
The first thing to configure is the name.
02:58
This is how it appears on the canvas so you can remember what this step does.
03:04
Let's call it manufactured attribute check.
03:10
Since the task is created for each item that fails the task and there needs to be an assignee for the task,
03:18
and since it is the designer's responsibility to ensure the data is correct initially,
03:23
and we're assuming the designer will create and start the change request when they feel the items are ready,
03:29
we'll set the assignee to the work order creator.
03:32
In other words, the change request creator.
03:38
Notes are optional, but can further help you remember what this primitive is for and what it does.
03:47
Next is the text for the button on the task that the assignee will click when the task is complete.
03:54
Since we're checking attributes, we can type in attributes filled in.
04:04
You should definitely tick the box to allow workflow cancellation.
04:09
This allows you to completely back out of the change request workflow if there happens to be a lot wrong with the items.
04:17
This option is recommended for all stages of the workflow.
04:23
Now let's configure the pass-fail item statuses.
04:27
These settings temporarily change the status of the items if they pass or fail the check we specify.
04:34
Here, for items that pass, they should stay in an approval pending state,
04:41
because they do not need to be changed and we don't want to open them up, open them up for accidental changes.
04:47
For items that fail, we want to return them to a development state,
04:52
so that the end user can fix the attributes all while the items remain in this change request.
05:08
We should definitely tick the box to recheck criteria before completing the task.
05:15
This means that the task created for an item that fails the checks will not be marked as "Complete",
05:20
unless the assignee truly configures the items to pass the check.
05:25
This means the workflow will not continue until all items have been fixed.
05:32
This is why it's also useful to have the "Allow Workflow Cancellation" option selected,
05:37
so that if there is a lot to fix or you get stuck, you can always cancel the workflow outright.
05:44
And that will remove any tasks along with it.
05:49
Now let's specify what we're actually checking the items for and what it means for an item to fail.
05:56
The rejection criteria is where you specify what it means for an item to fail and will therefore have a task generated for it.
06:05
In this first step, we want to check all manufactured items have a name, description, and material filled in.
06:14
So, let's configure that.
06:36
The above means that an item will fail if it is a manufactured item, and either the name, description, or material is empty.
06:50
This criteria now specifies what it means for an item to fail.
06:57
Lastly, let's add in a description for the task that the assignee will receive.
07:02
We want to be as descriptive as possible so that the assignee understands what they should look for.
07:07
Something like all manufactured items must contain a name, description, and material.
07:13
Please fill out this information and try again.
07:17
This primitive is now filled out completely, so let's save our work so we don't lose our progress.
07:28
The next step in our workflow is to ensure all purchased or off the shelf parts have all necessary attributes filled in.
07:37
In our case, a name, description, manufacturer, and manufacturer's part number or the catalog number.
07:43
This is a very similar check to our previous one, so we are going to clone this primitive,
07:50
so that we don't have to type in everything again since a lot of the settings are the same.
08:01
The type will stay the same.
08:12
We'll update the name slightly.
08:18
The assignee will stay the same.
08:24
Notes need updated slightly.
08:30
The button text can stay the same.
08:33
Workflow cancellation, the pass-fail statuses, and the recheck criteria settings all remain the same.
08:41
However, the rejection criteria will be slightly different.
08:45
Here, we are going to check that items of the purchased mechanical, purchased electromechanical,
08:51
or purchased electrical type have their name, description, manufacturer, and manufacturer part number filled in.
09:48
Here, if the item is any of the purchase types and it's missing any of its attributes, it will fail.
10:11
Lastly, we'll update the task description to reflect the changes in this primitive.
10:16
The text will remain fairly similar to the text that was in there previously.
10:22
Again, let's save our work so we don't lose our progress.
10:36
Step 3 in our workflow wants us to check that assemblies and manufactured items all have a 2D drawing.
10:44
For this, we also use an object decision primitive.
10:50
So, again, we'll clone one of the ones that we already have.
10:57
This time we're going to choose a different type.
11:05
This time we'll choose associate multi-item required files task.
11:10
This one will check items for a specific file and, again, generate a task if any of those files are missing.
11:19
Let's quickly update the other necessary fields to properly describe what this primitive is checking for.
11:26
We need to reassign the assignee since we changed the type.
11:45
Now let's configure the correct criteria.
11:47
You'll notice that there are two sets of options to configure.
11:51
This time the rejection criteria specifies which items we are going to check for specific files.
12:04
In our case, we want to check manufactured items and assemblies for the presence of a drawing.
12:38
The file criteria is where we specify which type of file Upchain will search for.
12:46
In our case, we will accept either an inventor IDW drawing,
12:57
or a DWG drawing file,
13:07
or a PDF as the drawing.
13:13
So, we've added those in.
13:20
Note that Upchain will only check for these file types in the CBOM and drawing sections of the items and in no other document categories.
13:35
Lastly, let's update the task description to reflect the file types that are required.
13:43
Now that that's configured, again, let's save our work so we don't lose our progress.
13:56
Step 4 wants us now to check that the drawings and assemblies are up to date.
14:03
This check can be found in the system primitive.
14:13
The specific option we need here is as saved equals latest working.
14:22
This check uses the same download filters that CAD users are faced with when downloading or checking out CAD.
14:31
The as saved filter shows which CAD file versions of the child components were saved into the CBOM of the parent item,
14:40
when the parent item was last checked in.
14:43
The latest working filter shows the latest CAD file version of the child components in the CBOM of the parent assembly.
14:52
In other words, this check is ensuring that what was last saved into the assembly in Upchain is the latest working versions of all components.
15:03
This check is also performed on drawings to ensure that when it was last checked in, it was also referring to its latest model version.
15:13
This is an important check because, otherwise, you could end up releasing an assembly or drawing with out-of-date information.
15:24
We'll update the name to reflect what this is checking and the notes to expand on what this is checking for.
15:34
Lastly, we'll save our progress.
15:38
Okay.
15:40
That was a lot to take in.
15:41
Take a breath.
15:43
This should give you enough information to consider using these sorts of item checks in your change request workflows if you wish.
15:51
We're only part of the way there.
15:52
We still need to configure the review stages, so keep going.
Video transcript
00:09
In this video, we'll demonstrate how to configure primitives to check our items for missing attributes and drawings,
00:15
and how to configure a primitive to ensure all assemblies and drawings are up to date with the latest model information.
00:21
So, let's take a look.
00:24
Let's start putting together the workflow that we outlined in the previous video.
00:29
We'll start by duplicating the existing system workflow for change requests.
00:37
This is so that we can keep the existing beginning and end steps, but add our own steps into the middle.
00:45
Let's clear out some of the primitives and connectors we don't need to make room for what we're about to add.
00:55
Remember, every workflow must have a start and stop primitive.
01:00
We'll configure the start primitive with our own custom button text, send for release.
01:11
Remember that it is also useful to have these two update primitives at the beginning.
01:17
The first updates the status of the change request to work in progress, and the second updates the status of the items to approval pending.
01:25
This ensures items cannot be accidentally edited since they're no longer in a development state while submitted for release.
01:34
The first thing the designer must do is ensure that all manufactured parts have all necessary attributes filled in.
01:41
In our case, the name, description, and material.
01:45
We can use the object decision primitive for this.
01:50
This primitive checks each item for specific attributes and can prevent the workflow from continuing until the necessary attributes are filled in.
01:60
A separate task is created for each item that fails a check and the task must be completed,
02:06
in other words, the attributes must be filled in before the workflow can continue.
02:15
Remember, Upchain won't be able to check that the values are correct, just that there is something filled in to each attribute field.
02:23
Let's configure this primitive.
02:26
The type must be set first.
02:29
This we'll set to associate multi-item attribute task.
02:35
The name sounds confusing, but it means the primitive will check for specific attributes in your items,
02:41
and create individual tasks for each item that fails the check.
02:52
Now let's work through the options top to bottom.
02:56
The first thing to configure is the name.
02:58
This is how it appears on the canvas so you can remember what this step does.
03:04
Let's call it manufactured attribute check.
03:10
Since the task is created for each item that fails the task and there needs to be an assignee for the task,
03:18
and since it is the designer's responsibility to ensure the data is correct initially,
03:23
and we're assuming the designer will create and start the change request when they feel the items are ready,
03:29
we'll set the assignee to the work order creator.
03:32
In other words, the change request creator.
03:38
Notes are optional, but can further help you remember what this primitive is for and what it does.
03:47
Next is the text for the button on the task that the assignee will click when the task is complete.
03:54
Since we're checking attributes, we can type in attributes filled in.
04:04
You should definitely tick the box to allow workflow cancellation.
04:09
This allows you to completely back out of the change request workflow if there happens to be a lot wrong with the items.
04:17
This option is recommended for all stages of the workflow.
04:23
Now let's configure the pass-fail item statuses.
04:27
These settings temporarily change the status of the items if they pass or fail the check we specify.
04:34
Here, for items that pass, they should stay in an approval pending state,
04:41
because they do not need to be changed and we don't want to open them up, open them up for accidental changes.
04:47
For items that fail, we want to return them to a development state,
04:52
so that the end user can fix the attributes all while the items remain in this change request.
05:08
We should definitely tick the box to recheck criteria before completing the task.
05:15
This means that the task created for an item that fails the checks will not be marked as "Complete",
05:20
unless the assignee truly configures the items to pass the check.
05:25
This means the workflow will not continue until all items have been fixed.
05:32
This is why it's also useful to have the "Allow Workflow Cancellation" option selected,
05:37
so that if there is a lot to fix or you get stuck, you can always cancel the workflow outright.
05:44
And that will remove any tasks along with it.
05:49
Now let's specify what we're actually checking the items for and what it means for an item to fail.
05:56
The rejection criteria is where you specify what it means for an item to fail and will therefore have a task generated for it.
06:05
In this first step, we want to check all manufactured items have a name, description, and material filled in.
06:14
So, let's configure that.
06:36
The above means that an item will fail if it is a manufactured item, and either the name, description, or material is empty.
06:50
This criteria now specifies what it means for an item to fail.
06:57
Lastly, let's add in a description for the task that the assignee will receive.
07:02
We want to be as descriptive as possible so that the assignee understands what they should look for.
07:07
Something like all manufactured items must contain a name, description, and material.
07:13
Please fill out this information and try again.
07:17
This primitive is now filled out completely, so let's save our work so we don't lose our progress.
07:28
The next step in our workflow is to ensure all purchased or off the shelf parts have all necessary attributes filled in.
07:37
In our case, a name, description, manufacturer, and manufacturer's part number or the catalog number.
07:43
This is a very similar check to our previous one, so we are going to clone this primitive,
07:50
so that we don't have to type in everything again since a lot of the settings are the same.
08:01
The type will stay the same.
08:12
We'll update the name slightly.
08:18
The assignee will stay the same.
08:24
Notes need updated slightly.
08:30
The button text can stay the same.
08:33
Workflow cancellation, the pass-fail statuses, and the recheck criteria settings all remain the same.
08:41
However, the rejection criteria will be slightly different.
08:45
Here, we are going to check that items of the purchased mechanical, purchased electromechanical,
08:51
or purchased electrical type have their name, description, manufacturer, and manufacturer part number filled in.
09:48
Here, if the item is any of the purchase types and it's missing any of its attributes, it will fail.
10:11
Lastly, we'll update the task description to reflect the changes in this primitive.
10:16
The text will remain fairly similar to the text that was in there previously.
10:22
Again, let's save our work so we don't lose our progress.
10:36
Step 3 in our workflow wants us to check that assemblies and manufactured items all have a 2D drawing.
10:44
For this, we also use an object decision primitive.
10:50
So, again, we'll clone one of the ones that we already have.
10:57
This time we're going to choose a different type.
11:05
This time we'll choose associate multi-item required files task.
11:10
This one will check items for a specific file and, again, generate a task if any of those files are missing.
11:19
Let's quickly update the other necessary fields to properly describe what this primitive is checking for.
11:26
We need to reassign the assignee since we changed the type.
11:45
Now let's configure the correct criteria.
11:47
You'll notice that there are two sets of options to configure.
11:51
This time the rejection criteria specifies which items we are going to check for specific files.
12:04
In our case, we want to check manufactured items and assemblies for the presence of a drawing.
12:38
The file criteria is where we specify which type of file Upchain will search for.
12:46
In our case, we will accept either an inventor IDW drawing,
12:57
or a DWG drawing file,
13:07
or a PDF as the drawing.
13:13
So, we've added those in.
13:20
Note that Upchain will only check for these file types in the CBOM and drawing sections of the items and in no other document categories.
13:35
Lastly, let's update the task description to reflect the file types that are required.
13:43
Now that that's configured, again, let's save our work so we don't lose our progress.
13:56
Step 4 wants us now to check that the drawings and assemblies are up to date.
14:03
This check can be found in the system primitive.
14:13
The specific option we need here is as saved equals latest working.
14:22
This check uses the same download filters that CAD users are faced with when downloading or checking out CAD.
14:31
The as saved filter shows which CAD file versions of the child components were saved into the CBOM of the parent item,
14:40
when the parent item was last checked in.
14:43
The latest working filter shows the latest CAD file version of the child components in the CBOM of the parent assembly.
14:52
In other words, this check is ensuring that what was last saved into the assembly in Upchain is the latest working versions of all components.
15:03
This check is also performed on drawings to ensure that when it was last checked in, it was also referring to its latest model version.
15:13
This is an important check because, otherwise, you could end up releasing an assembly or drawing with out-of-date information.
15:24
We'll update the name to reflect what this is checking and the notes to expand on what this is checking for.
15:34
Lastly, we'll save our progress.
15:38
Okay.
15:40
That was a lot to take in.
15:41
Take a breath.
15:43
This should give you enough information to consider using these sorts of item checks in your change request workflows if you wish.
15:51
We're only part of the way there.
15:52
We still need to configure the review stages, so keep going.
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.