Halo Implementation – Full Process – Creating ticket Type and workflow for Approval Ticket

okay uh hi everyone and welcome to another implementation uh series with Halo today I've got again my favorite person from Halo Mr Halo himself um Morgan espinal today we're going to talk all about access rights we're going to go through an entire scenario you know one of your clients has maybe asked you to um to set up access rights for them be that on a line of business application or maybe access rights to a specific folder we're going to go through that entire process talking about how to set up the the ticker type then all the way through to um you know the ticket approval process um and and through that entire um kind of workflow so this is going to be a slightly longer video than we normally do but I think it's really important because this is something that a lot of people are um are asking for so um sorry for the long intro but hey Morgan how are you doing and thank you so much again for uh for joining me on this call yeah thanks for having me Chris hello everyone um yeah this is going to be a good one I think we've we've done a few sessions talking about specific areas of configuration within Halo PSA um today we're going to do a bit more of a sort of recorded long-form consultancy session uh looking at start to end process so we'll be touching on workflows approvals ticket types field lists points that we've discussed previously but hopefully this will give the audience a bit more of a wider context of how the these different areas of config or sort of Daisy chained together so yeah yeah looking forward to it absolutely and I think it's going to be brilliant so I think what um what I'd like to see is is you know how do we set up um the ability for our customers to to log these kinds of requests with us right so the customer is asking for some kind of access rights right maybe they want access to a particular folder um and and we need to get some kind of approval process for that or maybe they need access to you know a line of business application maybe you know as an end user I need more rights to log into Halo is a perfect example right um now I need to have that approved through my um through my manager whatever the case might be so we need to have a form um on the client portal that the the customer can go on to and make this request you know with a drop down list it might say you know what kind of access do you want is it folder access there's a line of business application and then if it's line of business application then select a list of what those applications might be um and then based on that and maybe I have maybe there's different approvals right maybe you know there may be different people who need to approve whether I need folder access versus um you know line of business access whatever the case might be so to kind of have that form that goes through that and then and then designing that entire process within um yeah absolutely and so the first point to think about I like to well I like to think about these kinds of processes in the chronological order right so where are we starting well we're starting at the point of logging the ticket and integral to that is the form that you're filling out whether it's you as the agent or the end user making that request by the portal so the first point uh to sort of drill into a little bit is what is this form going to look like um now for people coming from other systems over to Halo PSA my advice would be look at the existing forms that you're working with right take the integral information take the important bits of information that you can't lose make sure they're input into Halo and keep in the back of your mind what part of the form can you improve upon you know do you really need this field can we take this how does anyone actually fill this in um but to start off with we really want to consider the field list and the ticket type that we're creating so Chris let's have a brief conversation about that um I I think that it's going to be important to include a justification field so if an end user is logging uh you know a permission request or access request to a certain application or folder why are they logging it why do they need that um it's also going to be important of course to specify what they're requesting access to like you say whether that's a business application or a particular folder on a server somewhere um and how long beyond that is there any right it it could just also be how long they need to have the access for so you know maybe I don't need to have access to that folder for the rest of Eternity right maybe I only need to drop some certain stuff into that folder but I don't have any access now but the justification I have is well I need to put this big file or whatever it is into that folder or I need to log into um you know Halo or learn about business application to set up a particular integration right and then after that I don't actually need to have further access to be able to do that stuff anymore so so some of it could be actually time based on you know I specifically only need it for a certain period of time good point yeah so um yeah like a temporary access option where you specify the duration that you need access for or a start and end date for that access okay cool perhaps another one to consider would be uh the level of access that the individual needs yeah okay cool should we start with that yeah let's start with Ellen and I think you know and you mentioned about um you know obviously having the customer being able to self-service themselves from the from the portal perspective but also you know if the customer calls you on the phone or or emails you in how does how does that kind of flow through the system as well so maybe we need to look at those those different scenarios as well I I know you know from the ticket type perspective obviously that's going to be the same effectively whether you whether you do that as the as the agent blog in the ticket or whether the customer is doing that from the portal but what if the customer emails in and says hey can I can I have access to this particular folder um you know we needed to kind of flow through that whole process as as well yeah absolutely okay so first things first creating our ticket type so we're going to want to go to the configuration module mm-hmm then into tickets and into ticket types now we could create a brand new ticket type from scratch um but what I'm going to do just to have some of these sort of default feel or some of these mandatory Fields pre-populated so I'm just going to take the standard service request ticket type and I'm just going to clone it just save a little bit of time and we'll call it access rights requests I mean that's what I do all the time by the way and I think it saves a huge amount of time of um you know taking the types that are there already and just just claiming them I I never create them from scratch because um you know invariably I'm going to tick all the same boxes anyway and so I might as well just kind of copy it from something that's there already yeah yeah exactly yeah a lot of them you know the chances are always going to start with the same default status uh you're gonna have the sort of the same options around what happens to the states when customer updates the ticket so yeah it can be easier in most cases to just clone an existing ticket type yeah now one thing that will be quite different is going to be the field list so um what we'll do is we'll go to the field list Tab and this is where we'll start amending those fields so uh let's start from scratch um we could put a summary in um yeah yeah and we'll see maybe we'll come back to that and we'll see how we can default that summary the big bunkers yeah no I was gonna say no I think we probably um we maybe do need to have the summary at the very least so that yeah because the customer is going to say I need access to whatever application so yeah yes yeah yeah yeah exactly and so we'll put summary and we'll put details so details will be able to provide some further details summary is just going to be a brief title of what it is they're requesting access to the we have a custom field already baked into the trials called justification so we can uh use this justification field that we've already got now um let's have a look at creating a couple of bespoke custom fields for this particular ticket type so the first one that we'll create is a drop down that's saying are we requesting access to an application or to a particular folder so to do that I can click add on the right hand side foreign and we'll just call this app or folder remember the field name uh it is not super important it's what goes into the database so it has to be alphanumeric no spaces but what people will see throughout the application and on the self-service portal is this build label so we want it to be this to be a little bit more descriptive so are you requesting access to an application or a folder now we'll probably want that to be a single select drop down you pick up or you pick folder so we'll select our type of custom field to be single select where I can then go down below it's my values section and I can say application and then comma separate that with cool I can leave that as it is now the next field that well the next two fields that we'll want to include is going to be an option to pick the application in question or the option to include a path a directory path so let's add those in so we'll do this application again we'll have our application be single select field um probably don't want to make that multi-select you don't want people to be requesting admin rights to too many apps all at once keep those processes distinct although although that could be actually something I think we we may want them to be able to do right I might want to have access to um you know QuickBooks and Halo at the same time because maybe again that I'm going to turn on something to do with the integration and I need to test it um or um okay I'm gonna do so so yeah this is so they may potentially be the ability for me to to request multiple applications okay cool well then yeah in that case we'll make our type of field multi-select same process comma separated list here so we'll do Quick Books we'll do Halo Esa and maybe we want access to an rmn so we'll do ninja yeah yeah I mean you know an end user probably wouldn't necessarily ask for actually for for you know Halo or ninja specifically yeah that's true but again this could be though that this could even be an internal request from one of your your engineers right I mean I yeah I could be working at Cedella and saying you know I'm not the boss so I don't have any of these rights but I need rights to be able to do this so it could be it could be within the the MSP as well um that somebody could be requesting permissions to do that so I think yeah yeah leaving it there was saying Halo and what have you in in there is fine but yeah typically as an MSP you would be putting in whatever the business applications that your end users would be using oh yeah I suppose that does raise an interesting question what applications would an end user be requesting access to in the first place so probably something like maybe QuickBooks possibly um or maybe they have some kind of CRM system of some sort um you know like Salesforce or um or something that that isn't an MSP type product you know um something to that effect or maybe they've got a some kind of marketing tool that they might need to log into you know maybe they want to um like a MailChimp type thing and they might want to create newsletters and um you know that has multiple multiple access levels you know those kinds of things or maybe even um you know somebody who is designing something on your website maybe they want some access to Wordpress if you've got WordPress you know so that they can actually log in to be able to log into the back end of Wordpress and do some stuff so it the the line of business applications that they're going to be using are going to be something to that effect or some kind of other tool that they're using within their business okay yeah yeah interesting perhaps we have two separate Fields again we can touch on another area of configuration so if we want to make this access rights request form as general purpose as possible we can have fields that are present to the user and Fields that are present to the agent so yeah an age and internally could request access to ninja or to Halo and for you know administrative purposes but then a different set of applications would be present to the user yes exactly and I think that's the thing because you know there's there's two things here right there could be and think about it yourselves within within Halo right you probably have certain certain rights within Halo that maybe some other people don't have and that person may may need to make a request internally to say I need to be able to access these other things with inside Halo um but but also so so an MSP may may need to do that same thing but yes also your customer then needs to make a request or the end user needs to make a request that says I need requests to whatever tool I use QuickBooks zero WordPress whatever it is okay cool yeah so let's create a new field business application user application give it the same field label um but a different set of options wait and just do like two I don't know QuickBooks um mail chimp mail chimp and I don't know word process on WordPress I mean these may not be tools that people would need access to but um you know just to just to illustrate the point of the types of of applications yeah absolutely absolutely okay cool yeah so we'll come back to making these dynamically visible we'll come back to the visibility conditions for these such that uh users can't see this field and agents can't see this field so they're a distinct list um the next one to add in if we don't already have it is off so we've got shared Powerpuff let's create a new one so create file file call that one three this will just be a text field so people could just input the string uh that corresponds to that path that in cool and the next one to consider would be the temporary access option so what I'm thinking is just a check box yeah oh yeah temporary access and then a check box of it only needs to be temporary and then a date until right so before you carry on so for for everyone watching here if you haven't sort of you know learned how to do um uh custom Fields within Halo what you'll notice is uh you know what Morgan is doing is clicking on the add button so this is going to give you the ability to then add a custom field rather than than using one of the built-in ones that's already on the system that yeah it's absolutely correct you can actually navigate to the same uh area of configuration via heading to the configuration module then to custom objects then custom fields and and we'll see that you know those fields that I've been adding in added into the ticket entity so this is just a bit of a shortcut way of adding those fields in yeah so this was going to be actually to jump from one area of config to the next or having it on the same screen yeah yeah yes yeah yeah so this will be temporary access and then we'll make this a checkbox um another handy Point worth mentioning is uh we can put a little hint in uh to our checkbox Fields so we can provide some further information so uh if you only need access to this uh well if you only need temporary access checklist for access please check the above box and and then a date and then yeah so I'll call this one access until when do you need access so and then this will be a date field cool and then we'll throw those other ones in so throw in summary details justification that's worth bearing in mind that the order in which the form is or the order in which the fields are presented on the form is established based on the order of the field list here so I probably want our summary to be at the top we want our details directly below then we want our option to specify whether we're requesting access to an application or a folder directory then we'll have our application options if selected or our directory is selected then below that our temporary access checkbox and below that the um when do we access until if the above checkbox is checked and then finally our justification so save that very quickly um so before we go any further let's make sure that the configuration of the visibility of these fields is set appropriately so this business application is for our agents so I'm going to hit the pencil against this field and I'm going to say do not make this field visible to the end user when they're logging this request via the portal and in fact don't make it visible once the ticket has been locked what for agents we will make it visible when they're logging and when they're viewing the ticket similarly our business application user field will want the inverse to be applicable so we don't want agents to see those fields they're not relevant to the the agents well they're relevant to the agents once the ticket's been logged but it's not relevant on the initial form the agent to see that field that's for the end user if logging via the portal well also for these of course we only want these fields these application fields to be present if we are requesting access to an application so let's go back in there and scroll down to our Dynamic field visibility section so Dynamic field visibility in Halo is a way of only presenting a certain field based on some other field being set or some other condition being met in this case we want our application field to only be present if we are requesting access to an application cool and then we'll do that for the field below as well cool uh similarly for our path to directory we'll only want that to be present if we're requesting access to a folder yep yeah and that's one of the things I really like about um about Halo is you know giving you the ability to kind of you know have these Dynamic Fields based on something else that you've um so yeah some of the other PSA tools um on the market don't allow you to do this so it's kind of really cool that you can you know all the fields get presented whether you um whether you need them or not so this is really cool to be able to say that only display that field if you're a user or only display their field if you're a customer and then only display the other fields based on what you've what you've selected on the the field as well kind of really yeah so you kind of it's almost taking you along a journey of you know oh okay so you want access to a folder what was the part of the folder right I don't need to see that application field it's not relevant so yeah it's you can imagine over time these forms can become quite comprehensive uh but the look and feel of them from a usability side is uh you know still very clean not bloated at all even though behind the scenes you might have dozens of fields you've only got the two or three Fields relevant to the specific type of request as being raised so yeah yeah absolutely cool um and we'll do the same thing with our when do we need access until we only want to show that if temporary access is checked so we go in here so our Dynamic build visibility to show if checked yep and then justification we will always uh have present and furthermore we will always enforce a justification to be populated so we'll do that for agents sorry do that for users and for agents when logging these requests yeah yeah cool so um you know we've we've made this form um but with the the idea of users and agents using this form um there's a couple of configuration points that we want to ensure are set to allow for the tickets to be logged by agents and by users and we'll find those on the details tab so we can see here we're granting agents the option to log a ticket of this type and we're also granting end users the ability to log a ticket at this time so that's quite important yeah also an important point is on the defaults tab there is a show to end user option so if you want these tickets to be present to the end user um you know once they've logged them so they can check the progress of them you want to make sure that straight event user is marked as yes yeah okay and and the other thing is under the defaults as well this is where you're going to be able to set up things like your um you know the default status that this ticket would be created in when it gets created so you've got your yeah exactly whether you want to start a workflow and then an approval process which we'll go through in Num in in a few minutes um and show you how that process will work as well but yeah this is where this is where you're going to set that stuff up yes yeah exactly um okay well let's put it to the test very quickly and let's just log a ticket on the agent side and make sure it's uh presented how you would expect it to be so 1.2 bear in mind is uh uh we have our list of ticket types here um there may be situations where you can't find the ticket type in this list so you want to make sure that in configuration tickets areas your area is using the correct isil type now we're set is all here so we've not got a problem but just bear in mind if you start to drill down and create different areas for different idle types um you're going into the correct area or at least setting the ticket type to be the correct isil type which you can do foreign for a ticket um where you have the ITIL type adjust here yeah cool so let's log access rights request cool so we've got our summary we've got our details we've got our justification with our little red asterisks denoting that it is a mandatory field so I can't actually submit this until I populate a justification we have our option to specify whether we're requesting access to an application where we can see the application list specific to our agents not to our users or are path to directory that is dynamically presented based on our option there that's all looking good and then we have our temporary access checkbox with our hint below if I check that then I've got my date field where I can specify when I need access until yeah cool so um the next point to consider is logging this ticket or end users logging this ticket by the self-service portal um and what you probably want is you probably want to wrap this into uh a catalog of services that you provide the service catalog right so let's quickly hop over to self-service portal I know we haven't done any I don't think we've done any sessions on the self-service portal just yet um so bear with we'll take it a little bit slower and we'll only talk about one specific but important area of self-service portal configuration so it's going to take a look at that so this is the self-service portal and this is where your end users will be logging in to view updates on their tickets raise new tickets check in on the status of services check their quotes look at reports possibly look at entire dashboards of metrics specific to their own company Etc everything here is customizable we'll come back to this in a later session looking at how we sort of customize uh what we're looking at here uh to sort of you know further Taylor the self-service portal to you and your customers needs but for now we're just going to go into the services and products section here now when I click into services and products the first thing that I'm presented with are these options where it's used as a Services Hardware software these are referred to in Halo PSA as service categories if I click into one I'll be able to see the services available within the service category in question and there's actually now as well which kind of I guess similar to maybe an access rights type thing that we have um yeah yeah exactly yeah I mean we've got these sort of baked into the trial um this isn't using what we've discussed today this is this is something else um but but yeah it's sort of a good starting point to get an idea of how one should structure the service catalog but yeah let's add in here our access rights request so fundamentally these services that we're requesting uh what's happening behind the scenes is just tickets of a certain type are being logged so when I go here I'm actually just presented with uh the new starter ticket type right so we want to emulate something similar with our access rights yeah or access request so you can find all of those services in the service catalog module so if you click in here we'll see on the left hand side we have our service categories and within a particular service category we have the list of services that are applicable so for example if I was to click users itself Services then I'm only presented I'm only presented with the services within that category similar so what I see here on the self-service portal so let's create a new service again I'm not going to go into too much detail we will have a deep dive into the service catalog in a later session um for now we'll just look at the real fundamentals and sort of getting that set up as a baseline we'll come back and look at some of the the other configuration options available so um for now we'll just give it a name give it a category um brief summary uh request access to an application okay right and go for grammarly um so the the sort of the the real configuration options what the real mechanics Behind These Services you can find within the configuration tab here now in here um we're going to want to be able to allow users to see this in the service catalog so that's already enabled for us that's great um and below here we have our service request details so this this goes back to that point that I just mentioned our service catalog on the cell service portal is simply a means of raising tickets of a certain type or using a certain template um in this case we want to use a certain ticket type and more specifically we want to use the access rights request ticket type so we'll add in here our ticket type access rights request oh sorry press access to an app slash older yep copy that I'm there um this option is quite an important one show the new ticket screen when requesting the service so we want to make sure that when end users do request this service they are prompted with that form to populate the information uh that needs to be populated there might be instances where you just want to use it to click a button and it just raises a ticket with some default information already applied on it no real user input um and at that point you wouldn't necessarily want to show the form to fill out information you just want them to click it logs the ticket and you know uh your team are informed but in this case we want to make sure this is on yeah save that let's add an icon saved one just before the call see if I can find that here's one I created earlier yeah yeah yeah exactly just like blue pizza right cool um right so let's go back to the portal and let's see if it's here there it is brilliant um again as I mentioned we're going to come back to the service catalog uh we're going to talk about the sort of the rights and permissions to certain areas of the service catalog you might have certain services that only specific individuals within your customers can request um we'll come back to all of that later for now uh just know that your service catalog is fundamentally built up of a series of tickets of a certain type or a certain template and the process of adding or the process of allowing a user to request a new service involves creating a new ticket type and adding a service linking that ticket type to the service that you're creating and then ensuring that that is available on the self-service portal and the result should be something similar to what we have here so we'll click into it we'll click our request and now we see that form again that we saw previously uh this time when I pick application I don't have ninja in the list I have mail or Halo in the list I have MailChimp and WordPress so this ties back to that configuration option that we saw previously where we can specify the visibility of a field for an agent and or an end user so one ticket type one master form but very different experiences for respective individuals that's really cool I mean you could you could actually do this if you know if you had a um an internal user that was locked out of so if I got locked out of Halo or even locked out of any tool right maybe you would want to then have it displaying on the portal to um your your internal users as well because maybe I can still log into the portal maybe I've got a you know an account or something so I can still log into the portal but I just can't log into the user interface I as a as a um an engineer or an agent can still log into the portal as though I was a customer and then try and um access this as well so just in the same way as you locked it down to any specific customers or um or agents you know if you just left those two boxes ticked that had visibility on on all of that stuff then it doesn't really matter whether you do it as a ticket or as a um you know from the portal cool okay cool and hopefully that's all making sense so far yep perfect tense as well it's perfect sense to me I mean I I you know I know this stuff anyway but yeah it makes perfect sense to me but hopefully um it's making sense to uh to anyone who's watching this video yeah yeah okay so um we've got the we've got the form set up and we've got our service so we've tested the logging of the ticket via the agent application and by well example let's just make sure that it logs just as tests man so we've tested the logging of the ticket from the agent application and from the self-service portal um the next point to really start thinking about is our workflow so remember that the workflow is what happens after the ticket is logged sorry Chris sorry I was going to say before you do that actually if you notice um and and you know this is an easy thing to set but of course you were able to not select the application when you created this right that's because you'd make that feel mandatory so maybe what we wanted to do was make the application field mandatory so that because there's no point me putting in a justification and saying I need a you know access to this and I'm not telling you what application it is so um yeah we might want to make it I totally agree totally agree so um what we would do is we would go back to our ticket type go to our field list edit the field or fields in question and uh we'll say on the agent side if uh the application option is selected we must then pick at least one application that we are requesting access to yeah same for the users so we go to end user new ticket visibility we make that a required field probably same for path to direct well probably same after directory and um when do you need access until so if we're if we pick that if we select Boulder as our access type then we must pick a path uh there you are yeah and if we're saying that we only want temporary access we must specify when we want access until so it's a good um and this is actually a good point that this happened because um neither of us kind of spotted this and now we've tested this and realized that actually yeah there's we're giving our users the ability to create something without um you know without selecting an application so it's really important when you maybe scoping these out to really think about you know what do I need to what do I need to make compulsory right they have to be able to select one application there's no point presenting this form to the user and then not allowing them to to select the application um so um so yeah and you you know you need to just kind of decide what it is that that you want to do but as you can see if you do forget it for whatever reason it's really simple to just go back and make that change and uh and it should be good to go yeah absolutely excellent okay cool um so let's just quickly got back to the portal go back home both products and services go to the users and Services Group head to our access rights request now we can see application is Market of an Asterix I've got to pick an application um and then same for temporary access similarly we could see that on the agent side so yeah good yeah thanks uh thanks for supporting that and you're absolutely correct you know it it's a I mean it's true it's true in life right you don't just um you don't just set something up and leave it um really think about this form really think about what needs to be presented when really think about what is required as a field um yeah measured twice cut once yeah exactly and it's and you know it's it obviously we're doing this kind of you know as as part of a um a demo but again you know you might want to make sure that um uh you know you're having in certain scenarios where maybe it's not it's it's not compulsory for the um uh you know for the agent to do it but it is compulsory for the customer so just make sure that you're selecting that visibility and whether it's required or not based on um based on what you've got in here so yeah yeah absolutely I mean we don't have to do it now because I think you know we've we've seen how to do it but again you may want to hide temporary access that says you know um I I don't want that to be visible unless I've picked one of these applications right so I've actually pick an application then I'm only going to see the temporary access box um yeah but so again you know it's it's just thinking about designing the form in such a way that you might want to make sure that certain things show at certain times and what have you yeah yeah and it's um it's nice that Halo can accommodate that I think yeah um sometimes it can feel a bit overwhelming but once you get over that initial hurdle uh you'll really start to appreciate the the flexibility of you being able to lead agents and customers down this path of okay well this is what we want to request so these are the important bits of information specific to that and yeah like like I say leading customers and agents down that path so sure speaking of which um yeah now now the journey sort of Begins the ticket has been logged um and the first Point once a ticket has been logged that we probably want to consider is some kind of approval process some approval mechanism to put in place you know you don't just want any anyone to log into the portal and request access to QuickBooks uh you know admin rights to QuickBooks and just have that go straight through you're going to want some kind of vetting process some kind of approval to put in place um such that the uh yeah the requester you know doesn't just get what they want straight away so so yeah yeah so so if the requester is a um you know yeah need some kind of authorization before they do that then I need to know that as the MSP that hey Chris doesn't have access to be able to just ask these questions right he needs Morgan's um uh you know say so or Morgan's go ahead it's got yeah you you do have you know you do have permission to do this but only for a temporary um for a temporary time something like that yeah yeah yeah really okay so let's have a look at creating an approval process for this so we'll go back to configuration tickets uh this time we'll go to approval processes where we'll set up a new process and we'll call this and so we do have a video on this whole approval process as as well on on the channel um yeah so you know if you want to look into this in more detail of how this approval process works um you know go go and have a look at the video I will link to it above somewhere um yeah yes yeah yeah absolutely so again um we're not going to have a deep dive into approvals uh that that's on that previous video that we've recorded um so yeah we'll just sort of we'll just go ahead and create one here of course I'll sort of outline the core bits of functionality respective to an approval process but but yeah for a bit more of an in-depth look at uh what we're doing here we recommend going to our approval process session so we'll just have one step and that step will be uh you know customer pulling uh I'm just going to call the customer approval yeah so how the hardest part because this is measured yeah okay good yeah um so our approver I mean Perhaps Perhaps who would want it to be the user's manager or second level manager um but this this is contingent on the active directory integration being enabled which we don't have in this instance so we won't use this but we will have um from one of these many options let's hit the where is it [Applause] the change approver at the client so we'll see a few options here so a customer may have several decision makers uh any of which who could make this approval um or it might be that everyone at the customer every decision maker at the customer in question needs to make that approval so um we we can pick from any of these options really but this example let's do I don't know a list of approval users at the client sure um now of course if we're picking from a list then we can specify the number of approvals needed below that we I probably want this to be on the big one yeah I was gonna say you know in terms of this you probably just need one level right you just need your direct manager you don't necessarily need to have three or four levels of approver based on yes yeah yeah exactly yeah which um there's a couple of ways of going about that I mean I think we discussed process rules in our previous session that's another way of doing it um so yeah yeah instead of picking from a list we'll just do the approves that the client uh which you know might be one but you know as I mentioned tickets client and as I mentioned that can be dynamic based on the client that it is or the user that is raising the request in question um dependent on the the ad integration being enabling cool we'll set send an email to our previous just send a standard approval message email we'll say that while we're awaiting approval the status is awaiting approval uh we'll say if approval is not needed then we'll go put it as the new status if it's accepted then you've approved and if rejected to reject it then probably want to inform the user of the outcome so if it is rejected uh they can be notified that their you know request to to access uh the admin the configuration panel within Halo has been rejected or their request to access WordPress has been rejected or accepted so yeah we'll send that information to the user perhaps to the agent as well it's not quite as important in this case however um you might want your agents to be notified of when an approval has been made so they can action that accordingly yeah um and it might be that we only want to notify the agent when there's bit when it's been approved so they can action it but if it's been rejected they don't need to know they just leave it yeah cool leave all of that as it is okay so we have now got our ticket type and we've got our approval the last point to consider is building a basic workflow to apply to our ticket uh to trigger that approvement uh so let's go to config tickets workflows let's create a new workflow now close this step and I'm going to go straight to the details Tab and I'm just going to give our workflow a name and we'll call it access rights request again we've we've done a deep dive into workflows in a previous session um so I'm not going to to explain everything that we see here we're in in detail at least but but yeah sort of assumed that that prior knowledge has already been uh watched a link in the description below on on where that video is so people can go and view it if they need to okay cool cool yeah so we're going to always want the ability to add a private note email the user uh and we'll probably leave it to that our steps will include an initial approval stage once our approval has been made we'll go to uh Justin in progress stage and then just have a completed stage as well yeah now going over to the flowchart are initial step is going to be uh at that approval stage so we're just going to do approval and um we're going to set our workflow action type to be approval process outcome now if the approval process outcome is approved then we can go on to the next step to you know Grant those grant that access and close the ticket off and then if it's rejected we'll just uh if it's rejected we well you what do you think Chris if um if someone raises and access rights request and it's rejected do we want to allow that request to be triggered again or do we just close the ticket off what are your thoughts well I think it depends on on why it was rejected right so there might be and and maybe maybe we should have thought of this in the beginning but maybe we need to build something in there of wires have been rejected because maybe in the justification I gave isn't enough of a justification so it's been rejected but um so now it can either be rejected closed tickets done you have to log a new one or um it could be okay it's rejected for these reasons so the end user now has to go back and give another justification as to why they want to why they want this ticket and then it could be approved yeah so so which one would you say is more suitable well both those scenarios would would work but I think yeah in this one if it's if it's rejected then I think the they need to be able to go back in and maybe give another justification as to why it's been as to oh well I and I guess I I mean I guess if it's been rejected hopefully it won't be rejected because potentially you would have actually probably spoken to your manager about it first anyway right okay Mr manager I need access to XYZ and they said yeah no problem just log a ticket and I'll approve it um but yeah if for whatever reason you haven't had that maybe that initial discussion and it's been rejected then you want to tell the user why it's been rejected but give them the ability to go and recreate the ticket again if they need to I would close it and say they need to re re-enter another one so either they re-enter another one and then we put the justification in or and I don't know if this is possible but if we could just then have it goes back to allowing them to kind of go back in and enter another justification as to why they need to do that I think that my in my opinion is is probably going to be better to do the second option one one ticket multiple approvals firing uh with updated justifications each time yeah yeah absolutely cool so I think that's that's better you're right because otherwise yeah you might just end up having 100 tickets for the same thing in this way rather just go back and um and and redo it again yeah yeah yeah cool um Okay so that's fine so we will um what will what I'm thinking is access right request ticket is logged um the point of it being logged and initial approval is triggered if that approval if that initial approval is rejected have an option to re-request that approval um perhaps even on the self-service portal so the the customer can actually click that again and um fire that off again if it's accepted then we proceed uh to you know grant grant access so yeah um cool so a couple of things to put in and let's start giving these appropriate labels so we're going to say this one is uh in progress [Music] this one is rejected uh this and this one will be access granted so and in our in progress step of our workflow we're going to want to include an uh agent action of access granted I suppose that could be a quick action we could just make that a button at the top um yeah cool so we'll just click you could just add a private note at that point anyway couldn't you or um or a public notes I mean you could yeah uh the however in our workflows we have to bear in mind that it is specific actions that lead us down specific routes so probably one a specific action for Access granted um it's also going to be easier to sort of distinguish from any private notes any other private notes that are added ticket so you can quite easily see when that access was granted you know is it a day later a week later whatever yeah so so just create a quick action here Transit it's going to move us to the access granted step then in our access granted step which is going to be here in with our in progress stage we're going to add an action that is going to be a closed ticket resolve ticket probably want to re-net well this has been renamed in subsequent trials um to something a little bit more sort of multi-purpose um yeah the the action on this version of the trials says resolve uh but more generally speaking what we're saying is close the ticket the request has been fulfilled and then one one more step if that's completed and then perhaps an option in here to really open the tickets and that might take us back to the end progress step so finally we'll take this and we'll put this closed so we've got this kind of feedback loop here once the approval has been made um we we have our access granted once access granted has been formed we then close a ticket and if we need to reopen it for whatever reason we can go back and add further private notes Etc yep if it's been rejected then we'll want an action to re-request approval so um what we'll do is we'll do yeah or or yeah yeah really request just justification or something or now in our re-request action we can include that justification field yeah just leave that as it is I've already put a note field on there as well and then we might want to allow users to perform that action and then down in the details tab for our action we can trigger an approval process that's going to trigger that access rights approval so just drag this like that just make things a little bit more straightforward so what we're saying is if the approval is rejected and we go back here and then we are going to move back to approval so we've got this sort of closed feedback loop so uh notice how this is our green box is our initial step so we can see that based on this checkbox here so when the ticket is first logged we're starting here at our initial approval if it's rejected we have the option to request approval again we can do that until it's approved and then once it's approved we can go down this separate pathway of granting access and with that confident at all so um it's a good that's a really good workflow to kind of um show and I know we you know we covered off workflows in in the previous video but you know this is a real a real world example of where um you know a workflow would kind of um you know work on a ticket that would show kind of you know something that's been rejected or approved or what have you so we can go we can actually go test that and show how that um that helps yeah for sure yeah let's give it a test so we've got our ticket type we've got our service we've got our approval and we've got our workflow and we've seen how we can tie the service and the ticket type together uh now we just need to see how we tie the approval and workflow to our our ticket and by extension to our service so for that I go to my ticket site and I go to the defaults Tab and I'm gonna whenever that is logged uh a a workflow namely our access rights request workflow and and also we're going to start an approval process our access rights approval process all right so just gonna check we do so just can't be Advanced um we've recently introduced the option to allow admins to impersonate agents and users so I'm just going to allow myself to impersonate users um so I can go to Mario and Luigi's Pizza Place and log into the portal as Luigi if I had the option at the top let's just refresh oh I I also need to give him an email address fascinating so so this has been an interesting test of um what we've put together so far so uh the Luigi has the same access permissions as when I previously logged into the portal again we'll talk about that in another session um but for now just bear in mind our access rights request uh option is here so we'll go in request that say that we want access to an application what application WordPress do we need temporary access yes just until the end of the month need to make some website changes should be done by end of month yep so um let's have a look at what's happened here so the biggest been logged uh interestingly it's gone straight to approved and so let's have a look firstly at our approval go to config approval processes go to the process in question and we're saying that all uh approvers at the tickets client must approve so it may be that no one is a change approver yeah so I was just going to say that we didn't have anyone I was trying to say that earlier on I think we need to check who's on our change approvers board um yeah yeah well uh yeah yeah so um what we'll do is we'll go to Mario and Luigi's Pizza Place and let's pick Mario as Mario wouldn't be the one logging the ticket well we can see that Mario can't partake in approvals and neither can Luigi so let's go back to Mario make him an approver run through that again making some websites changes should be done by end of the month so now instead of the ticket coming in with the approved status straight away we can see it's awaiting approval we hop over to our service desk we can see there it is at the top WordPress approval 2.0 or whatever that says approval um and down here we can see against the ticket in question the the approval that's been triggered and who needs to make that approval uh we also see all of that information against against our ticket so we have the uh what's being requested uh the user application so again we might want to hide this so we can do that by go into our build list for the ticket type go to business application and we can actually specify that fields are hidden if they're empty so not only do we have Dynamic field visibility but the point of logging a ticket we also have Dynamic field visibility once a ticket has been locked again that's a prime example there I don't need to see both of those application Fields I only need to see the application field that has been built in so that's that's quite handy um cool so we're awaiting approval here can't do anything can't perform that action uh as an admin I can approval Mario's behalf now it's been approved you can see that you know I've taken the liberty of marking that as approved um and now we have our access granted option again this is based on our workflow only allowing prospective actions at any given point so I can click that this probably don't want this what we're looking at here is the default Behavior uh default response behavior for the uh the SLA intera interaction with the action um so what we want to do is go down to the response behavior for the action and say do not respond so now I can click that doesn't give me a pop-up she does it straight away access has been granted we can close that off let Luigi know that he's got access to Wordpress for the end of the month okay excellent so that all works as far as being approved so let's go in and do the let's reject it and see what happens when we're reject it because we should be then seeing it kind of come back up giving them the ability to to do it so um so this time don't give ten like I want full access and then I can say I'm going to reject it because you know I'm happy to give you temporary access but not full access I want full access forever yeah or something yeah full access to male gym uh I love sending marketing emails all right so go back into our list just refresh that very quickly there it is MailChimp access so then um Mario rejects it we've internally we've got the option to re-request so of course you know Luigi could call up and say oh I want to request it again and the agent could do that on their behalf or we can actually give end users the opportunity to perform actions themselves um that was based on that was based on our option here allow end users to use this action yep where I've got my justification again you know sorry I only want 10 access until end of month yeah that then fires that approval back off see that's awaiting approval again and here we are in this time Mario could give it a thumbs up and now we can go ahead and Grant that access so just to kind of reiterate what's happening there we'll go back to our workflow in the first example we logged the ticket well in in the very first example no one was an approver so it auto approved so we went straight here we we started off at our initial approval it was automatically improved because there was no approver so we went to our in progress step um we then marched Mario as an approver at which point the ticket came in and we only had the option to email the user or take a private note those options are available based on our actions allowed at any step I then approved that and we had that access granted button pop up because we moved from the approved step to the in progress step then finally I logged another request I rejected it and we saw that on the agent application and on the self-service portal that re-request button came up with the justification field present I re-requested that hence taking us back to our approval step I then approved it and whoever game yeah brilliant yeah so that's and and I mean that's a really good example of kind of how you might do something like this to give somebody the ability to um to request approvals and yeah and that kind of thing so um if anyone watching this um you know if you've been following through and you want to try and um you know get all of this set up and need some help you know obviously I can help you with that as well um or you can reach directly out to the guys at Halo you know they can they can help you on this as well but you know maybe um as a good little kind of test for for anyone who wants to play with us is you know go through this process and then maybe add some other things to the um you know to the workflow to um uh you know maybe once the ticket is has been approved maybe then um you know we have some other actions that we might need to do over and above that but also you know maybe add a justification or a um a reason for rejection field right so that might be another thing is okay well I've rejected this as a manager but what was the reason for me rejecting it um so those are things that people can add I can help you with that Morgan can help you with that um but hopefully this is given everybody a really good idea of kind of how um you know how to set up a a ticket type then you know how to link that into um a workflow and then go all the way through the the ticket approval process as well yeah yeah absolutely it's um probably the longest session that we've we've recorded so far um but it is important to give the audience an understanding of you know the the whole picture and uh I think we've we've done a decent job at presenting that you know we've looked at everything from creating Fields setting visibility restrictions setting Dynamic field visibility for that field list making the the tickets hype present on the portal within the service catalog um we've seen how we can build a basic approval process and complementary workflow and how that all ties together so you know you might not be using this exact example uh but the the underlying process of how to go about constructing a workflow with an approval in it uh should should hopefully be better understood now so yeah yeah thanks for having me Chris yeah absolutely well as always thank you Morgan really really appreciated what um I'd like to do on the next video um is is maybe we can actually talk a little bit more around the um the self-service portal a little bit more and maybe we can even add on to this it might be nice to kind of use the chat facility to be able to say hey I want I want to use that to actually request the um the approval as well so we can we can kind of talk around that but I think yeah we definitely have um have have quite a lot of other videos coming out and and the customer portal is going to be next so um as always thank you so much thanks to Halo for allowing us to do these and allowing you to you know spend the time with me on the call going through this really do appreciate it and um I look forward to seeing you on the next one yeah always a pleasure yeah thanks Chris and thanks everyone for watching excellent thanks