How to Automate Release Process with Upchain

ANDREJA SCHNEIDER: Hello and welcome. Today's topic is how to automate release process within Upchain. I'm your host for today. My name is Andreja Schneider, and I'm a product manager within Autodesk.

Let's start with safe harbor statement. First, note that Autodesk University content is proprietary. Do not copy, post, or distribute without expressed permission.

Moving over to some learning objectives of today. Today, we will learn about benefits of automated release process. We will show how you can create an electrical design workflow and how you can incorporate electrical design checks into that final workflow, same we will do with mechanical design workflow. We will add to it also some item attributes and categorization checks, and after that one, we will create a quorum decision workflow and show you how you can benefit with auto quorum decision.

With all those different workflow types and objects embedded into your workflow, we can show you how you can take advantage and create one big release workflow, incorporating both mechanical and electrical design process. At the end, we will review what kind of audit trail information of data checks and user decisions you can find within Upchain.

So let's start with lesson one-- why workflow automation? First thing that might pop to mind is that it saves time, effort, and money. Additionally to that, I would add that it allows increase in productivity and efficiency. It brings increased production output. It lowers operating costs.

It gives ability to be more competitive. It also enables consistent and improved part production and better planning. One more important thing-- that it leaves an audit trail of each data checks or user required change.

I'm going on to some benefits of Upchain workflows. They are adjustable, so you can create a workflow based on your organizational needs. There are also tenant versus system-based. You can choose to use Upchain out-of-the-box workflow, or you can create a new tenant [INAUDIBLE] just for your organization.

Your organization can be dictate the workflow size. So just have a workflow based on specific design your organization uses and have multiple them or merge multiple design workflows into one big workflow used for any need. Same workflow can be shared between multiple divisions.

So this is in case your organization has multiple divisions. Assigning a workflow to a division can make it available for some and hidden from other divisions. And this is all within the same organization.

Workflows are also exportable but also importable. This is very useful in case there is a need of copying a workflow design across tenants or even environments. And also take advantage of Upchain workflow versioning and variation and use those as much as you can, especially when going through trial and error of building your own tenant workforce. So before we dive into our first-- I would just like to say we will not build a workflow from scratch. We will start with Upchain out-of-the-box workflow.

So looking at the picture above, you will notice an out-of-the-box workflow as it is designed and visible today in our Upchain administration. So starting with primitive one, we are starting the workflow. After that, we are testing to update primitive number two to update the CR to work-in-progress status.

Primitive three is updating items item status [INAUDIBLE]. This is very important, because this status [INAUDIBLE] information and preserving item data from being changed while workflow is progressing and making necessary data checks. After that, a task is created for project manager role to either release or to cancel the workflow.

If project manager approves, workflow is making adjustments to items and files and releasing the data using processing primitive number five. There is also a retry mechanism in primitive six if anything goes wrong with release process. [INAUDIBLE] passes the workflow, we follow the green line from 5 to 7 and complete the CR.

Let's see how this workflow looks like when it's used within the CR. So in here I have created a simple CR. I have associated one model design to it, and I'm starting a CR workflow using out-of-the-box Upchain workflow. It updates the item status, updates the CR status, and it's creating a task for a project manager.

This user can then say release the items or reject the design. And for the sake of this demo, we will say release the items. Items go through the release process. Item is updated, files are updated, and you can review the information to reach the workflow task in the Workflow Actions tab of your CR.

Let's go forward to electrical design workflow. First of all, here we are trying to determine whether there is a mix of both mechanical and electrical assemblies submitted for release process in one CR. If you have in your organization designer responsible for mechanical design and then a designer responsible for electrical design, one would not like to get a task to correct the data for the other. They simply cannot.

For this reason, you would make sure that no one has submitted a mix of electrical and mechanical assemblies into one release process. Only one or the other is allowed. This is how this is achieved.

So primitive number 7 is checking for either purchased electrical part or electrical package. If such is found, it will follow the red line to number 12. If this is not found, that means there are no electrical assemblies in the CR. It will go to number 5, which is a task.

Number 5 is instructing the PM that no electrical design is found. And since this is an electrical-exclusive workflow, the PM is instructed to cancel the CR. If electrical design is found, we're making sure still there is no mechanical design just by some accident in the same CR. And that is done within primitive number 12.

If mechanical items are found, the work passes to task for a PM to reject the workflow. Note that this is only recommended if you're using both mechanical and electrical design in your organization. If you're using only one, this check would be redundant.

Same case, only electrical items are present. Such are updated to approval pending state with primitive 14. We are moving then to primitive number 9, which is checking that any found electrical package item need to have both a PDF and Excel file associated.

Say your organization dictates that each electrical design comes with electrical plan, which is exported out of electrical system in form of a PDF that to be used in downstream processes even beyond Upchain. If such file is missing, workflow will stop and create a task for recorder creator to correct the form. There is also a recheck criteria turned on, which makes sure user cannot proceed with workflow until missing files have been uploaded.

Let's continue with the demo of this feature. In here, I have my electrical design submitted within the CR workflow. You can see I associate this electrical design workflow with this CR, and I'm starting the workflow. The workflow will go through necessary data checks. And if something found missing, workflow will stop and create a task for recorder creator.

Before reviewing the task information, user can see which kind of files are missing. Here, user goes into the item details and check that there is no drawing file associated with this item. Using the benefits of Upchain, user can go in and input the drawing directly to the electrical package. In this case, I'm selecting a PDF and waiting for upload to be done.

I'll just refresh the item and make sure that file is actually there and open the drawing segment within the documents. After that, user can click on a task, saying that electrical CAD is filled in. Workflow will make a recheck if this file is actually there, and if all is good, you proceed further.

Next after that, we have a task for a PM to either approve the design or reject the design. For the sake of the demo, we will say a PM will proceed with the release. Now items have been released. You can see that work is finished, and the CR is in completed status.

Moving on to mechanical design. It has the same checks which prevents a mix of mechanical and electrical design assemblies. And workflow will proceed toward mechanical design false checks only if mechanical items are found. With primitive number 5, we are checking whether our product structure and assembly or manufactured item have a drawing file associated. And those should be either in a DWG form or in PDF form.

Same as before, drawing is used in downstream processes. It is shared with collaborators outside the organization and, as such, must be part of release titles. After assessment and files check, there is a check from [INAUDIBLE] This will make sure that parent assembly does not contain an outdated CAD data for child items.

If a child file version mismatch file version under parent, a task will be created for a user to correct the parent assembly. Proceed with the demo. Here, I have associated a mechanical design workflow with this mechanical assembly.

I am reviewing the data under this part, and one model is associated. Please note that drawing is missing. It will display no data.

So I'm starting my workflow. The workflow involved two necessary data checks, and if something is found, workflow will stop and create a task for a recorder creator to correct the data. Now, when this is done, user can review which kind of data is missing.

If a user tries to advance the workflow without uploading the necessary files that we check criteria that we know that within the workflow will stop him. And user will need to go in and do the actual work of uploading the missing file for an item.

So a user will do a check upload item. I have already prepared my design in advance just to get this [INAUDIBLE]. And I have this drawing, which I want to associate with my model file. So I will just check in the drawing together with the model file into the Upchain system.

When this is done, in a few moments, users can go back into Upchain and move forward with the CR. [INAUDIBLE] We will check if the file has been uploaded correctly and if the correct file is uploaded. Correct the file type. And if this is done, workflow will proceed.

After that one, workflow stops for a [INAUDIBLE]. So we have detected the [INAUDIBLE]. User needs to correct it. Reviewing the assembly files, user will see that there is a mismatch in the assembly files. But this is our spring part is outdated. So user needs to go in and update the design of the child part on the assembly.

To do so, user will need to download the assembly design and open it in the CAD system. Once this is done, we will download all the latest file versions of the children together with the parent design. All that it takes for a user to do is to do a checkout on the parent, and there is no need to do a checkout on the child. The child is already associated with the parent, so we need to just update the parent and do a checking on the parent.

When this is done, users can review the file information. And if necessary, files have been uploaded correctly and connected with the module design. So remember that we have a parent model number 3 and child model file number 2. Going into the Upchain, you can see the same information.

Assembly model has the file version 3 and contains the child from version 2. We're continuing with our workflow. Now [INAUDIBLE] has been corrected. The workflow passes that step.

Moving forward, we again get a task for a PM to release the design or reject. In this case, you are again saying, please release the design. Once this is done and items have been updated, you can notice all the items have the necessary careful information previously updated through the workflow.

Lesson 6. So now we are incorporating additional item attributes checks for our mechanical design items. This is in case when there's a specific need that some item attributes are mandatory within your organization. So you can make sure that those are populated before item is released.

In here, I have created a check for one custom attribute, which is named "standard," and then one common attribute named "item description." Both cannot be left unpopulated. After item attribute, let's say your organization is checking for categorization attributes.

Categorization is useful for organization, for organizing your items by attributes specific to the category of the item that they belong to. For this example, we are checking in case there is a manufactured item with the category named "clamp" that it must have an attribute name "style" populated. This is completely adjustable in the workflow, and this is just an example I'm using for this demo.

Proceeding with the demo. So we have incorporated this mechanical design in this mechanical design workflow. We are just reviewing the data for the items. And in here, we are showing that some item attributes are missing for particular items.

So remember that we said that we need to have item description and standard and also client category populated. We're starting the workflow. The workflow do the necessary data checks. And since my model has already necessary for us, it will pass that point and create a task for recorder creator to correct the item attributes.

So now one by one user needs to go in and edit the item attributes. It's putting the missing necessary information. Once that is done, users can proceed with a task. Workflow will wait until all of the tasks have been successfully completed. And once the first task is done, you can see the item is moving to the pending status and cannot be changed afterwards.

We're proceeding to the second item. User is putting in the item description. After that, he needs to populate also the standard item attribute, saving this data. Then he can proceed with the task. Task will, again, recheck if everything is correctly populated, as mandated by the workflow.

After that one, we have another check that had failed. The user needs to populate the category attribute. That one item is marked where a user need to correct the attribute. User can go in and edit it, so style cannot be left unpopulated.

We're adding the style attribute, saving the category and item attribute, and then we can proceed to the task. We're saying achievement has been filled. After that one and after a recheck, the workflow will continue.

Again, we have a task for a PM to either approve the design or reject. For the sake of this demo, we'll say for a PM that he will approve the design. All looks good. All the necessary checks have been passed.

After that one workflow completes, items have been updated to release status. And you can see that all the necessary information has been filled in on those items. Now, in one workflow that I called general CAD workflow, I'm combining all the checks for both mechanical and electrical design.

Depending on unprotected associated item, the workflow will continue by mechanical design flow, which is noted in here by the arrows and which we just demonstrated. But if other case, the same workflow, it will take the path for electrical design checks. Let's say your organization had a problem where purchasing department mentioned there were released items which had no manufacturer associated or no ERP number, and they could not order those items in time.

To correct the data when there is not this kind of checks, designer would need to make a new revision out of that assembly and all of the affected children, correct the manufacturing data, and release again. Time being spent, right? So you can make sure that purchased items have the required attributes filled before the first initial release if you're using this example.

Proceeding with the demo. So I have my general CAD workflow associated with this electrical assembly. I'm just reviewing the data for the electrical assembly, and you can see all the bulk files and drawing files have been already associated. I'm also reviewing that some information or the items are missing.

Remember that we said that purchased items cannot have manufacture, manufacture item number, or ERP number left unpopulated. And we are starting the workflow. Since all the necessary files have been associated, the workflow will stop and create a task for a recorder creator for these two particular items to update the item attributes. A user, again, goes one by one item and edits the necessary attributes. So manufacture item number is missing. User needs to fill it in.

Receives the data. It can proceed with the task on that particular item to update the item for pending status. Moving to the next item. There, again, user reviews which data is missing. Add it to the data and put in the missing ERP item number. So since this is a numeric value that user needs to fill in, there is a control preventing putting anything else, and user needs to put in the correct data. Once this is done, user will save the necessary attributes.

And we can proceed with the task. We are seeing that electrical attributes have been killed. After that one, we again have a task for a PM to either approve or reject the design. We will say for PM that he will approve this design, since it went through the necessary data checks.

With that being said, the workflow is being updating the item to release status. And all of the necessary information is now within the release items. Moving on to release process and audit trail.

First of all, instead of just one person making a decision that the design is OK and approved for release, you can incorporate a voting mechanism into a release process. This is achieved by a quorum decision permitting. In this example, any PM associated with a project under which CR resides has a chance to vote for approval or to reject a design.

I'm putting here a 60% out of total users that need to vote either approve or reject for this approval to continue. This 60% can be changed to a higher or lower number if needed. Let's proceed with the demo.

So we have our general workflow associated with this electrical assembly. So this electrical assembly, again, has all the necessary files already populated. And all the item information is already done in advance. So we don't expect [INAUDIBLE] to stop on those tasks.

Proceeding with the workflow. Workflow is stopping on a quorum decision. Right now, user is reviewing the task. Task for a quorum decision, it says that it needs to have a 60% vote in order to be completed.

So we have three users that can vote on a decision to either approve the CR or reject the CR. My first user that is already logged in as a project manager assigned to this project and to this CR. So she can vote on the CR and on the release of this assembly. Let's say we want to approve.

After that one, moving to the second user. I'm showing here that a second user is also a project manager. It is assigned to the same project. And on its main dashboard, she can open the task for this particular CR directly and in there review the associated data and vote on the design. Again, second user will approve the CR.

Since we have reached over 60% voting mechanism, the workflow will continue. So the third user doesn't need to vote. With that one, workflow will just continue releasing the items, updating the item status, and you can just review the updated information within your CR.

So we have already shown the Workflow Actions tab, where you can review which workflow path this CR went through, then which tasks or decisions have been created, and who was the owner of those. There is also a timestamp showing when this task was completed or when it passed through certain [INAUDIBLE] primitive.

On the change request dashboard, you can also review the CR audit information. Here, I expanded three different CR. And under each one you can see the task that have been created for it as well as which user were assigned to the task but also which one completed the task, and also at which time frame.

Under Released Items, there's also a CR information. There is a CR link in Business Process tab of an item, and history of an item also shows which was the last user that approved the release and when. With this last example, concluding all the lessons. Let's just recap what we learned today.

So we've shown you what are the benefits of automated release process, however, what are the benefits of the automated release process within our Upchain as well. We have shown you with lesson three what are the parts of out-of-the-box Upchain workflow. In lesson four, we have shown you how you can create an electrical-only design workflow and incorporate certain electrical design checks within it.

With lesson five, we have shown you how you can incorporate a mechanical design workflow with mechanical design data checks. We have added to it an item attributes and categorization data checks in lesson six. And in lesson eight we have shown you how you can create a program decision workflow.

With lesson seven, we have shown you how you can merge multiple processes for different data types into one release workflow. And we have concluded in less than eight, where you can review the available audit trail information of your data checks and user decisions. Thank you for listening and watching. This is all for today. Have a nice day. Goodbye.