foreign I'm Tim Schluter and today we're going to be talking about the customer service with service management and customer service with request management plugins we're going to start out with the customer service for service management plugin that is the integration between cases and incidence problems and changes then we'll do a quick demo to see what that looks like then we'll move on to the customer service width request management plugin very similar to the service management plugin just it only covers requests and then I'll show you what that looks like as well and then I will go ahead and show you what we could do to get this set up and some other additional configurations and then if we have any questions we can take a look at that at the end so starting off here with the customer service with service management plugin as I said that's how we integrate cases with incidence problems and changes for all three tasks it gives the customer service agent the ability to either create tasks or associate open tasks with the case they're working and then it will update the case as those tasks are being worked so starting here with Incident Management the customer service agent will be able to go to the additional actions menu item they'll be able to click create incident or they'll be able to go to the incident field on the case and Associate an existing open incident if they create an incident from the case the Fields here are what will be pushed through the short description urgency CI those are kind of standard across all task types for instance specifically the contact will be set as the caller on the incident and then also new with this plugin is the related records tab on the case and that's where the reference to any incident problem or change that you associate will show up there if you have any other problem or change already associated with the case that will be mapped to those same fields on the incident record also also under the related records Tab and then as the fulfiller works on the incident as the incident State changes that will be noted automatically in the casework notes if the fulfiller adds any additional comments to the incident those will also get pushed to the casework notes and then if the incident is put on hold the on hold reason will also be noted in the casework notes and we'll look more at that in the demo problem management is similar to Incident Management and how they're created you can use the create problem UI action or you can associate an existing problem upon creation you get those same kind of standard Fields but then what's slightly different is the case will be put into the first reported by field on the problem and the account from the case will be put in the company field on the problem and similar to incidents anytime the state changes that will be noted in the case work notes the worknote updates are a little more involved with problems there's a couple more things that can trigger that so on the problem there's the communicate work around UI action and the communicate fix UI action when the work around UI action is clicked the text in the workaround field will be pushed to the casework notes and if communicate fix is clicked then the text from the fix field on the problem will get pushed to the case worknotes there's also a couple different ways that a problem can be closed out and that will change what what information gets pushed to the case so if it's canceled the cancellation reason will get pushed to the casework notes if the risk is accepted then the cause and fix notes will be pushed to the casework notes as well as the risk accepted reason if the fix is applied then just the cause and fixed notes will be copied to the work notes I have an example then the demo as well and then change is similar in that you can associate an existing change to a case but then there's also there's two UI action options there's the create normal change and create standard change create normal change works like it does with incident problems it grabs with certain information from the case and it populates it in the change that's newly created automatically however if you create a standard change that will link you to your standard change templates and all of the data will be pulled from the template only it will not pull specific information from the case besides the actual reference to the case so that adds the change is being worked whether it's normal or standard the work notes will still be updated on the case as uh as that changes work through so similar to instant it's when the state or type of the change changes that'll get pushed to the work notes any additional comments added by the fulfiller will be pushed to the casework notes and then when the changes put on hold or that on hold status is removed the casework nodes will show that as well and so I will show you here just what that looks like from the customer's perspective kind of what they see as this is all going through as well as the fulfiller so here I'm going to submit a simple case as soon as that loads here we go we'll say issue software after update this should redirect us to that ticket View so then from the fulfiller side we'll take a look at that case here we'll see what's new here is that that related records tab that I mentioned if I know that there's an active incident I could come in here and Associate that again note how any of these require the issues to actually be active we'll say for the take this demo that I know that there was a a change potentially that caused this right and then I'm gonna go ahead and come up here either by right clicking this header or go to the additional actions and I'll create an incident so incidents created the contact is set as the caller whoever this would be assigned to could work as as usual for this case I'll just I'm just gonna continue to be the admin here but I'll say we'll move this to work in progress and we'll say looking into issue update that and we'll see on the case that a work note was added and that the state has changed and you'll notice for all of these updates they are going in as work notes right so the customer isn't seeing any of these changes taking place it would be up to the agent to be communicating what's necessary I think it's reasonable to assume that some of our engineers and admins do not have the same smooth edges that are customer service agents would have and so any updates that they're making here can be you know translated into customer speak by the agents and so we'll go back to that incident and the agent would be able to to read this as well what the proper roles we'll go over that at the end as well so let's say the fulfilliers all good closed out actually we'll do that the proper way we'll we'll resolve it so here the agent would be able to see that it's been resolved that the fix is provided so it'd be up to the agent to come in here propose a solution to the customer and with this plugin comes a couple new resolution codes you'll see resolution codes related to problems being solved change requests being closed incidents being closed and requests being closed fixed by closing the related incident proposes solution and then from there it's just acting as a standard case and then that would be up to the customer to accept that solution so it's going to behave similarly for changes and problems I have a couple that I submitted already so we can just take a look at the notes there rather than having to bounce back and forth so here A change is already Associated oh and another important thing is once once a record is already Associated whether it's instant problem or change the UI action will disappear so here create normal and create standard change isn't an option anymore if incident was populated that create incident would also be no longer available and If you if you dissociate the record than that that you action would be available again so here for the change we'll see that it was Associated a comments added as the states moved the the timing for the change would be communicated as well this was empty so it's just showing the the time zone but those fields automatically be communicated as well same thing with the change being put on hold down hold reason is also communicated and again this would be on the agent to communicate this with the with the customer and then we'll take a look at one that's been linked with the problem we'll see that the change in incident actions are here now and problem is removed since a problem is already associated and you'll see that if a task is associated whether it's by creating the task or by picking an open task that'll be noted and if you remove the task it will note that as well but here you can see for the problem any state changes are communicated I did do that communicate workaround on the problem and it pulled the information there more State changes and then here I did fix the problem right and so it'll show the how it was resolved and then it pulls in those costs and fix notes and that's pretty much it for the service management plugin we're gonna move on to the customer service with request management plugin it is very similar to the services service management plugin just it only integrates cases with requests similar to how that works with instance problems problems and changes the agent can create a request from an existing case that create request doesn't just create a request record right it would link you to the service catalog what's new here is that the or what's different than the service management um plug-in is that the customer will be able to directly submit a request from their service catalog so they don't have to submit a case first and then have the agent on their behalf their request can can be submitted by them not a lot of information is passed through just a short description there is a variable set that's included with this plugin that you can add to your catalog items that will allow the customer to enter their name and then the account they're associated with and then just the the request State changes and then any additional comments added to the request item will be pushed to the work notes of the case and I'll show you what that looks like here as well so similar to how we submit a case the plugin allows us to add Quest catalog items to their service catalog and here I can as the customer submit a request directly when a customer does submit a request though a case is automatically generated and again that's what they will see on their end so just like we did with a normal case I'll get linked to this case view the only difference here is there is a initiated as request for false field that is set to true and that's how you can differentiate kind of on the back end which cases were created um as a request originally and there's also a list option to kind of see these so I can see my requests versus you know all my other cases and we'll click back into that guy and from the perspective it's just like you'd work any requests request comes in the request item is created we'll say hey work is in progress here oh similar to the other task types this information goes in as a work note on the case so it's up to the agent to communicate this update to the submitter and then just for the sake of the demo will get this closed out here then we'll take a look at the case on our end you'll also note that the the state isn't changing right there's no actual changes outside of the work notes being made to these related cases so we'll see that work with some progress now it's closed and it would be up to whatever agent is working this to communicate all this to the submitter now we'll go over how to get this set up and additional configurations that can be made setup is pretty straightforward there's just the two plugins you have to make sure that you have the customer service application already installed right but there's just the customer service with service management plugin there's customer service with request management plugin if you don't want people to be submitting requests or working with that you can just choose the service management Plugin or vice versa there's no new roles added either with these plugins all the roles already come with the incident management application right so there's the task specific write and read roles the write rules allow the agents to create the tasks and then the read roles will allow the agents to actually view the tasks if they're associated with the case if you want to change which fields map automatically between a case and the new newly created task that's handled through scripted extension points those extension points call script includes that are listed here your platform admin would need to go in and you can either use it just to add new feed the logic as to when certain fields are mapped or maybe you can do some Dynamic work around dates whatever whatever would fit your needs but it does it does include or does require scripting if you want to do it with anything outside of a business rule or something like that and then there is also a way to allow for external approvals so if you have a request that your customers can submit but maybe you have a partner that owns part of the process and they need to approve those kind of requests then you can add those Partners or whoever to an approval group just like you would otherwise and then you need to make sure that you have the ACLS to allow approval on the change or request records for any user with the snesm user role that role is what's included with customer admin partner admin customer partner so any external user right that has a role and then if you want to extend that ability to approve for external users to other tables that's also handled in the extension point the global.csm approvals management and is there any questions am I I have a question I think it's in by intent that the status or State field is not present on the case form they want us to use the ribbon it can it can be made visible but I think out of the box I think it's hidden is that correct that's right this Dev instance I'm showing is is fresh out of the box but yeah you can absolutely absolutely display the the State field there would best practice be that the case remains open while the related records like the incident or change or request are open or do you kind of close it out and then track the work on the related record so I would let you know back-end support do their work on the related record and then I would keep the case open as the agent so that if there's any because sometimes there's going to be information needed from the submitter so if it's something instant related right they need like a log or something from from the customer then the agent will be able to keep track of that and communicate that with with the customer um and so as long I'd say as long as the related tasks are open I would keep that case open for that kind of communication okay so that's kind of standard rules apply there right across the platform and it makes sense right so any related tickets where the case is indeed The Source or if we want to use the parent in that case it would be the case would be the last thing to close once all the related records have been dealt with Etc if an incident is big enough that it causes change to be pushed through then you would want to make sure that change is completely finished you know and then you can verify that the the change actually fixed the instant right before closing that incident so yeah it's the same same kind of logic So to that point then if there's like let's say an incident you know how incidents Auto close after let's say seven seven days and there's a delay between when the incident was closed and when the customer the case was you know put in resolved right I guess the protocol there let's say the issue wasn't resolved I guess you would have to just create another incident and related to the case or um how would that be handled well if if the I think we're saying like if if they put the incident resolve right and it closes in three days but then the agent doesn't resolve the case until the next day so it has its three days to resolve or whatever time frame is and then that incident closes and then the customer you know denies the solution and it reopens the case yeah if you're not gonna be opening the incident then yeah you just need to create a new one and I guess re-explain what the what the problem is yeah I guess you would just you would just lose that initial link to the first incident from the case perspective at least you'd relate the new incident to the one that was recently closed right so there's like a connection there bridge but yeah I could see that the uh yeah there's there's a parent incident field on the instant record that you could use to to kind of link it that way if you wanna create that chain I was wondering so it like from a process perspective if I'm in a workshop what should I be listening to to determine okay this plug-in should be installed versus this Plug-In or maybe just go with the out of box version of CSM if part of their process is that they're getting other teams involved right because it's it's licensing to give people the or takes licensing to give people the agent role right but if you already have X number of Ito roles that are being used by the people actually doing the work and you can just keep whatever your your small team of customer facing agents licensed there then that would be a good way this is kind of a good way to not get around but I mean it's it's the servicenow way to to not have to to buy all new licenses for um the people that will actually be doing the work to resolve these issues so in this situation if you were to have the plugins you would say the agents would be the ones that are also the you know like the support or the service desk and they wouldn't have need have uh separate licenses maybe I'm not understanding the answer sorry I guess the so the agents would still need their CSM licensing right but I'm saying the the people with the ITIL role the person who um maybe the engineer on the background who's who's making changes um to the back end for them to get visibility into a case you would be potentially running into licensing issues there but with this now the all the necessary information from the case is being pushed to the incident so they don't need any visibility into anything customer service related in the demo a couple of them scenarios where the status changed and you mentioned that the you know the the customer whoever needed to be notified how does that notification happen is that from a mechanism within servicenow or is it just an email a phone call like how does that so I would say the the agent would add the additional comment because there's the two types of fields right work notes that stay internal in the additional comments and that goes to the actual submitter all the updates that are coming from the itsm task whether it's incident problem that's coming into the case as a work note so only the agent is seeing that update they would then go in and if they want to email a call however they want to handle it but they could add an additional comment and then that would be what's visible on the portal View for the customer foreign [Music]