& Construction

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

Professional CAD/CAM tools built on Inventor and AutoCAD
In this lesson, we’ll demonstrate how to complete the workflow by connecting the primitives together and building out the exception paths. We’ll publish the workflow and then demonstrate its use in Upchain.
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:08
In this video, we'll demonstrate how to connect all the primitives together that we configured in the previous video,
00:14
and publish the workflow for final use.
00:16
So let's take a look.
00:20
Our final task is to connect the primitives together and publish the workflow for final use.
00:28
You always begin by connecting the happy path first.
00:32
The exception path is always configured second.
00:38
You can connect up the entire happy path first from start to finish,
00:43
and then configure any exception path second, or you can work one primitive at a time.
00:49
It's entirely up to you.
00:54
We'll follow the first method.
00:58
Let's connect up all the happy paths first.
01:01
To do this, hover your mouse over one of the four connector points of the starting primitive and then click that connector point.
01:13
Then, with your mouse button still pressed, drag the cursor towards the connector point of the next primitive.
01:21
Then, once your mouse pointer is over the next connector point, release the mouse button.
01:26
And that creates the first happy path from the first to the second primitive.
01:32
You'll notice it's green.
01:33
And we will continue to create our full happy path from start to finish.
01:51
And of course, it's always a good idea to save your work at regular intervals.
01:58
The exception path is always configured second.
02:05
These are necessary to add in for any primitive that has two possible outcomes.
02:10
In our case, the decision primitives can all be either accepted or rejected.
02:19
We've already added in what happens when they are accepted.
02:22
That's the happy path.
02:23
So we need to map out what happens if the decision is rejected, the exception path.
02:30
We specified in the first review step that if the design change has been rejected,
02:37
then an email should be sent to the investigation request creator, notifying them of the decision and the investigation request is canceled.
02:47
In this case, we're going to use the notification primitive again.
02:53
Remember, this primitive can send an email notification to a specific user.
02:57
In our case, we want the work order creator, at the configured location in the workflow,
03:04
and is useful when you need to send additional communications outside of the other primitives,
03:09
that include the option to send an email notification.
03:13
We'll also add in the update primitive to mark the investigation request as canceled if this pathway is followed.
03:23
So let's connect up that exception path.
03:28
So first, it will go to the notification primitive, then, the investigation request will be updated, and finally, it will end.
03:44
And let's save our work.
03:52
The other decision primitive is to review the design, and if it is not acceptable,
03:58
the workflow should loop back to send the design task back to the mechanical designer to keep working.
04:06
So, again, we'll add in another notification primitive to ensure an email is sent to the design team that the work needs further work.
04:16
This is useful here so that the designers receive a different email to the one the task primitive sends.
04:24
You can use this primitive to ensure that the recipients can distinguish between this task being reassigned rather than assigned for the first time.
04:41
We're going to deliberately leave out the name so that the "publish" will fail later, so we can show what this process looks like.
04:52
So, we'll connect up the exception path to that notification primitive,
04:56
and then loop it back to the update primitive so that the investigation request is returned to a work in progress state.
05:04
And then the task will be assigned again to the mechanical designer role.
05:10
You can see that you may need to add in additional primitives into the workflow to handle your desired exception pathways.
05:24
The last thing to do is to publish this workflow.
05:29
Upchain always performs a sanity check on the workflow to ensure you have not missed any necessary settings in the primitives,
05:37
and that all necessary connections between the primitives have been made.
05:41
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.
05:49
In our example, we missed the key setting, the name setting in the notification primitive, so we'll set that here.
06:02
We'll save our changes.
06:06
And now the workflow should publish successfully.
06:15
And we're done. The workflow is now published and ready to use.
06:21
When building investigation request workflows, there are some things to consider.
06:29
User teams are a useful way to group together a number of people that usually perform the same sorts of tasks in a workflow,
06:37
but may not all have the same role in the project team.
06:41
For example, you could create a manufacturing team, a cost approval team and so on.
06:48
By assigning a decision primitive or task primitive to a user team, it doesn't matter if the users in that team change over time.
06:58
Your workflow will stay intact, and the tasks are assigned to whomever exists in that team at the time the workflow is initiated.
07:18
If further tweaks are needed to your published workflow, you can use save as new version to create a new version in a draft state.
07:30
In our example, Version 0 was published, Version 1 has now been created, and is in a draft state.
07:39
We can now edit this to make whatever changes we need to make.
07:43
Then we can publish Version 1 of this workflow, and that will become the new active version that end users will be able to use.
07:57
And of course, the Upchain help documentation contains all information about every setting for every primitive.
08:07
So these videos have demonstrated how to plan, build and publish a specific example of an investigation request workflow,
08:15
meant for the design type of investigation request.
08:18
While we chose a specific example,
08:21
this should put you in a good position to start planning, and building your own investigation request workflows at your organization.
00:08
In this video, we'll demonstrate how to connect all the primitives together that we configured in the previous video,
00:14
and publish the workflow for final use.
00:16
So let's take a look.
00:20
Our final task is to connect the primitives together and publish the workflow for final use.
00:28
You always begin by connecting the happy path first.
00:32
The exception path is always configured second.
00:38
You can connect up the entire happy path first from start to finish,
00:43
and then configure any exception path second, or you can work one primitive at a time.
00:49
It's entirely up to you.
00:54
We'll follow the first method.
00:58
Let's connect up all the happy paths first.
01:01
To do this, hover your mouse over one of the four connector points of the starting primitive and then click that connector point.
01:13
Then, with your mouse button still pressed, drag the cursor towards the connector point of the next primitive.
01:21
Then, once your mouse pointer is over the next connector point, release the mouse button.
01:26
And that creates the first happy path from the first to the second primitive.
01:32
You'll notice it's green.
01:33
And we will continue to create our full happy path from start to finish.
01:51
And of course, it's always a good idea to save your work at regular intervals.
01:58
The exception path is always configured second.
02:05
These are necessary to add in for any primitive that has two possible outcomes.
02:10
In our case, the decision primitives can all be either accepted or rejected.
02:19
We've already added in what happens when they are accepted.
02:22
That's the happy path.
02:23
So we need to map out what happens if the decision is rejected, the exception path.
02:30
We specified in the first review step that if the design change has been rejected,
02:37
then an email should be sent to the investigation request creator, notifying them of the decision and the investigation request is canceled.
02:47
In this case, we're going to use the notification primitive again.
02:53
Remember, this primitive can send an email notification to a specific user.
02:57
In our case, we want the work order creator, at the configured location in the workflow,
03:04
and is useful when you need to send additional communications outside of the other primitives,
03:09
that include the option to send an email notification.
03:13
We'll also add in the update primitive to mark the investigation request as canceled if this pathway is followed.
03:23
So let's connect up that exception path.
03:28
So first, it will go to the notification primitive, then, the investigation request will be updated, and finally, it will end.
03:44
And let's save our work.
03:52
The other decision primitive is to review the design, and if it is not acceptable,
03:58
the workflow should loop back to send the design task back to the mechanical designer to keep working.
04:06
So, again, we'll add in another notification primitive to ensure an email is sent to the design team that the work needs further work.
04:16
This is useful here so that the designers receive a different email to the one the task primitive sends.
04:24
You can use this primitive to ensure that the recipients can distinguish between this task being reassigned rather than assigned for the first time.
04:41
We're going to deliberately leave out the name so that the "publish" will fail later, so we can show what this process looks like.
04:52
So, we'll connect up the exception path to that notification primitive,
04:56
and then loop it back to the update primitive so that the investigation request is returned to a work in progress state.
05:04
And then the task will be assigned again to the mechanical designer role.
05:10
You can see that you may need to add in additional primitives into the workflow to handle your desired exception pathways.
05:24
The last thing to do is to publish this workflow.
05:29
Upchain always performs a sanity check on the workflow to ensure you have not missed any necessary settings in the primitives,
05:37
and that all necessary connections between the primitives have been made.
05:41
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.
05:49
In our example, we missed the key setting, the name setting in the notification primitive, so we'll set that here.
06:02
We'll save our changes.
06:06
And now the workflow should publish successfully.
06:15
And we're done. The workflow is now published and ready to use.
06:21
When building investigation request workflows, there are some things to consider.
06:29
User teams are a useful way to group together a number of people that usually perform the same sorts of tasks in a workflow,
06:37
but may not all have the same role in the project team.
06:41
For example, you could create a manufacturing team, a cost approval team and so on.
06:48
By assigning a decision primitive or task primitive to a user team, it doesn't matter if the users in that team change over time.
06:58
Your workflow will stay intact, and the tasks are assigned to whomever exists in that team at the time the workflow is initiated.
07:18
If further tweaks are needed to your published workflow, you can use save as new version to create a new version in a draft state.
07:30
In our example, Version 0 was published, Version 1 has now been created, and is in a draft state.
07:39
We can now edit this to make whatever changes we need to make.
07:43
Then we can publish Version 1 of this workflow, and that will become the new active version that end users will be able to use.
07:57
And of course, the Upchain help documentation contains all information about every setting for every primitive.
08:07
So these videos have demonstrated how to plan, build and publish a specific example of an investigation request workflow,
08:15
meant for the design type of investigation request.
08:18
While we chose a specific example,
08:21
this should put you in a good position to start planning, and building your own investigation request workflows at your organization.
In this video, let’s test out our workflow. This will demonstrate how the different project team members we specified in our workflow are brought in at specific times to perform their intended task.
Transcript
00:09
In this video, let's test our workflow.
00:12
This will demonstrate how the different project team members we specified in our workflow,
00:17
are brought in at specific times to perform their intended task.
00:21
So let's take a look.
00:24
Let's test this example workflow that we built in the previous videos.
00:28
We'll demonstrate its happy path, logging in as the role that we've chosen for each of the primitives,
00:34
and discuss how it would proceed down the exception paths.
00:38
Remember, this is just an example workflow and the roles and steps will likely be different to the workflows that you build at your organization.
00:50
Note that before you can test a workflow, you need to make sure that all roles, user teams,
00:57
and specific users that you call out in your workflow have been added to the project team.
01:04
If they have not been added, you'll receive an error message that the workflow cannot proceed.
01:10
In our case, we are missing the mechanical designer role.
01:19
All license types can participate in workflows.
01:22
It is the role a user has that determines how and when they may be called to participate in a workflow.
01:36
You can create an investigation request from many locations.
01:46
From the item in the bill of materials section of a project, from the 3D viewer,
02:05
from the 2D PDF viewer if the item has a drawing, from the CAD plugin, where relevant,
02:31
and from scratch from the business processes section of a project.
02:45
I am currently logged in as the quality manager that has reviewed the design in this 3D viewer,
02:52
and I have come up with some design changes that need to be made as outlined in this markup.
03:00
Let's create an investigation request from the 3D viewer.
03:08
In our case, the purpose of the investigation request is to follow our redlining procedure.
03:14
So the type will stay as designed, and we will choose our redlining workflow.
03:25
Now let's fill in the rest of the information.
03:34
We don't specifically call out the assignee in this workflow, but it needs one anyway, so I will just assign it to myself.
03:42
You'll see you get a thumbnail image of the markup that is currently loaded into the 3D viewer.
03:50
You can also add any additional documentation from your computer,
03:54
or that are already associated with this Upchain project that may assist in the design changes required.
04:05
We'll create and start it.
04:14
Now I'm logged in as the lead mechanical designer.
04:17
The first step is a decision task sent to the lead designer on the project.
04:22
You can find this task in several places.
04:27
From the Upchain main dashboard, you'll see the task listed there and the project that it's associated with.
04:36
We go to the project.
04:43
On the project design dashboard, you'll see the assigned task there as well.
04:53
You'll typically receive an email notification as well since we configured that particular setting in the decision primitive.
05:03
And if the lead designer is also a CAD user, they can see their task in the "My Assignment" section of the CAD plug in as well.
05:18
Clicking on the task from any of these locations takes you to the investigation request in the business processes section of the project.
05:31
From here, you can review the information in the investigation request.
05:38
The details tab will contain the additional description that the creator has indicated.
05:47
You can look into the document tab, and here is where you will find a PNG file of the markup that was created.
05:57
This is basically a larger image of the thumbnail.
06:01
You can view the activities tab to see what the current activity is,
06:08
and it's currently at the design change request review stage that is currently in progress.
06:16
You can also view the items tab to confirm which item it is that this investigation request is for.
06:26
And you can view the markups tab and load the markup from here to review the information that the creator has indicated.
06:45
You'll see there are two buttons since there are two decisions to be made.
06:50
Clicking on the "reject" button would send the workflow down the exception path.
06:55
An email would be sent to the investigation request creator saying it was rejected, and the investigation request would be canceled.
07:03
In this case, upon review, it sounds like the changes are necessary, so we will approve this request.
07:27
Now I'm logged in as the mechanical designer to the mechanical CAD plugin.
07:34
The first place I am likely to see that I have a task assigned would be through the email.
07:42
In the CAD plugin, I would also then find that same task and investigation request under the "my assignments" tab of the specific project.
07:54
We can see the details of the investigation request in the lower pane.
08:01
This investigation request also has a documents tab where you can find, again, a screenshot of the markup and it can be downloaded from here.
08:21
The notes tab also indicates any comments that have been added to the investigation request as the decisions were made.
08:38
And we can find the item that needs to be worked on directly here, which can be downloaded from here.
09:07
Let's complete this work.
09:37
Now that the work is complete, let's mark our task as complete.
09:41
There is only one button here since it was a task.
09:45
Again, there is the option to reject the workflow since we configured that, but, otherwise, there is only one option here.
10:08
Now the decision is sent to the lead designer again to review the design changes and ensure it has been done correctly.
10:24
The lead designer would be able to locate the item, review that the necessary changes have been made,
10:44
and then decide whether the work done is approved or if more work was needed, we could reject it and send it back to the designer.
10:54
This would prompt for comments as to why and would then send an email to the designer that their task has been reassigned.
11:04
You'll also notice that there is a button at this stage to create the change request for the items in the investigation request.
11:12
This button is added automatically because we ticked the box to create CR at this stage.
11:21
If the item appears to be ready to be released, you can click this button, and this creates the change request.
11:48
Note, however, that creating a change request does not automatically mark the investigation request as complete.
11:55
You still need to go back to it and click the appropriate decision button to finish the workflow.
12:02
But if you do intend on sending the items to a change request,
12:07
you must do this before you click these other options here before completing the investigation request.
12:18
Our change request has been created.
12:21
We're not going to complete it here, but you can see it listed as now a child of this investigation request.
12:29
And we'll mark this investigation request as approved.
12:49
Now logged in as the quality manager, the user who initially created the investigation request,
12:55
here is the email that is received to indicate that the investigation request has been completed.
13:08
Viewing the item and loading its 3D viewer, you can see that the previous markup has been removed.
13:15
And that's because the markup was relevant to the previous file version.
13:22
And that has now been updated with the newest design changes.
13:30
We can now review this to make sure everything looks okay.
13:37
Looking at the investigation request itself,
13:40
the Notes tab is where you can view all comments that were added to the investigation request as the decision makers made their decisions.
13:50
And the original markup can still be found here as well.
14:02
The original image that was created is still saved on this investigation request as well.
14:10
You can also see that the change request that was created from the investigation request is listed here.
14:23
And on that change request, in the Relationships tab, the investigation request has been linked to this change request.
14:40
So we have demonstrated how our configured workflow will work in practice based on the primitives and options we chose.
14:48
This should give you a better understanding of how you can bring in many different people into your workflows,
14:54
and ensure the same procedure with the appropriate people is followed every time.
00:09
In this video, let's test our workflow.
00:12
This will demonstrate how the different project team members we specified in our workflow,
00:17
are brought in at specific times to perform their intended task.
00:21
So let's take a look.
00:24
Let's test this example workflow that we built in the previous videos.
00:28
We'll demonstrate its happy path, logging in as the role that we've chosen for each of the primitives,
00:34
and discuss how it would proceed down the exception paths.
00:38
Remember, this is just an example workflow and the roles and steps will likely be different to the workflows that you build at your organization.
00:50
Note that before you can test a workflow, you need to make sure that all roles, user teams,
00:57
and specific users that you call out in your workflow have been added to the project team.
01:04
If they have not been added, you'll receive an error message that the workflow cannot proceed.
01:10
In our case, we are missing the mechanical designer role.
01:19
All license types can participate in workflows.
01:22
It is the role a user has that determines how and when they may be called to participate in a workflow.
01:36
You can create an investigation request from many locations.
01:46
From the item in the bill of materials section of a project, from the 3D viewer,
02:05
from the 2D PDF viewer if the item has a drawing, from the CAD plugin, where relevant,
02:31
and from scratch from the business processes section of a project.
02:45
I am currently logged in as the quality manager that has reviewed the design in this 3D viewer,
02:52
and I have come up with some design changes that need to be made as outlined in this markup.
03:00
Let's create an investigation request from the 3D viewer.
03:08
In our case, the purpose of the investigation request is to follow our redlining procedure.
03:14
So the type will stay as designed, and we will choose our redlining workflow.
03:25
Now let's fill in the rest of the information.
03:34
We don't specifically call out the assignee in this workflow, but it needs one anyway, so I will just assign it to myself.
03:42
You'll see you get a thumbnail image of the markup that is currently loaded into the 3D viewer.
03:50
You can also add any additional documentation from your computer,
03:54
or that are already associated with this Upchain project that may assist in the design changes required.
04:05
We'll create and start it.
04:14
Now I'm logged in as the lead mechanical designer.
04:17
The first step is a decision task sent to the lead designer on the project.
04:22
You can find this task in several places.
04:27
From the Upchain main dashboard, you'll see the task listed there and the project that it's associated with.
04:36
We go to the project.
04:43
On the project design dashboard, you'll see the assigned task there as well.
04:53
You'll typically receive an email notification as well since we configured that particular setting in the decision primitive.
05:03
And if the lead designer is also a CAD user, they can see their task in the "My Assignment" section of the CAD plug in as well.
05:18
Clicking on the task from any of these locations takes you to the investigation request in the business processes section of the project.
05:31
From here, you can review the information in the investigation request.
05:38
The details tab will contain the additional description that the creator has indicated.
05:47
You can look into the document tab, and here is where you will find a PNG file of the markup that was created.
05:57
This is basically a larger image of the thumbnail.
06:01
You can view the activities tab to see what the current activity is,
06:08
and it's currently at the design change request review stage that is currently in progress.
06:16
You can also view the items tab to confirm which item it is that this investigation request is for.
06:26
And you can view the markups tab and load the markup from here to review the information that the creator has indicated.
06:45
You'll see there are two buttons since there are two decisions to be made.
06:50
Clicking on the "reject" button would send the workflow down the exception path.
06:55
An email would be sent to the investigation request creator saying it was rejected, and the investigation request would be canceled.
07:03
In this case, upon review, it sounds like the changes are necessary, so we will approve this request.
07:27
Now I'm logged in as the mechanical designer to the mechanical CAD plugin.
07:34
The first place I am likely to see that I have a task assigned would be through the email.
07:42
In the CAD plugin, I would also then find that same task and investigation request under the "my assignments" tab of the specific project.
07:54
We can see the details of the investigation request in the lower pane.
08:01
This investigation request also has a documents tab where you can find, again, a screenshot of the markup and it can be downloaded from here.
08:21
The notes tab also indicates any comments that have been added to the investigation request as the decisions were made.
08:38
And we can find the item that needs to be worked on directly here, which can be downloaded from here.
09:07
Let's complete this work.
09:37
Now that the work is complete, let's mark our task as complete.
09:41
There is only one button here since it was a task.
09:45
Again, there is the option to reject the workflow since we configured that, but, otherwise, there is only one option here.
10:08
Now the decision is sent to the lead designer again to review the design changes and ensure it has been done correctly.
10:24
The lead designer would be able to locate the item, review that the necessary changes have been made,
10:44
and then decide whether the work done is approved or if more work was needed, we could reject it and send it back to the designer.
10:54
This would prompt for comments as to why and would then send an email to the designer that their task has been reassigned.
11:04
You'll also notice that there is a button at this stage to create the change request for the items in the investigation request.
11:12
This button is added automatically because we ticked the box to create CR at this stage.
11:21
If the item appears to be ready to be released, you can click this button, and this creates the change request.
11:48
Note, however, that creating a change request does not automatically mark the investigation request as complete.
11:55
You still need to go back to it and click the appropriate decision button to finish the workflow.
12:02
But if you do intend on sending the items to a change request,
12:07
you must do this before you click these other options here before completing the investigation request.
12:18
Our change request has been created.
12:21
We're not going to complete it here, but you can see it listed as now a child of this investigation request.
12:29
And we'll mark this investigation request as approved.
12:49
Now logged in as the quality manager, the user who initially created the investigation request,
12:55
here is the email that is received to indicate that the investigation request has been completed.
13:08
Viewing the item and loading its 3D viewer, you can see that the previous markup has been removed.
13:15
And that's because the markup was relevant to the previous file version.
13:22
And that has now been updated with the newest design changes.
13:30
We can now review this to make sure everything looks okay.
13:37
Looking at the investigation request itself,
13:40
the Notes tab is where you can view all comments that were added to the investigation request as the decision makers made their decisions.
13:50
And the original markup can still be found here as well.
14:02
The original image that was created is still saved on this investigation request as well.
14:10
You can also see that the change request that was created from the investigation request is listed here.
14:23
And on that change request, in the Relationships tab, the investigation request has been linked to this change request.
14:40
So we have demonstrated how our configured workflow will work in practice based on the primitives and options we chose.
14:48
This should give you a better understanding of how you can bring in many different people into your workflows,
14:54
and ensure the same procedure with the appropriate people is followed every time.