& 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 discuss how to plan out an Investigation request workflow and the things to consider when doing so. We’ll discuss some of the possibilities that Upchain can provide within an Investigation request workflow and scope out an example workflow that looks at a redlining process.
Think about the sorts of business processes you already have in place in your organization that you use for investigation-type purposes, such as scoping out initial designs, feasibility studies, incorporating customer feedback, redlines from a shop floor technician, design change instructions, etc.
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:09
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:21
So let's take a look.
00:24
Why should we create our business processes in Upchain?
00:28
Well, by having a workflow agreed upon and built in Upchain,
00:32
it means Upchain ensures the same process is followed every time a specific business process must be used,
00:39
and everything related to that process can be tracked and saved in one location.
00:45
As you may have learned in previous courses, workflows govern the lifecycle of many different objects in Upchain, not just items.
00:53
And each one has a specific purpose.
00:58
One of these objects is the investigation request.
01:02
These can be used to initiate the change process and determine the impact of the change and the best possible solution.
01:10
They help to promote discussions and collaboration within your organization or with partners and suppliers.
01:20
One thing to note is that investigation requests fall into two categories, design and supplier RFQs.
01:29
Design types are meant to capture the investigation type processes that stay within your organization.
01:36
Whereas supplier RFQs are used when you wish to share information with specific suppliers and have them send you a quote.
01:47
The investigation type determines who the available assignees are for the investigation request, not the available workflows.
01:55
We'll come back to this point in a moment.
02:01
There is a lot of flexibility when it comes to how you wish to use investigation requests at your organization,
02:08
and it all comes down to the workflows you build.
02:12
If you've got multiple investigative type business processes you already follow,
02:17
you can build separate investigation request workflows in Upchain to capture each one.
02:28
Importantly, when you create a new investigation request,
02:32
you can select any of the workflows that have been created for investigation requests, regardless of their intended purpose or the IR type.
02:43
Therefore, it is important that you name your workflows accordingly,
02:47
so that it is clear whether they are intended for design investigation requests or supplier RFQs.
03:00
Before building any workflow in Upchain, you should plan out what your desired business process is.
03:07
Some questions to help you start thinking in the right direction are: Who might initiate an investigation request?
03:17
What are different scenarios that would warrant an investigation request?
03:22
For example, scoping out initial designs, feasibility studies, incorporating customer feedback,
03:29
red lines from a shop floor technician, design change instructions and so on.
03:36
Who will be responsible for completing each step?
03:41
What are the criteria needed to mark an investigation request as complete?
03:48
What would be some reasons why an investigation request could not be completed or need to be restarted?
03:56
Will it involve external suppliers or not?
04:00
Are there any additional actions that should occur at each step, such as additional notifications, status updates and so on?
04:13
Here, at our example company, we want to plan out a workflow that captures the full redlining procedure that we already follow.
04:21
This is intended to be used in a design investigation request type.
04:26
It is important that proper communication is adhered to at all times,
04:31
so that all parties involved are kept updated on the progress of the investigation request.
04:39
So it begins that anyone who identifies issues in the design creates an investigation request for the item from a 3D markup,
04:49
a 2D markup, or the item directly.
04:53
This user could be any team member at our organization.
04:60
The lead designer for the project must review and either approve or reject the request for a design change.
05:07
If approved, the design change request is sent to the mechanical design team on the projects, one of whom will actually address the task.
05:18
If rejected, an email is sent to the investigation request creator as to why, and the investigation request is canceled and no further work is done.
05:32
If approved, then the design team does the work as outlined in the investigation request and the accompanying markups if they exist.
05:41
The lead designer of the project must then review the design work and either approve or reject it.
05:50
Again, if approved, an email is sent to the investigation request creator to say that the work is complete.
05:58
The item is then sent to a change request to release the item if desired.
06:05
If rejected, the work is sent back to the design team to try again, Step 3, and loops back through the approval process again.
06:17
Some requirements that we will also want to make sure are enforced in this workflow are: we need to be able to cancel the workflow at any stage,
06:28
any decision steps must enforce the approval and rejection comments to track all decisions and the reasoning behind them,
06:40
and we want the possibility to send the items directly to a change request from the investigation request.
06:51
So this is our desired business process that we would like to build in Upchain.
06:56
So how can Upchain help with this?
06:59
This workflow is not too complicated and mostly involves user participation.
07:04
The important thing is that this same order and procedure is followed every time we follow the redlining procedure.
07:13
So we'll build it into our workflow in Upchain.
07:17
We can use the following primitives in our workflow.
07:23
The decision primitive is used to assign a decision task to a single person, everyone with a specific role on the project team,
07:32
or a group of people on the project team.
07:36
You can further specify how many people must complete this task before it'll move on.
07:42
This is a good primitive to use to track acceptance or rejection comments,
07:47
and loop your workflow back to the appropriate step to try again if it's been rejected rather than cancel the workflow outright.
07:55
We will use this primitive for each decision point in our workflow, Steps 2 and 4.
08:08
The task primitive is used to simply assign a task to a specific user, specific role, or a user team on the project.
08:17
This is useful to ensure the assignee understands it's their turn to perform their assigned work before marking it as complete.
08:25
We'll use this for Step 3.
08:31
The notification primitive is useful if you wish to send an email notification to specific users at certain points in the workflow.
08:40
These are notifications that work in addition to the ones that you can configure other primitives to send,
08:47
and they allow you to send an email at a time in the workflow when no other primitive is available to send a notification.
08:56
These are useful in keeping certain users up to date of on the progress the workflow.
09:01
So we'll use these for steps 2 and 4 to let the appropriate parties know what's going on when a decision has been approved or rejected.
09:15
And of course, we'll also include the other necessary primitives in all workflows, the start, stop,
09:22
and update primitives as they exist in all other workflows in Upchain.
09:31
This video should get you thinking about what might be possible with Upchain,
09:35
and how you can start to translate your existing business processes into an investigation request workflow where applicable.
09:43
Please review the Upchain help documentation to review the capabilities of these primitives, as well as the additional primitives not discussed here.
09:52
But don't worry about fully understanding them just now.
09:55
We'll build our example workflow in Upchain in this lesson to demonstrate how each of the primitives listed here are configured.
10:03
Keep going.
00:09
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:21
So let's take a look.
00:24
Why should we create our business processes in Upchain?
00:28
Well, by having a workflow agreed upon and built in Upchain,
00:32
it means Upchain ensures the same process is followed every time a specific business process must be used,
00:39
and everything related to that process can be tracked and saved in one location.
00:45
As you may have learned in previous courses, workflows govern the lifecycle of many different objects in Upchain, not just items.
00:53
And each one has a specific purpose.
00:58
One of these objects is the investigation request.
01:02
These can be used to initiate the change process and determine the impact of the change and the best possible solution.
01:10
They help to promote discussions and collaboration within your organization or with partners and suppliers.
01:20
One thing to note is that investigation requests fall into two categories, design and supplier RFQs.
01:29
Design types are meant to capture the investigation type processes that stay within your organization.
01:36
Whereas supplier RFQs are used when you wish to share information with specific suppliers and have them send you a quote.
01:47
The investigation type determines who the available assignees are for the investigation request, not the available workflows.
01:55
We'll come back to this point in a moment.
02:01
There is a lot of flexibility when it comes to how you wish to use investigation requests at your organization,
02:08
and it all comes down to the workflows you build.
02:12
If you've got multiple investigative type business processes you already follow,
02:17
you can build separate investigation request workflows in Upchain to capture each one.
02:28
Importantly, when you create a new investigation request,
02:32
you can select any of the workflows that have been created for investigation requests, regardless of their intended purpose or the IR type.
02:43
Therefore, it is important that you name your workflows accordingly,
02:47
so that it is clear whether they are intended for design investigation requests or supplier RFQs.
03:00
Before building any workflow in Upchain, you should plan out what your desired business process is.
03:07
Some questions to help you start thinking in the right direction are: Who might initiate an investigation request?
03:17
What are different scenarios that would warrant an investigation request?
03:22
For example, scoping out initial designs, feasibility studies, incorporating customer feedback,
03:29
red lines from a shop floor technician, design change instructions and so on.
03:36
Who will be responsible for completing each step?
03:41
What are the criteria needed to mark an investigation request as complete?
03:48
What would be some reasons why an investigation request could not be completed or need to be restarted?
03:56
Will it involve external suppliers or not?
04:00
Are there any additional actions that should occur at each step, such as additional notifications, status updates and so on?
04:13
Here, at our example company, we want to plan out a workflow that captures the full redlining procedure that we already follow.
04:21
This is intended to be used in a design investigation request type.
04:26
It is important that proper communication is adhered to at all times,
04:31
so that all parties involved are kept updated on the progress of the investigation request.
04:39
So it begins that anyone who identifies issues in the design creates an investigation request for the item from a 3D markup,
04:49
a 2D markup, or the item directly.
04:53
This user could be any team member at our organization.
04:60
The lead designer for the project must review and either approve or reject the request for a design change.
05:07
If approved, the design change request is sent to the mechanical design team on the projects, one of whom will actually address the task.
05:18
If rejected, an email is sent to the investigation request creator as to why, and the investigation request is canceled and no further work is done.
05:32
If approved, then the design team does the work as outlined in the investigation request and the accompanying markups if they exist.
05:41
The lead designer of the project must then review the design work and either approve or reject it.
05:50
Again, if approved, an email is sent to the investigation request creator to say that the work is complete.
05:58
The item is then sent to a change request to release the item if desired.
06:05
If rejected, the work is sent back to the design team to try again, Step 3, and loops back through the approval process again.
06:17
Some requirements that we will also want to make sure are enforced in this workflow are: we need to be able to cancel the workflow at any stage,
06:28
any decision steps must enforce the approval and rejection comments to track all decisions and the reasoning behind them,
06:40
and we want the possibility to send the items directly to a change request from the investigation request.
06:51
So this is our desired business process that we would like to build in Upchain.
06:56
So how can Upchain help with this?
06:59
This workflow is not too complicated and mostly involves user participation.
07:04
The important thing is that this same order and procedure is followed every time we follow the redlining procedure.
07:13
So we'll build it into our workflow in Upchain.
07:17
We can use the following primitives in our workflow.
07:23
The decision primitive is used to assign a decision task to a single person, everyone with a specific role on the project team,
07:32
or a group of people on the project team.
07:36
You can further specify how many people must complete this task before it'll move on.
07:42
This is a good primitive to use to track acceptance or rejection comments,
07:47
and loop your workflow back to the appropriate step to try again if it's been rejected rather than cancel the workflow outright.
07:55
We will use this primitive for each decision point in our workflow, Steps 2 and 4.
08:08
The task primitive is used to simply assign a task to a specific user, specific role, or a user team on the project.
08:17
This is useful to ensure the assignee understands it's their turn to perform their assigned work before marking it as complete.
08:25
We'll use this for Step 3.
08:31
The notification primitive is useful if you wish to send an email notification to specific users at certain points in the workflow.
08:40
These are notifications that work in addition to the ones that you can configure other primitives to send,
08:47
and they allow you to send an email at a time in the workflow when no other primitive is available to send a notification.
08:56
These are useful in keeping certain users up to date of on the progress the workflow.
09:01
So we'll use these for steps 2 and 4 to let the appropriate parties know what's going on when a decision has been approved or rejected.
09:15
And of course, we'll also include the other necessary primitives in all workflows, the start, stop,
09:22
and update primitives as they exist in all other workflows in Upchain.
09:31
This video should get you thinking about what might be possible with Upchain,
09:35
and how you can start to translate your existing business processes into an investigation request workflow where applicable.
09:43
Please review the Upchain help documentation to review the capabilities of these primitives, as well as the additional primitives not discussed here.
09:52
But don't worry about fully understanding them just now.
09:55
We'll build our example workflow in Upchain in this lesson to demonstrate how each of the primitives listed here are configured.
10:03
Keep going.
In this video, we’ll start to build the workflow that we outlined in the first video by adding and configuring the primitives we need in our optimal path.
Transcript
00:08
In this video, we'll start to build the workflow that we outlined in the first video,
00:12
by adding and configuring the primitives we need in our optimal path.
00:16
So let's take a look.
00:20
Let's start putting together the workflow that we outlined in the previous video.
00:26
We'll create it from scratch since there isn't much from the existing system workflow that we need.
00:33
Let's call it "Redlining Workflow".
00:36
Remember, this workflow is intended for the design type investigation request, but there is no distinguishing that here.
00:52
Every workflow must have a start and stop primitive, so let's add those in first.
01:07
Also, remember that it is useful to have update primitives throughout the workflow to keep the status of the investigation request up to date.
01:16
This helps others, who may be reviewing the list of investigation requests, know where it is currently at.
01:26
For our workflow, our first update primitive, we will set the status to "Engineering Review",
01:33
since it is the lead designer on the project who must first review and approve the requested work.
01:45
The first step in the workflow is that the lead designer on the project must review the request for a design change and approve or reject it.
01:54
For this, we will use the decision primitive.
01:58
This primitive presents a decision task to a single user, anyone with a specific role, or a group of people on the project team.
02:08
This decision can be made by one person or a group of people.
02:13
Let's configure it.
02:15
We'll give it an appropriate name,
02:29
and we'll fill out the notes so that anyone looking at this workflow in the canvas knows what this primitive is for.
02:40
For this decision, we'll set it to the generic decision type.
02:44
This means only one person has to make the decision for the workflow to proceed even if there are more than one assignee.
02:53
However, you could also choose the quorum decision.
02:57
This means that more than one person needs to approve the decision before the workflow moves on along the happy path.
03:05
You set the specific percentage of all assignees that must approve the decision here.
03:11
If any one assignee rejects the decision, it automatically moves the workflow down the exception path, even if other assignees approve.
03:21
So consider using this decision when you need guaranteed multiple eyes on a specific decision step.
03:37
We'll tick these two boxes to enforce the requirement that the decision maker must enter a comment into the investigation request,
03:47
regardless of which decision they make.
03:54
The decision maker receives two options when making their decision.
03:58
The user command is the button the decision maker clicks to approve the data and send the workflow down the happy path or the green path.
04:09
The user command rejected is the button the decision maker clicks to reject the data and send the workflow down the exception path.
04:18
Let's add in a task description so that the assignee knows what they are meant to do at this stage.
04:24
Be as descriptive as possible so that the assignee understands what they are meant to do.
04:33
Since we want to be able to use this workflow across many different projects,
04:37
we don't want to call out a specific person by name, rather we'll set the assignee to the role of lead mechanical designer.
04:45
That way, whoever holds that role on the project will receive the decision task when someone initiates this workflow.
04:55
We'll also tick the box to allow workflow cancellation.
04:58
This allows you to completely back out of the investigation request workflow and immediately cancel it.
05:04
This could be useful if the investigation request was created by accident or contains the wrong information.
05:12
And lastly, we'll tick the box to send an email notification.
05:16
While the task will appear in various "My assignments areas" throughout Upchain, without this option checked,
05:22
the assignee of the decision may not be immediately aware that they have a new task assigned.
05:30
Let's save our work.
05:39
The next step is to send a task to the designer to perform the requested design changes.
05:45
First, though, we'll add in an update primitive to update the status of the investigation request to work in progress.
06:03
And for the task, we'll use the task primitive since the designer simply needs to be assigned the work to do and then mark it as complete.
06:17
We'll assign it to the role of the mechanical designer,
06:21
and that way anyone with that role on the project can complete it, allowing for some flexibility.
06:37
We'll fill out the task details again,
06:47
and we'll ensure we send an email notification, and allow workflow cancellation.
06:54
This is optional.
07:02
And again, let's save our work.
07:11
Then once the design changes have been made,
07:15
they must be reviewed again by the lead designer before they can sign off on the work and potentially send the item to a change request.
07:24
So, again, we'll add in an update primitive to update the status of the investigation request to "Approval Pending".
07:42
And then we will add in the decision task.
07:49
We'll clone this decision primitive to create the second decision primitive since the majority of the settings are the same.
07:59
We'll update the name to reflect what this decision is for as well as the notes.
08:18
Again, it's a generic decision.
08:22
We want comments on the decisions made.
08:26
The "Approved" button can remain the same.
08:28
We'll rename the "Rejection" button to make it clear what that it will do.
08:37
And we'll update the task description, again,
08:40
so the decision maker understands what stage this investigation request is at and what they are meant to do.
08:53
And all other settings remain the same.
08:55
Again, it's the lead mechanical designer assigned this decision.
09:00
We are also going to tick the box to create a change request at this stage,
09:06
and this will allow the lead designer to send the items in the investigation request directly to a change request at this stage,
09:20
and again, save our work.
09:25
Communication is key.
09:27
So, in this case, we're going to introduce another primitive, the notification primitive type.
09:36
This primitive can send an email notification to specific users at the configured location in the workflow,
09:43
and is useful when you need to send additional communications outside of the other primitives,
09:49
that include the option to send an email notification.
09:53
In our example, we need to be able to send an email to the investigation request creator that the work has been completed and approved,
10:02
so that they are kept up to date.
10:07
So we will assign this to the work order creator.
10:09
That's the investigation request creator.
10:20
You should fill out the notification details as this will appear in the email that is sent so that the recipient understands what the email is about.
10:35
We also need to tick the box to send an email notification as there are currently no other areas in Upchain that this notification appears,
10:44
so an email must be sent.
10:54
Lastly, we'll add a final update primitive to mark the investigation request as complete.
11:11
And we'll save our changes.
11:15
So, we're almost there.
11:17
We've configured the key steps we need in our optimal path.
11:21
We still need to connect these primitives together and configure any exception paths that may exist.
11:27
So keep going.
00:08
In this video, we'll start to build the workflow that we outlined in the first video,
00:12
by adding and configuring the primitives we need in our optimal path.
00:16
So let's take a look.
00:20
Let's start putting together the workflow that we outlined in the previous video.
00:26
We'll create it from scratch since there isn't much from the existing system workflow that we need.
00:33
Let's call it "Redlining Workflow".
00:36
Remember, this workflow is intended for the design type investigation request, but there is no distinguishing that here.
00:52
Every workflow must have a start and stop primitive, so let's add those in first.
01:07
Also, remember that it is useful to have update primitives throughout the workflow to keep the status of the investigation request up to date.
01:16
This helps others, who may be reviewing the list of investigation requests, know where it is currently at.
01:26
For our workflow, our first update primitive, we will set the status to "Engineering Review",
01:33
since it is the lead designer on the project who must first review and approve the requested work.
01:45
The first step in the workflow is that the lead designer on the project must review the request for a design change and approve or reject it.
01:54
For this, we will use the decision primitive.
01:58
This primitive presents a decision task to a single user, anyone with a specific role, or a group of people on the project team.
02:08
This decision can be made by one person or a group of people.
02:13
Let's configure it.
02:15
We'll give it an appropriate name,
02:29
and we'll fill out the notes so that anyone looking at this workflow in the canvas knows what this primitive is for.
02:40
For this decision, we'll set it to the generic decision type.
02:44
This means only one person has to make the decision for the workflow to proceed even if there are more than one assignee.
02:53
However, you could also choose the quorum decision.
02:57
This means that more than one person needs to approve the decision before the workflow moves on along the happy path.
03:05
You set the specific percentage of all assignees that must approve the decision here.
03:11
If any one assignee rejects the decision, it automatically moves the workflow down the exception path, even if other assignees approve.
03:21
So consider using this decision when you need guaranteed multiple eyes on a specific decision step.
03:37
We'll tick these two boxes to enforce the requirement that the decision maker must enter a comment into the investigation request,
03:47
regardless of which decision they make.
03:54
The decision maker receives two options when making their decision.
03:58
The user command is the button the decision maker clicks to approve the data and send the workflow down the happy path or the green path.
04:09
The user command rejected is the button the decision maker clicks to reject the data and send the workflow down the exception path.
04:18
Let's add in a task description so that the assignee knows what they are meant to do at this stage.
04:24
Be as descriptive as possible so that the assignee understands what they are meant to do.
04:33
Since we want to be able to use this workflow across many different projects,
04:37
we don't want to call out a specific person by name, rather we'll set the assignee to the role of lead mechanical designer.
04:45
That way, whoever holds that role on the project will receive the decision task when someone initiates this workflow.
04:55
We'll also tick the box to allow workflow cancellation.
04:58
This allows you to completely back out of the investigation request workflow and immediately cancel it.
05:04
This could be useful if the investigation request was created by accident or contains the wrong information.
05:12
And lastly, we'll tick the box to send an email notification.
05:16
While the task will appear in various "My assignments areas" throughout Upchain, without this option checked,
05:22
the assignee of the decision may not be immediately aware that they have a new task assigned.
05:30
Let's save our work.
05:39
The next step is to send a task to the designer to perform the requested design changes.
05:45
First, though, we'll add in an update primitive to update the status of the investigation request to work in progress.
06:03
And for the task, we'll use the task primitive since the designer simply needs to be assigned the work to do and then mark it as complete.
06:17
We'll assign it to the role of the mechanical designer,
06:21
and that way anyone with that role on the project can complete it, allowing for some flexibility.
06:37
We'll fill out the task details again,
06:47
and we'll ensure we send an email notification, and allow workflow cancellation.
06:54
This is optional.
07:02
And again, let's save our work.
07:11
Then once the design changes have been made,
07:15
they must be reviewed again by the lead designer before they can sign off on the work and potentially send the item to a change request.
07:24
So, again, we'll add in an update primitive to update the status of the investigation request to "Approval Pending".
07:42
And then we will add in the decision task.
07:49
We'll clone this decision primitive to create the second decision primitive since the majority of the settings are the same.
07:59
We'll update the name to reflect what this decision is for as well as the notes.
08:18
Again, it's a generic decision.
08:22
We want comments on the decisions made.
08:26
The "Approved" button can remain the same.
08:28
We'll rename the "Rejection" button to make it clear what that it will do.
08:37
And we'll update the task description, again,
08:40
so the decision maker understands what stage this investigation request is at and what they are meant to do.
08:53
And all other settings remain the same.
08:55
Again, it's the lead mechanical designer assigned this decision.
09:00
We are also going to tick the box to create a change request at this stage,
09:06
and this will allow the lead designer to send the items in the investigation request directly to a change request at this stage,
09:20
and again, save our work.
09:25
Communication is key.
09:27
So, in this case, we're going to introduce another primitive, the notification primitive type.
09:36
This primitive can send an email notification to specific users at the configured location in the workflow,
09:43
and is useful when you need to send additional communications outside of the other primitives,
09:49
that include the option to send an email notification.
09:53
In our example, we need to be able to send an email to the investigation request creator that the work has been completed and approved,
10:02
so that they are kept up to date.
10:07
So we will assign this to the work order creator.
10:09
That's the investigation request creator.
10:20
You should fill out the notification details as this will appear in the email that is sent so that the recipient understands what the email is about.
10:35
We also need to tick the box to send an email notification as there are currently no other areas in Upchain that this notification appears,
10:44
so an email must be sent.
10:54
Lastly, we'll add a final update primitive to mark the investigation request as complete.
11:11
And we'll save our changes.
11:15
So, we're almost there.
11:17
We've configured the key steps we need in our optimal path.
11:21
We still need to connect these primitives together and configure any exception paths that may exist.
11:27
So keep going.