Workflow Manager creating a break-fix ticket feature.

In this example, we'll go ahead and rather than automatically generate construction tickets from a design, this would be a more operational, operations oriented scenario where we've got a fault alarm. And this could be automated through integration with a fault management system, but in this case we're going to manually come in and say we've, you know, gotten word or we've got an indication of a fault and we're sending a technician out to do a repair and I'm going to create a new project here. I'm going to put a polygon in an area. So I'm saying create new project and I can draw the polygon over the area where I expect the job to occur. So we'll choose our Workflow Manager project here. We'll rope off the area. And we'll give this new project a name. So again, this would be a typical point of integration with a fault management system that would automatically generate a ticket to REST API call in Network Manager, or excuse me, in Workflow Manager Ticket Manager. We can come down now. We'll say this is a maintenance type task. Now, unfortunately, I don't have a maintenance group here, but I do have default, which I belong to. So I'll be able to easily navigate to this ticket. So we've now created the project. And we can come in here now and we can look at that project now. What you'll see initially is that you will not see that project on the list and that's because there's an active filter that's filtering out any projects that do not contain tickets. So if I turn that filter off, I can see here I have that new fault repair job that I created. Now I want to add my ticket to this. I can say create ticket. I could have done this from the map UI as well, but I wanted to come back and show the ticket manager portion of this again. So we can choose the region. We can put in information around the type and the category and details, severity of the issue. All of this is property modeling that's done at the ticket level that users can configure. We'll say this is a medium severity. Actually may have been high if it's a cut. And we can put in different notes and describe the issue and the cause and so on. But then we select map object point. It brings us back out to the map UI and then we can drop that point down at whatever the approximate location of the fault is. But again, if we were integrated with a fault management system, that would have been something that would have been likely automatically placed and submitted as a ticket to our system. And then distributed and tracked until close. So the yellow circle indicates a medium severity. A red would have indicated high. We can look and see we have our project here. We can edit that project information. But now if we come over to assigned work, we can see down at the bottom of my list now, I have been given this break fixed ticket. So we can see that this ticket form when we look at it is a bit more detailed than the previous for construction. But we navigate to the location. We understand where it is now. We have some idea of the severity and the issue from the ticket form itself that we received. And we can read that here. We can get our directions. But then you can also see here that the way this form was configured for this ticket has a number of different categories. So we have our site info, repair detail, and then there's default information associated with all of our tickets that are generated in WFM, in our construction manager. But these can be, these forms are editable and configurable just like any other asset in the system. So now I've set out the end route to this job. We're looking, we see our history here. Now it does refresh at a set interval. So if I hit the refresh button automatically, it will update that end route status for me. So I can choose to just hit the map button or use the magnifying glass icon on the ticket itself to get back to this location. And now I can create a new network manager design. So again, the way that we see our users typically working is that anyone who's to make edits in the system has to do this through a design editing session, which makes it a contained model of all of the changes that that user is making and is also something that's easily searched for and navigated to in the system. So again, the state model here, I've done type as build updates and I'm going to choose an editable state here. So we're using as build updates and site survey here only because I don't have the states added yet for my fault management in this database. So now we've opened our design. And we can place some notes for the work that we're doing. So again, typically our customers do not have their construction or maintenance engineers updating the database directly in scenarios like this. It's entirely possible to do that. It's entirely up to the organization to determine which users might have edit privileges versus just red line markup privileges like we see here. So we've got some description here in the note about what we discovered at this site and then maybe what some of the work is that we've done to fix this issue. We can capture photos, you can draw line work and place points just like we have in previous examples. But this all is occurring while you're working an active ticket that's been assigned to you through the ticket manager user interface. So again, I made this red since this was an issue of some severity. I know we said this was a medium severity, but in this case we determined once we got there that it was a red. It was a higher severity because it was a full cut. And now we can come in and maybe drape a polygon in the area. We could place a point feature in the area. And there's a number of different markup layer features that we can add here to document what we've done visually on the map, as well as coming back in a moment and updating the property information on the ticket itself. So now we close that design job, we see the markup layer go away because it's contained within the design and only visible when the design is open. And we can come back to our ticket manager, we can see the status of that current ticket, and we forgot to change it to on site. So we've now corrected that, we did our on site work, and now we say field complete. And again, field complete may be as far as I'm allowed to take this state model-wise as my particular user. But now we can come in and we can make some changes, and we can populate some information about the work that was done at the ticket level. So we'll now have the red line markup information visible on the map, and then we also have the property information on the ticket that we can report on for the activity. And you can add properties to this, like percent complete for construction, for instance. So maybe you have large cable pools or lots of trench work in a single ticket, where a contractor, a construction crew contractor during that day can mark off what percentage complete they've done that day against that particular ticket that can be reported on by your organization.