Upchain Workflows for Tenant Admins

JASON DUPREE: Hello. Thanks for joining me. My name is Jason Dupree and this is Upchain Workflows for Tenant Admins. I'm an implementation consultant in the data management space and you can find me on LinkedIn under Jason-- Dupree, Jason.

Here's our safe harbor statement. Take just a moment to look that over and we'll move on. Just a little bit about me to start. Again, my title and position is I'm a implementation consultant focused on data management. I started with a company called ECAD and done lots of things over the course of the time that I've been-- 12 plus years, 13 now.

But I started, before I even got into this business, I started and got my bachelor's education-- got my bachelor's in Elementary Education in 2007. I'm not going to say exactly how old I am because that'll tell you how long I was in college to get that BA. So I started at ECAD a couple of years later in 2010. So I spent two years teaching sixth grade math and, over that time, I realized that it wasn't really for me. Of course, 10 years goes by and you would eventually be really good at it, but it just wasn't really getting to where it was taken off for me.

So during that time, in my college years, I spent all of a lot of free time and my personal time getting into hobbies like photography and videography and graphic design. And through all those, I had to learn the software for all of those different products. So I had to teach myself a lot of these different softwares across these different wide variety of things some of it being design, some of it not.

But whenever I had a friend that was working at ECAD and he was in the technical position that I'm in now. And he was moving into sales and he said, hey, I think I got a job for you because you are a teacher and you know software and you can teach yourself software. Really the only piece that you're missing is the knowledge of the manufacturing industry. And so that's something that I picked up along the way, but I started at ECAD and got into Inventor and AutoCAD and mechanical and electrical and pretty much everything the product design collection entailed and picked it up really well and it was awesome.

So I do have time, about 12 years, spent at ECAD before ECAD was acquired and went through all the products in the manufacturing space, but also dipped into the AEC space to do some Revit and learned how Civil and Plant 3D interacted with Vault because that was another product that I covered. And I think I even had to learn a little bit of CADworks back in the day in there somewhere too. So kind of covering a little bit of everything. But even the M&E side, so we were doing product design collection, but it had 3DS Max and Showcase and even Mudbox for a little while there so I got to learn those products as well.

So then ECAD got acquired by D3 and became part of this team D3. And I moved from just being a manufacturing centered person to focusing on one of the more niche areas of the manufacturing products, which is Vault. So I got into data management. I've been doing Vault for a long time in the midst of all these other products.

And I had my boss now, Kim Hendricks, who wouldn't let me-- I don't think she would have let me go to one of the other teams. She pulled me into the data management team and I started helping out with Vault there. And then as soon as Autodesk came and acquired Upchain I was the lucky one that drew the short or long straw, whichever way you want to look at it, to get to take part and learn Upchain and dive head first into being one of our front-runners for that.

So today we're going to be talking about Upchain and the business processes, the business processes and the administration side of that. So those workflows inside of Upchain. Again, there's my LinkedIn URL if you want to take a look at it, check me out there. And if you need to email me any questions hit me up at jason.dupree@teamd3.com

So first off, just, a quick what is Upchain? Just a little bit of overview of what the platform is. According to Upchain's LinkedIn, Upchain is a cloud-based product, data management, and product lifecycle management software for all in one. Configurable, out-of-the-box workflows control your processes to keep projects moving while integrations keep teams working in CAD and business tools they already know.

So that's a lot of words. What exactly does that mean? Let's make it a little simpler and say-- think Vault in the cloud. So Vault being on premise, you install a server, and you install clients onto the machines, and then you connect those two and work that way. But Vault can also go in the cloud. You can install a server on an AWS machine or some other cloud machine, but here this is browser based.

Upchain being browser based, it's all on the Autodesk servers. And we just do everything through a browser and through plug-ins that can go into the CAD products. So not necessarily a full on client like Vault, but you do have those plug-ins inside of Inventor and SolidWorks and so on. It is item-centric. So here we're looking at a view of the web view in a browser.

And where Vault is folder and file-centric, Upchain is more like the item master inside of Vault. So you've got this list of items and those items, being containers, they have or can have files attached to them. So they can have CAD files, but they can also have other file types; word documents, PDFs, whatever it is you need in there, but they don't have to. They can also just be empty and have no files attached to them, but they can have other metadata that goes along with that.

Now, it is project-based as well. So you can see at the top of the screen, there's a little projects dropdown, the scalpel 29 inch, that is the project that this view is looking at. So you can have different projects with different list or different bomb inside of those projects. It is CAD agnostic.

So this is a view of the plugin inside of, say, either SolidWorks or Inventor, but it does look the same inside those different products. And it installs and runs as an add in, but there is also another version of this that is a standalone, free floating plugin. It's not actually plugging into the products, but it's a panel like this. And so you can use other CAD programs that don't have specific plug-ins for them. So you can still use it with any other CAD program as well.

Now, Vault has a little bit of PLM, you've got life cycles and you've also got the ECOs, the change order processes. I've seen other people, clients, use those change orders as other things. They've used them as dishing out tasks or jobs for the day, assigning a workload to their users. So not that those ECOS have to be ECOs, they can just be a process.

Here in Upchain we do have a little bit more in depth PLM. So we've got, not only the life cycles, but also tasks that can get assigned. And the view that you're looking at here shows some tasks. And those tasks can have durations and due dates. So you can have this Gantt chart that shows and helps coordinate those tasks and across the project, but you can also have other processes as well like change request, change notices, quality assurance checks, requirements gathering, investigation requests, all these different workflows that can be fully customized.

In Vault we've got the ECO that's got basically one workflow that it works off of, but here we can customize it to nth the degree. So let's talk about those workflows because that's what we're here for today and get into the back end of how those workflows work. Here's an example of the workflow that you see as an admin. So when you go into the administration side of Upchain and you look at the workflow you see all these boxes that are connected. And they show the flow of the process, of the change request, or whatever it is.

These can be fairly simple like the one you see here. So this one's basically got one user input and that releases some files or some items. Or it can be fairly complicated where it's got to go through a check of multiple types and approvals from multiple groups or multiple people. And then you can have different paths that they go down. So lots of different ways that you can do this. You can make it as complex as you need to.

So here's that simple workflow, just to help understand what exactly is happening here. This start primitive is just where the workflow starts. So this is an input, you have to click a button to tell it to start the workflow, but then after that there are these update workflows, update primitives, that specify something is getting updated. So there's nothing that the user has to do, it happens automatically. In this case, the workflow itself, the change request, or whatever process you're in getting updated to say it's a work in progress.

So now that the workflow has started, that status of that workflow is changed. Then the items themselves, the items themselves will get set to approval pending. That locks them down so that way people can't be making changes while you're in the process of getting that approval. At this point, there's a task here. This is a user input to move forward.

There's nearly nothing else to do here other than just say, OK, we're ready to move forward. The system primitive releases the items so it actually does that for you. You said these are good so it releases the items and sets them to a release state. No need for an update primitive here because the system primitive is doing it for you.

And then this primitive, another update, is telling the workflow that it's completed. You've said that the items should be released, the system does that, and the workflow status goes to completed. Or, if the system release fails for some reason, then it might go down to a decision like this. So this decision task lets the user decide, OK, do we want to try this again, maybe we can figure out what the problem was and fix it, or do we want to go ahead and just reject this in the workflow?

And if you-- You can see the green path goes back up to that purple button and you can see the red path goes to another update. That update takes the items back to development, that way they're back in a editable state. And you can go and work on those again, make those changes so that you can go back and maybe run this process again. And the workflow itself will be set to failed to release.

So here we're specifying something else happened other than-- It wasn't rejected by the user, necessarily, it was a failure to release because of some system issue. And then, lastly, the workflow ends with a stop primitive.

So let's look at those primitives and what options we have on that back end. Here are some of the primitives that you'll see inside of those workflows. A start primitive. Update. A system decision or object decision, these are spots that actually can have a little bit of user input, but they can also be a decision based off of a certain criteria. A print so you can have it, through your process, automatically print something out, send an email notification to some users.

The system primitive, as we saw, can release items, but there are a slew of other things that it can do. The report primitive can generate a report, maybe a bomb or some other report type, and add that to your items. And then to stop primitive, again, to end the workflows. A couple of other primitive types are decisions and tasks. We saw those in that previous workflow, so user inputs here.

And then there are also sub tasks and documents too. So these are specific to a certain type of workflow, whereas all of these are system primitives. These are things that typically don't necessarily have a user input, the system is doing something. As we said, the system decision, object decision, to start they can or do have something that the user has to click or decide on, but the system is still doing something in the back end, whereas these two primitives are user primitives.

So they're user task decisions. The user is inputting something, they're saying go this route or go this route and the system itself isn't doing anything other than that. So it's just a user telling it to continue on in one path or another. And the sub-task and the document are specific to QA and requirements workflows. Hopefully, at some point this slide will be out of date and those two task primitives will be within the other workflow types too.

There's a help file, help website, that you can go to for all of the workflow lists and super detailed about what everything is there. So I want to show this to you because we've only got so much time to be able to show some of these things and there's a lot of information that goes along with all of these different primitives. So we want to make sure you know where to find that information later on. So let's get into that.

So now I'm in Upchain in the web view. So you can see I'm in live.upchain.net I've logged in with my Autodesk ID and I've chosen the tenant that I want to log into. And from here, looking for-- I'm in the dashboard, but looking for that help file and where that is. I'm going to go over to the little circle with the question mark in it and go to Upchain Help Center.

In the Help, just want to be specific about where to look for these workflows and what those primitives are, go to the left and down to workflows. Expand workflows and look for the specific workflow type that you're working in. So let's say I go to change request, expand there, and then look for primitive list for that workflow type. All those sections there all have a primitive list that you can look through. The primitive list will be repeated in some of the workflows.

So you'll see some of the same ones, but when you click on that, you'll see the list of workflows, scroll through, look at the workflow and it's got all the inputs for the workflows listed out and what they're for, what they do. So you can see, some of them are pretty complex in what they can do and what's there for your inputs. So it's pretty important to be able to know because, obviously, you're not going to remember all this stuff and maybe even all the stuff that I go over so it's good to be able to go back here take a look at something specific and say, OK, I want to know what this does, let me go read over this and then go back and apply it as needed.

And then, down towards the bottom-- You can see these are all the system primitives. Down towards the bottom is where the user primitives are for the task and the decision. All right. So eFind, if you know where to look for, if you forget, you can always click in the search there and get back to it that way, hopefully.

Now, the workflows are inside of your processes, are inside of a project, the ones that are being used. So I'm going to look in this project right here and go to the business processes. And here you can see all of the change requests, change notices, quality assurance requirements, investigation requests, all those different types of workflows, all those processes that have been used and created. You can see some of them are canceled, some have been completed. So all those show up here.

You can get to them from there within a project. And then there's also the project management section that have the tasks. And within those tasks, you can see the Gantt chart. We'll Zoom out to see some of the other-- where those are, get an overlay of your project and how those tasks are going. So now let's go into the back end of the project, not of the project, back in of Upchain, look at the administration side of things.

And inside the administration at the top here, you can see business processes and the workflows. So this is where we're going to be building and editing those workflows. In here there are system workflows and these are the default, out of the box, tools that are there that can be used. You can just stick with these if they work for you, but otherwise, you can take any of these that are there.

So I could say the [INAUDIBLE] workflow, maybe I want to tweak it some, apply some different permissions to it, and go over to the duplicate as tenant workflow. And then that will create it as a tenant workflow and then you can make edits to it from there.

So over in the tenant workflows you can see the workflow types, CNs CRs document workflows. Whereas an item can go through a release process, a document just a normal file within the project has a document area. So you can have your Word documents, PDFs, different document types in there when they need to get-- you want to publish those, release those they have their own workflow types. Investigation requests. Projects.

Now, projects have their own workflow types too and I want to mention those because you'll see in the system workflows for projects. A project when it gets created it needs to get started and set to active. And you can see in the system workflows there is a project for each project type. So if you do go make tenant workflows or you make your own custom project, you want to make sure that you make a tenant workflow for that project and it needs to be a specific one for each project type. So just something to keep in mind there.

And QA requirements gathering and the task. Now the change request, we're going to be focusing mostly on those so I to show a few options. This one I made just to make it a very simple, show you how simple a workflow can actually be. This one goes from the start. You can actually expand this, or depending on how big your workflow is, you can zoom in or out, make it a little easier to see.

So it starts, it updates the workflow to a completed state right away and then it releases the items. We're going to talk about this panel over here in just a moment. And then it stops. So with this particular workflow, you click the button to work to start the workflow and then that's it. There's nothing else to do. It automatically releases those and either fails or succeeds and ends the workflow either way.

So it can be that simple or it can be something a little bit more complicated maybe with a decision inside of there. So here we're starting the workflow, the items update. The user gets to say are we approving this or, after I check it, do I reject it. And then it can circle back around if it needs to. So, again, very simple, but we've added a step in there for the user to have an input.

So I want to show-- I'm going to start with this very simple one and add in a step into this process. Taking a workflow that exists already and going to make some edits to it. You can see there's a little pencil right here. There's actually versions so as you make these edits and save those you can go back to those old versions and start from a previous spot if you need to.

Going to the latest version, it's not published, and I can actually see the Publish button is not grayed out so I know that I have yet to work on this one. You can see it's an empty space. If I was on a previous workflow, and I've got some primitives there, instead of going here and choosing new version that new version would wipe out everything I've got here and create a blank space like you just saw. So that's the one you want to watch out for. Instead you go, save as new version, and that saves everything you have here as that new version so you can start tweaking it.

Now you can also import as a new version. If you were to use the export, maybe you want to take one from a different tenant, maybe you've got a sandbox that you've been working in and you want to take that, export it out, it saves as an XML, and you can take that and import it as a new version into another tenant. Or you want to take one that you've already got in this tenant and just duplicate it so you can do it that way by exporting it and then importing it. So I'm going to go back to my new version that's a blank slate here. And if I want to start building this out, I would start with the Start Primitive.

Now, notice, when I drag this over it's got a circle with a cross through it. That's because I haven't started editing it yet. So that's something that I think is really easy to miss. You do need to go and click the pencil to be able to start editing and now it shows that the name is editable. So I could actually change the name of the workflow if I needed to.

And it also shows the status that it's locked by me. So if somebody else came in here to make changes to it they wouldn't be able to because I'm working on it. So now I can take that start primitive, drag it over, drop it into the window. When you have a primitive and you've got it selected, the panel on the right shows up and all the options, all the inputs for that primitive, are available to you. So anywhere that you see the notes field, that's going to be just administrative stuff.

So from here, no user is going to see that, just from the administrative side, things to keep track of what this primitive is doing. You may come back to this at some point to make an edit to it and have completely forgotten what you did before or if somebody else takes it over it's nice to have those notes in there so that everybody knows and can easily remember what's going on. And the user commands. So a user command being a button that a user actually clicks, what do you want that to say? So here it could say start workflow like it does by default or it could say something different like start the process.

Clicking off into just blank space there, now we no longer see the input. And from there I'm going to build this out like that simple workflow. The next thing I need is to update the workflow itself, the status of the workflow, so that way it shows up as work in progress and that it's no longer in a draft state. So here I can leave that name as update or I can set it to something more specific, like update workflow status to work in progress. Again, the more detailed it is, the easier it is to know what that is next time you come back and look at it.

Again, got a place for notes in here. Now need to change the type. So the update workflow can set the status for items or for the workflow themselves or the item maturity. So that's another thing that it can update. So here I'm going to go with the work order status update and change the value to work in progress.

There's a place to set percentage done so you can specify in this state of the workflow what percentage you want that to show up as. So we can say this is 5% or 10% or whatever it is that we may have done some work so far, depending on how large our workflow is. Next, I want another workflow, another update primitive, to change the item status. The item status is going to go to pending release, I'm sorry, approval pending. And that way the items are going to get locked so that they don't accidentally get edited while we're in that review process.

And then from there, maybe I want a user input. So instead of going with a decision, this time I'm just going to go with a task. And with this task I'm going to give a user command to release the items. So it will be a button that they click that just says release items. It's just a generic task here.

And I've got an assignee field to tell someone to click that button and say continue on with the process. So this could be myself or it could be somebody else. When you choose your assignees you've got the ability to assign by role. So the project itself is going to have users assigned to certain roles in that project. I'm the work order creator so I'm going to go ahead and use that to keep it simple, but it could be somebody completely different than the person that started the workflow.

You can go by specific users. And you can also go by teams. So if you have those teams set up, it'll automatically import all the users within that team. All right.

Now I've got my assignee. I can add some details, something for that user to see and for them to understand what it is they're doing here. OK. And email notification, do I want that user to get an email notification so they know, through their email, it's time to go do some work.

Again, we've got a place for notes for our administrative purposes, but then we've also got a spot for allow workflow cancellation. This is going to give us an out. Even though this particular primitive has one specific route that it's going to go, this gives us a, maybe something messed up, we completely forgot about something and we just need to completely stop the workflow, so that allow workflow cancellation is going to be handy to just always be able to eject. And you can also see this Create CN. So depending on what workflow type you're in, what primitive you're in, you might have the ability to create some other workflow.

So you can go from an investigation request and generate a change request off of that. So now I've got the task for the user. And once they say yes, hit the button, release the items. Then we're going to let the system actually do the release. So this system primitive, again, notes for yourself the type of system primitive here, all the different things that it can do.

We can have it actually check for a stale cBom and go ahead and fix it for you, generate some different file types, or, as we're going to do here, simply release the items. Now, once it releases, the items are good, the item status has been set. So now we need the workflow itself to get set to completed. So, again, I'm going to change the work order status to completed, in this situation. And then that's the end of the workflow.

So you can use the stop primitive there. Now as I go through, I've got all my primitives there. There's no-- Even though I set them up in order related to each other, there's no actual flow happening just yet. So now we need to connect those with these little nodes. Grab one, drag it to the next.

You can see the green path being the happy path, as they call it, the good path. And not that it's always the good path, but it's the first path that you always get when you drag from one node to another. So I'm going to start connecting these and build those out. So we're just following this path between these primitives. All right.

So maybe we think we're good so let's publish that. Well, we still have something that's not fully defined. So primitive fine, it gives us an error or a warning just letting us know. So that's good. So we're going to go look for primitive five.

They've all got numbers on them, makes them easy to find and ID. Particular primitive, it looks like we've got everything. We look for the asterisk and look at everything that is required is set. So we're good there. So we need to add a exception path.

So an exception path, this red path. We've got green or red and not all primitives have two paths. You can see if I drag off of the nodes of some of these other primitives they don't give us a red line, but this one does. So it's got to go somewhere. So if the system release fails, what happens then?

In this situation, we saw some examples where it went backwards and gave the items another chance to get edited so that it can continue along the path and try it again. Or it was a decision for the user to say, do I want to try again or continue on and just reject it. In this situation I'm going to go ahead and just say let's set the work order status to failed to release. So it's going to specify that the system had a failure and we'll know that based off of this status.

And then, so that the items themselves, because currently after this primitive, since they didn't get released, they're still in pending approval so we want to set those back to development. Item status update to development and connect these. And then on to the finish. So now that I have everything connected and set up correctly, hitting publish. We get a little message letting us know that it worked, everything's good.

Now I can see my status is set to active. So if I go start a workflow, start a CR, and choose this particular CR then we'll see that this is the one that gets used. Like I said, it is possible to go back to these old versions, select those, go to save as a new version so that'll make it the newest version, and then publish it. So if you want it to revert back to some old changes you can. OK, so let's look at some examples here.

We've got that simple CR. Here's that CR with the approval. So they actually have a decision. In this decision primitive we get to say it's a user command for approve or reject. So that user command, you can make it say whatever you want.

It doesn't have to be approve or reject, it doesn't have to be a good or bad, it can be just two different paths. Do we want to go to this team or that team next? The button that you choose, the user command, approve or reject, do you want to have a comment required for that? So when they click that button, typically, I've seen, when it gets rejected, you want to have them input a reason for that, whereas when it gets approved, not as big of a deal. We can just continue on from there.

Assignee cannot be creator. So that would say the person that started the workflow can't be the one to approve here, it has to be somebody else. Task description so they know what they're doing here. The assignee is set to the correct user or group. And they're getting an email notification for that as well.

And, again, they've got that workflow cancellation option to eject the entire workflow and hit the Reject button to get out of it. All right. So we can get even more complex here with an example like a workflow with item approval. This one is so big it expands past the screen. So I'm going to use the minimize or zoom feature here to be able to see it all in one view.

So you can see lots of things going on here. This particular workflow is pretty cool because, not only does it have some spots where the system is checking to make sure that certain attributes are filled in, like here-- so you can see this is an object decision. So the object is deciding what happens to this workflow based off of some criteria.

So we've got an actual rejection criteria to look and say, OK, if this rejection criteria is met it's going to go down the red path. And if it's not, then it's going to go along the green path. So we actually have properties. The description, is it empty? Is the item name empty? So either of those, if either one of them are empty, it'll stop and let the users input that before they continue on. So it does a couple of checks there.

Next it's doing a check for drawings, making sure that there's a drawing attached to each of those items. And then, once it gets to pass that things are-- The cBoms getting checked, the user has an input. And then it goes on to certain teams by saying the rejection criteria for this particular object decision is that it's a certain item type and it's an approval pending. This is kind of cool because along the way we're updating the items to all be approval pending. So when it gets to this point it checks and sees, OK, I've got these item types, they're in approval pending so I'm going to stop here first and let that team, the assignees--

We might have the assignees for this particular workflow be that group. So for the software we're wanting the software lead to check and approve. For the hardware maybe we want this electrical designer to approve. For the mechanical approval we want to lead mechanical designer. So we've got certain people for these certain item types.

As they're getting caught by these object decisions those users make those approvals, make any adjustments if they need to. And then it goes on to a final approval by someone who's maybe kind of doing a second check for everybody, just making sure everybody's on the same page, and then it goes on from there. Another example that we've got is this electrical package release. I like this one because after it goes through some of those kind of same checks-- We're looking for making sure attributes are filled in, making sure certain file types are there, making sure maybe a PDF is attached to the item. --it goes through a couple of different teams for decisions for approval.

And then it gets to a spot that is not really an approval. It's saying, do you want to do this or that? So even though it's a green path and a red path, that's not a good or bad. It's just a, do we want to add software to this? Is there a software in this workflow that needs to get approved?

Well, if so, let's send that on to the software team and then the software team can make their approvals for those particular items and then say everything is good to go and then moves on from there. So lots of different ways that you can use these really complex-- Seen a lot of cool stuff so far. And it's kind of wild how crazy these can get. So let's look at a couple of these in action from the user side.

And we'll come back and look at that approval for the item types, item type specific approvals. We'll look at an example of that. A little bit simpler version of the one that we saw. But just starting with the CR and CR with approval and what that looks like. In my project I've got a couple of examples here that I'm going to use. This particular item is in development and it needs to get released.

So I'm going to send this to a change request. So now I'm in the change request. We can see the number up here. And need to choose the particular workflow that we're going to use for this. So all the change requests that I have created and all the system ones are all in this list and I'm going to go with this very simple CR.

Now, this one, I know I originally had it where it was just one button to start the workflow and then that was it, but I think I just edited it and saved it. So we might have something a little different here. Next thing is I'm going to do is hit Save and start the process. Now, it is possible that if you forgot to put in some information it'll give you an error and let you know what needs to be done. So it's just saying here it's missing a release type or a revision note.

So looking at the release type and the revision note here, you can see the revision note is empty. To make that edit I'm going to click the Edit button and now that field is available to type in. Type in the notes about what is happening here and now I'm good to go. So this is my changed description that would show up inside of a revision table. Save those edits and now I can start the process.

And we'll see it. Takes just a moment, but it'll go on to the next step and we'll have the instructions of what to do next. So this particular workflow, we're seeing that the item is now pending approval. It shows what step we're in. This is a task and you can see the button there, but it also shows up in the step that we're in here. So you can see the user that is required for this step.

So it's possible that you came in here and it's not actually your turn to do anything, or you're just looking to see whose turn is it to do something, make sure that they recognize that they need to take note of this. And you can see who that is and what it is you want them to do. And then we can make that decision to say let's move forward, hit the release button, and now we're going on to the next step. So with this simple workflow; we started it, we hit the release button, and then it continues on down the green path to the finish. The workflow is now set to completed and the items are set to released.

So pretty simple. So it can be as simple as that or even simpler or it can be a lot more complex. So let's take a look at an example of something a little more complex. We'll go back to my Bom for this project. And I'm going to take my Cadomatic here and run it through a workflow, a change request, that has some checks for a particular item types.

So you can see here, my items, the icons, show that they are different item types and the item type column showing what those are. So I've got a couple of manufactured items, a couple of purchased parts, and a software package. So I'm going to use my item approval example. This is like one that I showed you that was very expansive, but it's a much simpler version of that just to show the example of it catching the particular item types. All right.

Save that. And start the workflow. Oh, a revision note before it catches me. I'll hit Edit here and type this in. Yeah, there we go.

OK. Starting that workflow. This particular workflow has a stop point that just says, are we sure that we want to continue on. So now we're here with this process engineer approval, review the items and just make sure that everything looks good that we want to move forward. So it's just one button to pick and we're going to move on from there.

Before we go there, you can see we've got these columns for all these different users that are part of this workflow. So as they do their approvals or as they have something they need to do, we might see some of those columns change according to what they are assigned for. OK. So I'm approving to move forward.

And now our first step is an object decision primitive stopping and saying, check and see if there are any software items-- So you can see this is a software approval. --and approve those individually. So we're looking for-- OK, we've got software package here. And this little button here allows us to approve or reject. So we get to stop and approve each individual item.

So we saw some of the workflows where it was a simple one step, click the button and everything gets approved, but with this object decision primitive it's catching all of the items that meet that criteria and then stopping so we can approve those individually. Now, I am the work order creator. I kept it simple so that I was able to assign that to myself, but if I was logged in as one of these roles then it would show up as that. And now I'm on to the next step, which is hardware approval. All of the software packages got approved so it said I'm good at this step. Let me move on to the next object decision for purchase mechanical parts, is what this step is looking for.

Now, just to make sure everything gets refreshed, and it may change what role it's looking at me as. I'm going to go back to my item and can get back to that process by going to the business processes tab, change request, and there it is. All right. So now we're looking at the lead mechanical designer. I'm logged in and I've got that role as well as the work order creator, which is why it's showing up with the buttons in this column.

And I'm looking for hardware, so I'm looking for my purchase mechanical parts. Now, you do have these columns that you can and make it a little easier to find the ones that you're looking for, pretty easy with a small assembly, but I've got to purchase mechanical parts. So before we can go on to the next step I need to approve those. Take a look at them, open them up, make sure everything looks good. Set that one to approve. Now I click that one and I'm still in the hardware approval state.