& 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 continue building on the workflow that we started in the previous lesson. We’ll focus on how to configure decision points so that you can include multiple people and teams in the review and approval stages of your workflow. We’ll also finish the workflow by adding connectors, configuring all exceptions paths, and finally publishing the workflow for final use.
In this video, we’ll demonstrate how to configure the primitives for each approval stage in the workflow.
Transcript
00:09
In this video, we'll demonstrate how to configure the primitives for each approval stage in the workflow, so let's take a look.
00:18
Now that we have our item checks in place, let's move on to configuring the approval steps.
00:24
For each of these steps, we are going to use the decision primitive.
00:28
This is found under the User Primitive section.
00:33
But first, let's add an update primitive after the item checks to indicate that the change request is now in the approval pending stage.
00:43
This helps others reviewing the list of change requests understand what stage this change request is at.
01:05
The first review step is to be done by the lead mechanical designer.
01:11
So, we'll click and drag a new decision primitive onto the canvas.
01:17
Let's give it a name and fill out the notes to distinguish it from the other approval steps we'll add later on.
01:33
For this decision, we'll set it to the generic decision type.
01:39
This means only one person has to make the decision for the workflow to proceed.
01:47
We'll tick these two boxes to enforce the requirement that the decision maker must enter a comment into the change request,
01:55
regardless of which decision they make.
02:00
The decision maker will receive 2 options when making their decision.
02:05
The user command is the button the decision maker clicks to approve the data and send the workflow down the happy path.
02:19
The user command rejected is the button the decision maker clicks to reject the data and send the workflow down the exception path.
02:32
Let's type in a task description so that the assignee knows what they are meant to do at this stage.
02:45
Since we want to be able to use this workflow across many different projects,
02:49
we don't wanna call out the specific person by name, rather we'll set the assignee to the role of lead mechanical designer.
02:58
That way, whoever holds that role on the project will receive the decision task when someone initiates this workflow.
03:08
Again, we should allow workflow cancellation because we should always have an option to back out of the workflow,
03:14
and cancel the change request if necessary.
03:20
And lastly, we'll tick the box to send an email notification While the task will appear in the various my assignments areas throughout Upchain,
03:30
without this option checked, the assignee of the decision may not be immediately aware that they have a new task assigned.
03:40
Let's save our work so we don't lose our progress.
03:50
The next review step is to be done by the manufacturing team.
03:54
At least 75% of this team must give their approval for the workflow to proceed.
04:01
This team may change over time perhaps because people change departments, leave the company, or new people are hired.
04:11
Instead of listing out the specific team members by name within the primitive,
04:17
and subsequently having to update the workflow every time this team changes,
04:22
instead, we have configured a user team called manufacturing team.
04:28
Then when we assign the decision task to this team, it won't matter if the users inside it change over time.
04:36
We're still calling out to this manufacturing team.
04:44
Let's see how this works.
04:53
First, let's clone the existing decision task.
04:59
Most of the settings will be the same, so cloning makes configuring the next primitive a bit quicker and easier.
05:06
We'll change the name and the note to reflect who this decision is for.
05:20
This time, since we need multiple decisions from within the same team, we'll choose a quorum decision type.
05:29
This means multiple users must make the approval decision for the workflow to follow the flow to follow the happy path, not just one person.
05:44
The assignee has been cleared when we change the task type.
05:49
Let's assign it to the manufacturing team.
05:52
You'll find this underneath the user teams tab.
05:57
The team, of course, must be configured before you can assign a task to it.
06:04
Lastly, because this is a quorum decision,
06:07
we'll need to specify what percentage of assignees need to make an approval decision before the workflow proceeds down the happy path.
06:16
In our example, the percentage of this team that must approve the items is 75%, so we type in 75.
06:26
Note that if anyone in the assignee list rejects the decision, it automatically goes down the exception path.
06:33
The 75% is so that you can ensure a specific amount of the team actually reviews and approves the data before it will move down the happy path.
06:51
Lastly, the project manager must give their final review and sign off.
06:57
We'll configure this in the same way as the mechanical lead decision primitive since we're assigning this decision to a role.
07:05
So, again, we will clone that primitive since the majority of the settings are the same.
07:12
We'll update the name and the notes, but the type remains the same.
07:19
All other settings remain the same.
07:25
But we'll update the assignee to the project manager and remove the lead mechanical designer role.
07:43
Let's save our changes.
07:55
And we're nearly there.
07:57
All of our key primitives are now configured.
08:00
The last thing to do is connect them together and finally publish the workflow.
08:05
So, keep going to the next video to learn how to do this.
Video transcript
00:09
In this video, we'll demonstrate how to configure the primitives for each approval stage in the workflow, so let's take a look.
00:18
Now that we have our item checks in place, let's move on to configuring the approval steps.
00:24
For each of these steps, we are going to use the decision primitive.
00:28
This is found under the User Primitive section.
00:33
But first, let's add an update primitive after the item checks to indicate that the change request is now in the approval pending stage.
00:43
This helps others reviewing the list of change requests understand what stage this change request is at.
01:05
The first review step is to be done by the lead mechanical designer.
01:11
So, we'll click and drag a new decision primitive onto the canvas.
01:17
Let's give it a name and fill out the notes to distinguish it from the other approval steps we'll add later on.
01:33
For this decision, we'll set it to the generic decision type.
01:39
This means only one person has to make the decision for the workflow to proceed.
01:47
We'll tick these two boxes to enforce the requirement that the decision maker must enter a comment into the change request,
01:55
regardless of which decision they make.
02:00
The decision maker will receive 2 options when making their decision.
02:05
The user command is the button the decision maker clicks to approve the data and send the workflow down the happy path.
02:19
The user command rejected is the button the decision maker clicks to reject the data and send the workflow down the exception path.
02:32
Let's type in a task description so that the assignee knows what they are meant to do at this stage.
02:45
Since we want to be able to use this workflow across many different projects,
02:49
we don't wanna call out the specific person by name, rather we'll set the assignee to the role of lead mechanical designer.
02:58
That way, whoever holds that role on the project will receive the decision task when someone initiates this workflow.
03:08
Again, we should allow workflow cancellation because we should always have an option to back out of the workflow,
03:14
and cancel the change request if necessary.
03:20
And lastly, we'll tick the box to send an email notification While the task will appear in the various my assignments areas throughout Upchain,
03:30
without this option checked, the assignee of the decision may not be immediately aware that they have a new task assigned.
03:40
Let's save our work so we don't lose our progress.
03:50
The next review step is to be done by the manufacturing team.
03:54
At least 75% of this team must give their approval for the workflow to proceed.
04:01
This team may change over time perhaps because people change departments, leave the company, or new people are hired.
04:11
Instead of listing out the specific team members by name within the primitive,
04:17
and subsequently having to update the workflow every time this team changes,
04:22
instead, we have configured a user team called manufacturing team.
04:28
Then when we assign the decision task to this team, it won't matter if the users inside it change over time.
04:36
We're still calling out to this manufacturing team.
04:44
Let's see how this works.
04:53
First, let's clone the existing decision task.
04:59
Most of the settings will be the same, so cloning makes configuring the next primitive a bit quicker and easier.
05:06
We'll change the name and the note to reflect who this decision is for.
05:20
This time, since we need multiple decisions from within the same team, we'll choose a quorum decision type.
05:29
This means multiple users must make the approval decision for the workflow to follow the flow to follow the happy path, not just one person.
05:44
The assignee has been cleared when we change the task type.
05:49
Let's assign it to the manufacturing team.
05:52
You'll find this underneath the user teams tab.
05:57
The team, of course, must be configured before you can assign a task to it.
06:04
Lastly, because this is a quorum decision,
06:07
we'll need to specify what percentage of assignees need to make an approval decision before the workflow proceeds down the happy path.
06:16
In our example, the percentage of this team that must approve the items is 75%, so we type in 75.
06:26
Note that if anyone in the assignee list rejects the decision, it automatically goes down the exception path.
06:33
The 75% is so that you can ensure a specific amount of the team actually reviews and approves the data before it will move down the happy path.
06:51
Lastly, the project manager must give their final review and sign off.
06:57
We'll configure this in the same way as the mechanical lead decision primitive since we're assigning this decision to a role.
07:05
So, again, we will clone that primitive since the majority of the settings are the same.
07:12
We'll update the name and the notes, but the type remains the same.
07:19
All other settings remain the same.
07:25
But we'll update the assignee to the project manager and remove the lead mechanical designer role.
07:43
Let's save our changes.
07:55
And we're nearly there.
07:57
All of our key primitives are now configured.
08:00
The last thing to do is connect them together and finally publish the workflow.
08:05
So, keep going to the next video to learn how to do this.
In this video, we’ll demonstrate how to connect all the primitives together that we configured in the previous video and publish the workflow for final use.
Transcript
00:09
In this video, we'll demonstrate how to connect all the primitives together that we configured in the previous videos,
00:15
and how to publish the workflow for final use.
00:18
So, let's take a look.
00:22
Our final task is to connect the primitives together and publish the workflow for use.
00:28
You always begin by connecting the happy path first.
00:32
The exception path is always configured second.
00:36
You can connect up the entire happy path first and then any exception path second, or you can work through it one primitive at a time.
00:46
It's entirely up to you.
00:49
We'll follow the first method.
00:51
Let's connect up all the happy paths first.
00:56
To do this, click one of the four connector points of the starting primitive.
01:03
Then, with your mouse button still pressed, drag the cursor towards the connector point of the next primitive.
01:10
Then, once your mouse pointer is over the next connector, release the mouse button.
01:16
You'll notice the happy path is green.
01:19
And we'll repeat this for our full desired happy path.
01:39
And of course, it's always a good idea to save your work as you go.
01:48
The exception path is always configured second.
01:52
These are necessary to add in for any primitive that has two possible outcomes.
01:58
In our case, the system primitive has two possible outcomes and the decision primitives can all be either accepted or rejected.
02:10
Let's deal with the decision primitives first.
02:14
We've specified in our example that if anyone identifies issues in the data,
02:20
it should be sent back to the designer to fix the data before the review process starts again.
02:28
So, in our case, we want to connect each decision primitive up to a new update primitive that updates the change request back to work in progress.
02:39
You'll find the update primitive in the system primitives section.
02:47
So, this update primitive will update the change request to work in progress.
03:01
We'll also add in an update primitive to return the items to a development state,
03:05
so that any changes can be made by the designer before they resubmit for release,
03:12
all while keeping the items within the same change request.
03:18
Now to notify the designer that they have something to do and that their approval request was rejected,
03:26
we'll add in a task primitive and assign it to the work order creator.
03:32
We'll configure this primitive as a task to fix the data as outlined in the rejection comments and assign it to the work order creator,
03:40
i.e. the designer, since they are responsible for its creation.
03:49
We'll fill out the task details that lets the designer know that their request for release has been rejected and some data fixes are required.
04:05
We'll also allow workflow cancellation, so that the change request can be canceled if more drastic changes need to be made to the data.
04:16
By building this loop into the workflow,
04:19
it ensures that the data can stay within the same change request and all comments and history of the review process are saved in one place.
04:32
This loop will take us back to the very beginning.
04:42
Let's connect up the other decision primitives to the same loop.
04:55
And we'll save our work.
05:04
The system primitive that checks that all files are up to date also has two possible outcomes.
05:11
If files are not up to date, we need to put the items back into development and allow the designer to make sure the files are up to date.
05:20
This has to be done with additional primitives.
05:22
It does not have built in tasks like the object decision primitives do.
05:31
Let's add in an update primitive to return the items to a development state.
05:38
This is so that the CAD files and drawings in the items can be checked out to update them.
05:54
Let's also add in a decision primitive where the designer can either retry the release or cancel out of the workflow, if desired.
06:16
We've chosen a decision primitive here to have two possibilities to deal with this situation.
06:22
But you could also use a task primitive to simply loop back to the beginning, like we did for the decision primitives exception paths.
07:22
Now let's connect these primitives together.
07:33
If the designer says they have fixed the data, the workflow should start again from the beginning.
07:41
If they decide that they want to cancel out of the workflow,
07:45
we'll connect that path up to the statuses towards the end of the workflow that just updates the items to development,
07:55
the change request to canceled, and then the workflow will end.
07:60
So, you can see you may need to add in additional primitives to handle these exception paths.
08:11
The last thing to do is to publish this workflow.
08:15
Upchain always performs a sanity check on the workflow to ensure you have not missed any necessary settings in the primitives,
08:22
and that all necessary connections between the primitives have been made.
08:27
This is to ensure you do not publish something that does not have all necessary logic in place to handle all possible outcomes of the workflow.
08:37
As you can see in our example, primitive 5 was missing a connector.
08:42
But now, we are able to publish successfully.
08:50
When building these change request workflows, there are some things that you may wish to consider.
08:58
Test each one of these primitives in a smaller workflow one at a time,
09:03
so that you can get an understanding of what it does,
09:05
and to ensure it is checking things correctly on items that will deliberately pass or deliberately fail.
09:14
Create two workflows for your end users.
09:17
One that simply checks the data and one that includes these checks but also the approval and release stages.
09:29
Make use of the update primitive as much as possible to keep the change request up to date.
09:35
For example, it might be useful to insert an update primitive in between each approval stage,
09:41
since there are several options that can help describe what stage it's at.
09:49
If you have a mechanical team and an electrical team and they work separately, consider building two separate pathways into the workflow.
09:59
One to follow the electrical approval process and one to follow the mechanical approval process.
10:05
Upchain can't follow each path simultaneously, but it can follow one or the other,
10:10
and check to ensure there isn't a mix of the two item type groups in the same change request.
10:17
It also makes it simpler for your end users to only have one workflow to pick from.
10:26
And of course, the Upchain help documentation contains all information about every setting for every primitive.
10:38
This may have seemed like a lot and we did configure quite a few additional primitives to the out-of-the-box workflow.
10:46
But it should put you in a good position to begin creating workflows like this for yourself.
10:51
So, good luck and happy workflowing.
Video transcript
00:09
In this video, we'll demonstrate how to connect all the primitives together that we configured in the previous videos,
00:15
and how to publish the workflow for final use.
00:18
So, let's take a look.
00:22
Our final task is to connect the primitives together and publish the workflow for use.
00:28
You always begin by connecting the happy path first.
00:32
The exception path is always configured second.
00:36
You can connect up the entire happy path first and then any exception path second, or you can work through it one primitive at a time.
00:46
It's entirely up to you.
00:49
We'll follow the first method.
00:51
Let's connect up all the happy paths first.
00:56
To do this, click one of the four connector points of the starting primitive.
01:03
Then, with your mouse button still pressed, drag the cursor towards the connector point of the next primitive.
01:10
Then, once your mouse pointer is over the next connector, release the mouse button.
01:16
You'll notice the happy path is green.
01:19
And we'll repeat this for our full desired happy path.
01:39
And of course, it's always a good idea to save your work as you go.
01:48
The exception path is always configured second.
01:52
These are necessary to add in for any primitive that has two possible outcomes.
01:58
In our case, the system primitive has two possible outcomes and the decision primitives can all be either accepted or rejected.
02:10
Let's deal with the decision primitives first.
02:14
We've specified in our example that if anyone identifies issues in the data,
02:20
it should be sent back to the designer to fix the data before the review process starts again.
02:28
So, in our case, we want to connect each decision primitive up to a new update primitive that updates the change request back to work in progress.
02:39
You'll find the update primitive in the system primitives section.
02:47
So, this update primitive will update the change request to work in progress.
03:01
We'll also add in an update primitive to return the items to a development state,
03:05
so that any changes can be made by the designer before they resubmit for release,
03:12
all while keeping the items within the same change request.
03:18
Now to notify the designer that they have something to do and that their approval request was rejected,
03:26
we'll add in a task primitive and assign it to the work order creator.
03:32
We'll configure this primitive as a task to fix the data as outlined in the rejection comments and assign it to the work order creator,
03:40
i.e. the designer, since they are responsible for its creation.
03:49
We'll fill out the task details that lets the designer know that their request for release has been rejected and some data fixes are required.
04:05
We'll also allow workflow cancellation, so that the change request can be canceled if more drastic changes need to be made to the data.
04:16
By building this loop into the workflow,
04:19
it ensures that the data can stay within the same change request and all comments and history of the review process are saved in one place.
04:32
This loop will take us back to the very beginning.
04:42
Let's connect up the other decision primitives to the same loop.
04:55
And we'll save our work.
05:04
The system primitive that checks that all files are up to date also has two possible outcomes.
05:11
If files are not up to date, we need to put the items back into development and allow the designer to make sure the files are up to date.
05:20
This has to be done with additional primitives.
05:22
It does not have built in tasks like the object decision primitives do.
05:31
Let's add in an update primitive to return the items to a development state.
05:38
This is so that the CAD files and drawings in the items can be checked out to update them.
05:54
Let's also add in a decision primitive where the designer can either retry the release or cancel out of the workflow, if desired.
06:16
We've chosen a decision primitive here to have two possibilities to deal with this situation.
06:22
But you could also use a task primitive to simply loop back to the beginning, like we did for the decision primitives exception paths.
07:22
Now let's connect these primitives together.
07:33
If the designer says they have fixed the data, the workflow should start again from the beginning.
07:41
If they decide that they want to cancel out of the workflow,
07:45
we'll connect that path up to the statuses towards the end of the workflow that just updates the items to development,
07:55
the change request to canceled, and then the workflow will end.
07:60
So, you can see you may need to add in additional primitives to handle these exception paths.
08:11
The last thing to do is to publish this workflow.
08:15
Upchain always performs a sanity check on the workflow to ensure you have not missed any necessary settings in the primitives,
08:22
and that all necessary connections between the primitives have been made.
08:27
This is to ensure you do not publish something that does not have all necessary logic in place to handle all possible outcomes of the workflow.
08:37
As you can see in our example, primitive 5 was missing a connector.
08:42
But now, we are able to publish successfully.
08:50
When building these change request workflows, there are some things that you may wish to consider.
08:58
Test each one of these primitives in a smaller workflow one at a time,
09:03
so that you can get an understanding of what it does,
09:05
and to ensure it is checking things correctly on items that will deliberately pass or deliberately fail.
09:14
Create two workflows for your end users.
09:17
One that simply checks the data and one that includes these checks but also the approval and release stages.
09:29
Make use of the update primitive as much as possible to keep the change request up to date.
09:35
For example, it might be useful to insert an update primitive in between each approval stage,
09:41
since there are several options that can help describe what stage it's at.
09:49
If you have a mechanical team and an electrical team and they work separately, consider building two separate pathways into the workflow.
09:59
One to follow the electrical approval process and one to follow the mechanical approval process.
10:05
Upchain can't follow each path simultaneously, but it can follow one or the other,
10:10
and check to ensure there isn't a mix of the two item type groups in the same change request.
10:17
It also makes it simpler for your end users to only have one workflow to pick from.
10:26
And of course, the Upchain help documentation contains all information about every setting for every primitive.
10:38
This may have seemed like a lot and we did configure quite a few additional primitives to the out-of-the-box workflow.
10:46
But it should put you in a good position to begin creating workflows like this for yourself.
10:51
So, good luck and happy workflowing.
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.