Sessions
4863 sessions, 88 canceled
How to avoid causing skipped records
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Howdy. And welcome to Creator Con. I'm here to share with you how to avoid creating skipped records. My name is Kim Reverman. I am the ServiceNow architect for Texas A&M University. We are a multi-tenant instance with multiple universities, colleges, departments, and agencies. We have over 1,000 ITIL users and a user base of over 400,000 users. With this configuration comes a significant number of customizations and, of course, skipped records. So I'm here to tell you and share with you what we did to avoid creating skipped records. One of the things that we were challenged with was reduce the upgrade duration time and increase time spent on improvements. And I'm going to show you we have. Here's some background about us whenever we first started. You can see there was a sharp rise in the duration time to actually getting an upgrade delivered from when we first started our clone to whenever we put it on production. And it took us up to three months for several of the upgrades. And now whenever we're deploying a major upgrade, it's taking us less than a month. One of the things too is our customizations were also rising. And we noticed we have a huge technical debt because of running a multi-instance. We adopted a strategy for getting back to baseline. And we've been still implementing new products since then and keeping our skipped records low. During the London upgrade, we leveraged the really sweet ServiceNow upgrade feature to only review the skipped records that were actually changed. That saved us a tremendous amount of time there so thank you, ServiceNow upgrade developers, for that feature. We really appreciate it. Getting back to baseline or as close as you can still isn't enough. How do you keep it there? And that was our challenge. Here's what we did to stabilize the growth of creating the skipped records. We made the ServiceNow records stand out using Field Styles. Using field styles, we were able to color the ServiceNow records with a green background. And if they happened to be modified by us, then they're priority one or two, then we're going to put a red border around them. The priority three and fours we have a dotted orange border, and the priority five a solid green border. Anything else created by us is left white background with a black text. Now the script that we use to control which of those styles we're going to show is called CreatedByNow. And I'm going to give you a demo of what you will see if you installed this script on your instances. This is Problem Management. It's the Configure All section. And as you can see, here are the business rules. All the records you see with the green background are ServiceNow records. The ones with the white ones are ours. And the ones that the very bottom there with the red dotted border is the ServiceNow record that we modified, a.k.a that's a skipped record. Here are the client scripts again. We have some that we've modified, and some that we have not, and others that we have created. And one of the things that's real nice about these is when we are looking for problems, we can easily see, OK, well, let's take a look at our modifications that we made, the things that we created first, or what did we modify and take a look and see if we need to make some changes there before we modify something else. This is the dictionary entries. As you can see, they have the green border around them because those are priority fives. So what does the script do? Well, first thing that we're going to check for is to see if the record is in our scoped app. If it is, it's ours. The background will remain white. Then the next thing we do is we look at the versions, just one record, to see if there is a sys update history record and see if it's current. If it is, it's NOW's and therefore it's going to remain green. If it's not current, it's NOW and we revised it. Any other version records is ours. Those are all going to be system updates set records. Since I didn't show you the script and you're probably curious about what you can do to get it, go out to SHARE. It's in the developer site for ServiceNow. And link for CreatedByNow or scan the QR code here to download it as soon as you can and install it. If you want to contact me, my information is here. I'm also available on the ServiceNow Devs Slack website community, an awesome place for getting help at any time. Thank you all very much for coming to Creator Con. Enjoy and be inspired to do great things. Thank you very much. [MUSIC PLAYING]
A ServiceNow discovery spoke to setup workflows for your IT operations
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hi, everyone. Welcome to this breakout session on the topic ServiceNow, Discovery Spoke. This session is about Discovery Spoke that I've prepared some time back. And with this spoke, it allows you to set up workflows for your IT operations. So my name is Alikutty Abdulrazak, and I work as a senior solution architect at Wipro. My functions include as a TUE lead for Wipro. I handle all the solutions and the prod offerings. Apart from that, I'm also involved in supporting the pre sales and delivery teams. But my experience, I have over 12 years of experience in the IT industry. I've worked in different roles as in service delivery and also in pre sales. On my expertise here, I have [? family ?] worked on different IP workflow products, employee workflow, as well as created workflow products. And I've been also part of community MVP for the past five years, and also part of the developer MVP for past two years from now. So something about by myself. Going to the topic here. So the discovery spoke. So this is a custom spoke which I have built, and this allows you to perform horizontal discovery via flow designer. So being working with different item implementation for a long time, there has been always a need to-- as you know, you have to set up workflows for your IT operations. There are different use cases that you can come across during your implementation. With this spoke, it allows you to set up no code, low code workflow for your IT operation. As a part of this spoke, I have two different actions that have been built. First action is about discovering any device in your infrastructure. It's called as discovered by IP address, and it allows you to discover any of your servers or your network devices within your infrastructure. There is also a second action within the spoke, which is get status details. It is the corresponding spoke related to the discovery, and with this it allows you to extract the discovery result and you can validate whether your discovery is successful or not. A couple of use cases where in real time you could use it. One of the main common use cases that we have is the infrastructure change. So let's say you have to make a change to your server, for example, adding more CPU or adding a disk. Whenever the specific change is implemented by your IT team, you can use this spoke to trigger a discovery to your infrastructure. Since you have the server as your CI on the change, you could access the IP of the CI and trigger this workflow. And with this workflow, what it gives you is the latest changes in your infrastructure. So let's say you have added more disk or more memory. The same things get discovered at the same time, and this allows you to validate that your change has been successful. You can set up such workflows for change. Apart from this, other common use cases that I've come across is when you have alert management. So if you need to remediate the alert by restarting a server, then this is a case where you could use this spoke to rediscover your server and make sure you know your server is back up to normal. That is another use case where you could use it. Another use case is regarding software installation and uninstallation. So whenever you have a software installation happening in one of your servers or any other infrastructure, this spoke would, again, be used to discover whether the software has been installed or not. It would act like a failover, for example, you have a CCM to do this. In case of that installation fail, with the help of this discovery spoke you could actually open a path to the asset team to validate it. So it's kind of an instance failover. Apart from this, you can have it used for any of your orchestration uses with your servers or within your infrastructure, or also on any other discovery request. Now this spoke is available in the share repository. You could search for ServiceNow Discovery and download it. You can also import from GitHub in your source control. Additionally I've also put up a documentation for this in the community blog. So this is the spoke, which is available in share repository here. You can search it for ServiceNow Discovery Spoke and download it from here. The GitHub URL and also the documentation related to the spoke is available within this repository, so you could access all the details regarding it. I'll now show you a couple of demonstration use cases on how you could use the specific spoke for your discovery, for infrastructure discovery. Coming back to my instance here. So I have the spoke already set up in my personal instance here. So you can see that this is the primary action that I have. This is called as a Discovery by IP address. So you can discover any devices from your infrastructure using this. You need to provide the IP address from your CMDB. So primarily, a prerequisite is you already have discovery set up in your instance. So I'll just show you how to test this. When you test it, you need to provide a specific IP address, so I'll be giving a sample IP address here. The second input that you have here is the source. You can specify any task number which is associated with it, which you are trying to relate it to. And also have the option to select an application. So this is a [INAUDIBLE] server that is associated with your discovery. For now, you select this as all and I'll try to test this. Once I click on Run Test, it would actually start triggering discovery on an infrastructure. A discovery status record would be created. If I open the results of this, you can see here that the discovery status has already initiated. The discovery of this device is in progress. Now if I navigate back to my instance here under discovery status, you will be able to see that a discovery is already started here, which is active, which has been initiated by the spoke. And if I go to it, you'll be able to see all the results regarding it. So as soon as this is triggered, system will try to access the device information. Once the discovery is completed you could use my second spoke, which I've built, to access the discovery result. So let's see what the second spoke is about and how you could use it. We're going back to the second spoke here. The second spoke is get status details, where you could provide your discovery status with just an output from your first spoke and then see what are the results. So let me show you how the results would be here. So I would be selecting a discovery status and I would click on Run Test here. I would start extracting the discovery of the results from my status record. And if you see the results here, you can see I will get the complete details of my discovery. This would primarily be an adjacent reformat here. You can see the sys ID of the CI which was discovered, the class of the CI, the IP address related to it. If there was any issue associated with the discovery, that information is also added here and you would also get that issue link, which would be in HTML format. Finally, you would also get the status of the discovery, whether it was successful or not. And depending on these choice values, these options, you could actually trigger your workflows for your IT operations. You can also get multiple discovery value. For example, if you are discovering a subnet of large number of IP, the second spoke would be used to get results of multiple devices as well. So that is about the second spoke. Now coming to the two different use cases that I have set up. So I would be just going through the first flow here, which is a use case for change implementation, and I'll also demonstrate a second use case which is regarding software installation. So this is a flow which gets triggered, the number you change is getting implemented. That's the trigger condition for it. As we do it, what we do here is we would call up the discovery spoke here and the discovery spoke would access the IP address of your CI, which is on the change. You would also see the source as marked as a change request number here. Once this is triggered, you need to wait until the discovery is completed. And once discovery is completed, you can use the second spoke here to get the status details. So depending on the results which we get back-- so let's say I have an issue in discovery the device status was not successful. I can open a task or an incident for it, or if it was successful I can update that the change was successfully implemented. So that is what the specific flow has done here. Depending on what output you get from discovery, the change gets updated. So this is the first sample use case that I've built. I have also another use case, which I will be demonstrating today. So this is regarding software installation. So whenever you install a software, either it might be depending on automation. You have automation enabled using a CIS-EM or any other product, or it may be a manual installation. So right now I've considered a manual installation because I don't have that automation tool. What this workflow does is whenever you have a software request on your server-- so let's say I have considered WinZip as an example here. This is a workflow that would be associated with your software request, basically your service catalog. What we do here is basically it first goes to the manager approval, depending on your process. Once the manager approves, it creates a catalog path for the asset team. Now this can also be an automation. If you are using a CIS-EM, you can use the out of the box CIS-EM spoke for this, which would automate it. Once the task is manually set up by the asset team, in our case here, the spoke would be automatically triggered here. So this would be, again, discovering your infrastructure. It would capture the new software installation information. It will bring it back to the instance here and depending on your software installation status, let's say if the study was a success and I was able to look up the software installation record, it would be a successful installation. If I was not able to discover the software, then the catalog task would be reopened and the asset team would have to handle it. So this is kind of an instance failover where as soon as you close the task, if discovery is not successful, the asset team would have to handle it again, giving a better user experience. So let's try this out. So I have set up a catalog item for this. So I would open my software installation catalog item for WinZip here. You can also request this from Virtual Agent, if you want. That's also possible. I need to select a server here where I would be installing this. So I select my server name here, which I have already access into, so I select the server. So before opening, before going to this, let me just go to the server once and I'll show you what is there currently in the server. Switching back to server here. So this are all the information regarding my Windows server that I have. And if you see correctly, I have around 25 softwares which has been installed in here, and you won't see the WinZip as currently installed as a part of this list. So once I do this workflow, you'll be able to see that the WinZip gets discovered, and automatically it would also help in setting up my IT operation process. So now the request is submitted. I would have initial approval for this, which goes to the manager. It's a normal process of a task setup. Now I have approval here, which I'm just going to bypass this. An approval. So as I approve it, a task would be created for installation. Since our case is a manual installation, task is created. If this was automated installation you could directly install it even without a task. So let's do one thing. Let's also install the software directly on the server. So right now I'm going to switch back to my server here, which I have opened up. I have switched back to my Windows server here where I will be installing the software. So I have the installer here for WinZip. Just take a minute to install it, so I'll begin installing it. So it's a normal process. As an asset team member, once you get the task you try to install it. Generally this would be an automation. You would have an agent set up which would automatically install it. But just for the sake of demo, I'm just installing it. Now if I try to close my task without installing it, it would trigger as a failure. It would reopen my task and it would notify the asset manager. Right now since I am actually installing it, this would actually be a successful use case. And when I close the task, it would trigger the discovery and let me know that the discovery was successful. So that is typically the use case that I have set up here. Now installation is almost getting complete here. OK, so this has been installed and that process is completed, and also we can see the software has got added in my Windows server list here. Now going back to my instance again. Now since the installation is over, I would actually be closing this task manually for now. So as the asset team member I'm just going to close this task. As soon as I close this task, the discovery for that specific device is triggered. So I just open the related flow here. So you can see the corresponding flow and how it is getting executed. So the flow is just opening up. So here you can see that as soon as I close the task here for the catalog task, the custom spoke for discovery is triggered. Now it is just waiting for the discovery to complete, a couple of-- might take a couple of minutes. As soon as it's complete, what it does is if the discovery is a success, then it tries to look up for the software record. Now the advantage here is the catalog of items linked to the software model, and the software model is also a part of your SAM process. In case you are using Software Asset Management [INAUDIBLE],, you can link both the software model and the discovery model together and you can set up your installation process for this. Now let's see if the discovery is getting completed or not. So now it's completed, and the process has also completed. Look up is completed. And if I go back to my device here, software device here, you can see that an additional software is also added. Right now we have 26. And if I scroll down, you can see the WinZip software has got added. It has been discovered as soon as I closed the task, and that has also been validated by my workflow there. So using these two custom actions that we have, you could actually set up any workflows for your IT operations depending on your use cases. It's possible to set it up. And you could use it for any kind of infrastructure validation. With that said, regarding this session, thank you all for watching.
Multi-source eBonding– the one ring to rule them all
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hi. I'm Christopher Carver. And I'm here to talk to you about multi-source eBonding. Before we get into that, let's talk a little bit about me. I'm a technical architect here at Textron helping them realize ServiceNow across the enterprise. Textron has customers in defense, aerospace, specialized vehicles, turf control, and fuel systems. Now, let's go ahead and get into this topic of multi-source eBonding. So Textron actually has engagements with a lot of external IP service suppliers that perform various operations within our enterprise. They can do everything from server support to database support and call center and data recovery. Now, Textron needs to eBond with each one of these individual companies and making sure that our ticket communicates with their ticket in their ticketing system. So initially, when we set out, it was a one-to-one correspondence between our tickets. However, have you ever run into an issue where you need to coordinate the work with multiple external service suppliers where you have an outage that involves multiple parties to communicate? Well, initially, our major incident manager, here at Textron, would end up creating four or five incident tickets and make them children under a big ticket, but then they would have to manually ensure that the coordination of information from one supplier made it into the other supplier's ticketing system. This is a huge burden for them and didn't scale very well. So we needed to create a new solution to allow us to work together. And the idea behind it is that we only wanted one ticket here at Textron, and updating that one ticket at Textron actually updated all of our IT service suppliers across the board. What this meant was is that if a supplier updates their ticket, that information would flow to ours. But then our system on the ServiceNow platform would be intelligent enough to update the other suppliers and their ticketing system. That way the data flowed smoothly between suppliers. And that no supplier actually needed to know who the other company was that they needed to interact with. We took care of all of that in this new framework. So let's talk a little bit about the ServiceNow components that comprise of this multi-source framework that we're putting together. So the first thing is we take advantage of the out-of-the-box experience on the platform for imports [INAUDIBLE].. OK. That is a very powerful ability within ServiceNow. But we went ahead and just leveraged out of the box that other suppliers will actually write into the single import table, and then we take care of that transformation. The other thing that we needed to build, and this is the core, this is the part that really makes this all run, is we did create a custom table called the relationship table. And this is a one to many relationship where we have our one ticket but then we know which tickets on the supplier side to update and keep them updated. And lastly, we did create another custom table. And it's our payload table. That's to ensure that as we're sending outbound messages, that we keep track of those messages and then are able to recover and do some data recovery if necessary. And we'll talk about that in a little bit. All right. So let's now move on to the inbound topology. So everything that you see in blue is within the framework. It's static OK. That way as we on board new suppliers during the initial engagement, we would just work through the data mapping session. How do you talk to us? Because as soon as you send us the right message and we then set them up, everything is set in place. So I don't have to rewrite everything from scratch for every supplier. So what they'll do is they'll actually write into the import set staging table. Then we'll perform the transform. I say we, but we know it's ServiceNow at the back end, the platforms do the transform. So we set up that transform to actually do the logic. We do trust our vendors, but we also want to verify all that data coming in before we write it to our system of record table for that incident or ticket. The target table for our transform though is our relationship table, and that is key. Once we've written to the relationship table, we then know on the final steps of the transform, do we create a new ticket? Or do we update a new ticket? Now, the outbound topology is a little bit free. There's a little bit more involved. However, we try to streamline out all of the static areas, once again, in blue. That once it's set up, you don't have to change it for every supplier. The other items that are colored is what we would have to put into place for every supplier as we on board them. So we did set up a standard business rule that would look at the ticket table of the ticket that we're looking for, and then we created an event that's unique for every supplier. And the reason for that is just as we said in the inbound, where the supplier needs to talk to us how we ask them to talk to them, in return, we talked to the supplier how they want us to talk to them. So we actually had to create an event that would be sent, and then we would take that event and process that and build up the payload of the data that we've captured from the ticket. We then send the payload down to our REST handler that would end up sending that message over to the supplier. And we use asynchronous communication calls, and we'll talk about that in a little bit. And then when the supplier is done, they'll send that message back. And then we actually have another handler that's listening on the ECC queue on processing that message back. Because typically, when a supplier responds back to you, they have their own structure of their response message. So we have it unique for every supplier. As that gets sent back, that also is updating the REST payload table. Now, on the far back inside is the payload monitor. And the payload monitor, what it does, is schedule a task that is set up in ServiceNow and it, monitors the REST payload table. And what it does is it determinants do I try to resend the message? Has the message timed out? Because we have to remember the internet is like the wild, wild west. You don't know what's going to happen. Something can happen in between the external service suppliers ticketing system could be in the process of being upgraded. So we need to be able to true up all of the missing messages that we weren't able to send to that supplier at a later date. So let's talk about some of the lessons learned that came about all of this. So the first thing is the concept of reflect or deflect updates coming in from the external service suppliers. So imagine you have this large party. Everyone is talking together. One of your service providers, they're done with their ticket. So if they close their ticket, do you reflect that closing your ticket. Well, if you do, your other service suppliers might think you're closing it out. It's all solved. So the question then becomes should I reflect that change or deflect it? And in that case, we would have deflected that change, just made a work note and pass that work note on to the other suppliers letting them know another supplier has closed out the ticket, is they're done. That might trigger them to take further action on their part. The next part is asynchronous REST calls. This was a game changer for us. It not only helped us improve our performance, but it also helped improve our scalability and led into the third point. Now, I included a link in this presentation. I don't know about asynchronous REST calls. I totally recommend you read up on that. And the third point of scheduling automatic recovery, that was because of an outcropping from asynchronous operations. We were then able to perform that automatic recovery, and that was a great lesson learned. Because we used to do synchronous calls, and that was a real performance killer and made automatic data recovery very difficult. The next one is truing-up those conversations. Back to that party. You've got a big party, but now you need to eBond with another supplier. You're pulling in this new supplier who needs to do some work, yet they're late to the party. So you need to be able to true up all those prior existing conversations and files that you've been sharing, and let them in on what that conversation is about. So don't forget about turning up those vendors keeping them up to date. And lastly, don't forget about deBond. It's just as important as eBonding. Sometimes you need to decouple your ticket from another vendor. So make sure that you work through that with your vendor, and how you can accomplish that. And finally, if you're interested in pursuing multi-source eBonding or want to see you how we've done it, we do provide a copy of this framework on GitHub. So if you're interested in reviewing, testing, deploying, or even contributing, I'd love to hear from you in the future. Thank you. [MUSIC PLAYING]
Write your own Outlook add-in that exposes ServiceNow UI natively inside emails
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello, everyone. Welcome to my session, Outlook Add-Ins for ServiceNow, where I'll show you how to expose service portal natively inside of Microsoft Outlook. A little bit about me-- I've been at ServiceNow for 10 years, which means that that's one fourth of my 40-year coding experience and, frankly, one fourth of my entire career. My name is Grant Hulbert, and I'm the Director of Innovation for Corporate Strategy. Today, we're going to talk about what the problem is-- too much copy and paste and swivel chair. We'll talk about the solution, which is Outlook add-ins for ServiceNow. And we'll actually walk through installing the solution, and then we'll talk a little bit about customizing and debugging, and how you can make changes to this yourself. So first off the problem-- imagine that you've received an email-- and I'm sure this happens all the time-- where you are asked to do something that probably needs to be reported as an incident or a customer service case. So in this case, somebody sent me an email with a request. Well, what do you do every time you do that? You, first of all, have to slide your email a little off to the side. You have to then open a browser, log in to your incident management system, and then you have to go over to the email side and copy the username. Go to the other side, paste the username. Copy the issue from the subject line. Paste the issue into the subject line. Copy the comments. Paste the comments. And then, finally submit. And then, finally get back to your work. And this seems like an awful lot of swivel chair, an awful lot of work, for something that really should be automated. So let's talk about the solution. And the hint's right there on the screen. What would happen if we just never left Outlook? Well, this is the solution. You have the ability to write Outlook add-ins, where your icons and menus appear right there on the screen directly inside of Outlook. And when this task pane that Microsoft provides slides down the side, you as a coder have the ability to put your service portal into that spot, right inside of Outlook, and you can have all of the data from the email pre-filled into that form in ServiceNow. And then, after you submit this incident, you can click to view it. And sure enough, there in ServiceNow is all the information that came Outlook. I don't know about you, but this is potentially life-changing. It seems terribly mundane, but, frankly, being able to get rid of all of that copy and paste and be able to have ServiceNow itself showing up inside of Outlook, to me, just changes everything for myself, and for employees, and for my stakeholders. So let's talk about what you as a coder get. This is really cool. I just get so excited about this. Microsoft has created an API where all of the data in that email can be queried from client side. And in our case, what ServiceNow engineers have created is a way for you to see that inside of portal client side code. So you actually get access, through APIs, to everything inside of that email-- the subject, the body. There's tons of stuff that we'll talk about towards the end here. And then, of course, any arbitrary service portal that you can design-- the one I'm showing here is out of box, but you can create any service portal and have that appear, again, directly inside of Outlook. So let's go through the steps of installing it, because I know when I'm looking at these kinds of demos, a lot of times they leave the installation steps out and sometimes it can be a little bit confusing. So I'll take you through every step of installing it. It's actually pretty easy. And good news is this has been around since the Paris release. So first step, you just go up to your list of plugins and click Plugins. And then what you'll search for is add-ins, or the com.sn_outlook_addin and install it. So after that Outlook add-in plugin is installed, you'll find that there is a list of manifests. And these office add-in manifests are the starting point for these apps that are projected inside of Outlook. So in our case, this came out of box ServiceNow for ITSM. So we'll click inside of this manifest, and you can see here, that there is, up under the hamburger menu, Copy Manifest URL. So when you click that, the idea is that you need this on your clipboard for the next installation step. So we'll copy this manifest URL, and then we'll switch back over to Outlook. Now, inside of Outlook, if you have the new Outlook user interface, you'll see the little three dots up top here. You click on those three dots, and then you can see that you can get add-ins. So we'll click Get Add-ins here, and a dialog box appears that allows you to add more Outlook add-ins. And in our case, we'll click the My Add-ins. And then, all the way down at the bottom, we can say Add from URL. And this presents a dialog box where you paste in what you copied earlier. So it's really cool, because ServiceNow actually builds this manifest URL for you. The app does that for you. And people in the email IT part of your company can actually provide this link as basically a base system. They can actually push this out to everyone in your company who's using Outlook and automatically have lists installed if you want. But in our case as the developer, we'll just paste it in manually. And now, after you've installed that, you'll immediately see this menu bar. And that is evidence that you're add-in was installed and is functioning. So I imagine the next thing you want to do is see what it takes to customize the code. In our case, we'll open a portal widget. Because what the Outlook add-in out-of-box product provides is a whole bunch of widgets-- one for creating incidents and one for creating BTB tasks. So we'll type portal in the nav. Click the widgets. And it's a little hard to, find because there's a lot of widgets, so search for star outlook. And then you'll see that there's a widget called outlook_create_incident. That is the widget that actually appears in the slide-in task pane over in Outlook. and we'll click inside to create the incident. Scroll down to the bottom of this, and open the widget editor. Now, for those of you who are familiar with ServiceNow portal, this is technology that's been around forever. If you're not familiar, this is basically kind of a very standard Angular.js layout for creating widgets. But I want to draw your attention to the centerpiece here, the client script. So this is running client side. When you run Outlook, you actually are effectively running a web browser. Outlook is, of course, a native app, but inside of Outlook, that little slide-in pane is a web browser. And that browser is projecting JavaScript, HTML, all of that stuff. So when our slide-in task pane comes on with this particular portal widget, we can look at the source code that's running in the client side of the browser. So I searched here for office. And you can see here that we are accessing the end user's client browser, looking for Window.office.co ntext.mailbox.item. And what this is is we've basically exposed Outlook's APIs directly inside of here. And so, this is all Outlook's syntax for subject, and body, and all the information that you can get out of that. Now, notice here that we have a data view of Outlook. What this is is this makes it easier for the plugin to only show the fields that are in a particular specific view in your incident form. Remember, this is out of the box. You'll be able to customize it however you like. But on the incident form, this plugin adds a new view called Outlook, and that enables you to really easily customize that particular form. And then, also notice that I've pre-added-- you wouldn't see this if you followed along. I pasted it in one more line of code here, because I wanted to do something kind of useful-- have a correlation ID for the incoming email that I could then store inside of the incident that's created. That way you can have a data connection between the email and the created incident. So now, let's go see what this looks like inside of incident. We'll open up just a random incident here, and we'll switch to the Outlook view that I mentioned before. And then we'll switch to the form layout. Because what we're going to do is add one more field onto this form to make it visible on the slide-in pane in Outlook. So let's click that form layout. And we'll select the Correlation ID, bring it over to the other side, and click Save. Notice that the result of this is that we now have a new Correlation ID field showing up. This is all out of boxes. This Correlation ID is part of the incident table already, but we're just making it visible so that we can show it in our demo. The idea here is that you, when you want to put in your own cool add-ons to this, would pick any other fields that you want. I'm just showing you one example-- one that's actually somewhat useful. So now, when we reload the task pane inside of Outlook, you can see that this Correlation ID appears here. And that's the actual string that comes from the Outlook email and from their APIs. So let's talk about debugging. It turns out that because this whole region here, this pane on the right-hand side, is an actual webkit browser view, you can right-click and treat it just like a browser. So in this case I right-click and choose Inspect Element, and a typical webkit browser inspector appears. So here you can set breakpoints, you can see how your JavaScript is running-- basically all the stuff that you would do is if you are in a browser. But notice that this is actually in Outlook. So you're not going to ever see this in your browser, in the sense that Outlook provides its own browser and its own environment. And here is the Microsoft documentation. I just brought you to one page. There's plenty of docs online if you Google for office add-ins. But the idea here is, down at the bottom, you can see this is Microsoft Docs on this mailbox item-- the blind carbon copy, the body. And if we were to scroll through here, you would see tons and tons of information, including things about calendar items-- basically just everything you'd want to get out of a user's email. So what's next? Well, what I would suggest to you is that you clone the base system manifest, that manifest that we opened earlier to grab the URL from, and start your own add-on. That gives you the chance to create your own plugins, create your own menu items, create basically all the functionality that you want so that you're not interfering with the base system one. Then I'd suggest that you Google for Microsoft's Outlook Add-ins APIs and see what they can provide. This slide deck does provide links to that. So if you get the slide deck, then just go to the bottom and you'll and you'll find those links. And that's something I haven't had a chance to do yet. Notice that I've been talking about service portal. Service portal is really pretty old technology. It works great. I love the look of it. But nowadays everything's about UI Builder. So if any of you find out that UI Builder displays just as easily inside of these little slide-in panes-- I see no reason why they shouldn't-- please let me know and let the world know what you find. And finally, just have fun with this. Enjoy making your users' lives easier. I certainly find that I became the hero. As soon as I enabled this functionality for my users, they were beside themselves with joy. And being able to reduce all of their swivel chair and all of their copy and paste, I practically got a parade out of it. So hopefully you will, too. Thank you everyone for joining this session. I hope you enjoy building your own Outlook plugins and add-ons. And the slide deck contains resources. These are hyperlinks to the various parts of the technology that I've showed you today. Enjoy. [MUSIC PLAYING]
Regain 30 minutes of lost productivity a day with SN Utils
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Welcome to the session, how you can regain 30 minutes of productivity a day with SN Utils. My name is Arnoud Kooi. I am a Workflow Design Architect at ServiceNow. I'm five years at ServiceNow, seven years in the ecosystem, and I love the platform. Today's session is about the browser extension, SN Utils. It comes along with a VS code extension as well. But today's topic is the SN Utils site. It is available for every major browser, ranging from Chrome, to Firefox, as well as Safari. The code is available on GitHub, and all the direct links are also available on my site, arnoudkooi.com. And it's as easy as clicking Install from when you are on your favorite browser extension Web Store. So I have started working on SN Utils six years ago. And in that time, it has grown to almost 45,000 users. I have a lot of positive store ratings that I am really proud of. And here, you see a few testimonials. Set the video to Pause and read them all. The one on the right side, it changes my life. So that is also really, really cool to have testimonials like that. Recently, I have run a survey. And in the upper left circle chart, you see that more than 50% state that they gain 30 or more minutes productivity a day. So that's really awesome-- and even a substantial part, more than one hour a day. It's used by customers, by partners, so it's used all across the people who work with ServiceNow. A lot of positive experience-- if the experience is subpar, then it's most here often heard suggestion is more enablement, more training, more help on how to get the most out of it. So hopefully, this session will enable that as well. Today's focus is on slash commands. That is a feature to navigate around the instance, search for things, and invoke particular functions. So that will make more sense once I demonstrated it. So let's now jump right into the ServiceNow instance. And here, we see four tasks that we have at hand today. And let's just open the first one and start off with it. What group is Fred Luddy a member of? And to investigate that, instead of going to the normal navigation, I can invoke a user search by starting a slash command. And what I have just done is hit my keyboard forward slash. And now, this popup is available. I have a really shortcut for that called u, and that does a filter search. So when I do fred, when I would hit Enter, it would open in my current window. I would really like to open a new tab, so I do a Control-- or on Mac, a Command tap-- and now, that opens in a different tab. I get all the threads that I have in this instance. When opening it, it's opened the Fred Luddy record, as I would expect. And scrolling down here, I see the groups. And instead of needing to export this, what I can do here is use the select multiple records with Command-- that is a normal ServiceNow feature. But now, again, I can use a slash command copycells. I type in copy, and then I hit Space or Tab to fill that command. I hit Enter. And now, the cells that I had selected are being copied. So let's go back to my task. When I hit the Command-V here, I have all the groups that thread is part of. I hit Post, and I think we are done with this task. So I'm going to change this task to Done. What is up next? Why is dark mode not available? So there is a question, but it appears that dark mode is something that we just enabled. It is a new feature of their-- dark mode is a new feature available from San Diego in the next UI. So I recall that I have done that earlier today. So what I'm doing-- I can better open this in another tab. What I see here that I don't have the full UI but only the Record view. So I first want to enable the full UI. And it appears that there is a system property, polaris. And I expect it to find it over there. So dark theme enabled-- that is the property. And I recall that we have already changed it. So indeed, it has been changed. And it has been changed just recently. So some problems fixed themselves. But just to be sure, let's try to impersonate Jenny. And I have a slash command for impersonations. When I do imp jenny, it will search all the Jennys. And by hitting keyboard 1, I'm going to impersonate Jenny. And I'm going to go to her preferences. And yeah, it seems that theme dark is already available for Jenny. So this problem was already fixed. Let's do an impersonation as well to stop impersonating. Go back to our task boards. And here, I say, already fixed. What we did some confirmation, and all should be good now. And this should be good as well. So the next lots of error messages following containing a string. I recognize this as a sysid. So what I want to do is I want to copy that sysid. And when I paste in that sysid, it's recognized that this is a sysid, and I can do a direct instant search for that sysid. So when I hit Enter, immediately, the record, it is a script include as it appears is found. And it is called a script include NastyUtils with a function strangerCode, and it only throws an error. So this really doesn't seem something that should be here. But I would like to also investigate where this code is being used. So I have NastyUtils. Again, triggering the slash command. We have a slash, do a code, and then search only for nasty. Now, it does a code search within my entire instance. And based on nasty, I get a few hits, some irrelevant ones. The script includes itself. And I do see a business rule that constrains the code. So let's open that business rule. And this does not seem to be OK. So I would like to disable this business rule because a business rule that only throws error doesn't seem OK. So I can do sa and then hit Enter. And what it does now, because this record is in the global scope, I could hit this one, but I want to permanently switch to the global scope. So I do a /sa, and that gives me the last 10 scopes. I could also add in a search term, but until that is the global one-- so by hitting 2, I'm switching back to the global scope. Now, I can disable it. And instead of using a UI action to save, I can use hit Command-S to save. That's also a shortcut added, so you can use a shortcut to save your current record. So the immediate need is done. But we also have a prod instance. And I have a slash command-- /prod-- that is a configure command to open in the prod instance. So now, it will open the same record with the same sysid in a different tab. And ServiceNow has a Compare function. So that is triggered by diff1. So this is the left side of what I want to compare. Hit diff, and it will open this. But we also need to define the right side. So now, I'm in the business rule on the prod instance, and I'm hitting diff2, hitting Enter. And now, we see diff loaded. And now, we see the differences between the two instances. And here, we see that the faulty code doesn't seem to be on the proper instance. So that seems good. A few other differences between the two instances, but I think it's really important to see that the code that causes the errors is not on the prod instance. So I'm going to leave this one for now, go back to my task boards, and say it needs an investigation. I'm going to go back to this one later. And for now, I'm setting this in a state of doing. So the last immediate task is manager field on incident form. Why is it there? Let's see if the instance contains a bit more info. Yeah, I got a link to the underlying record. And here, it opens in the new workspace. And when I do a double click here, it shows me technical names. That can also be done by a slash command-- /tn also triggers the same. But really, the quickest way is a double click in the form white space. And it shows me a lot of extra info on my record. So here, I see that manager record is the caller ID and then the manager of the manager. So that, indeed, does not seem to make sense. So I would like to remove this from my form. And another data that the double click or the technical names adds is when you are in a workspace, it adds a link to the classic UI as well as the particular view. So by clicking that, I'm on the classic UI, and I see exactly the same here. But from here, it is pretty easy to configure and go to Form Design. So it opens the Form Design, and I should be able to remove it. But currently, I'm not in the correct scope, so I don't have the option to edit it. But the slash command detects that this is not the correct scope, so it automatically adds a suggestion to switch to the correct scope. So by clicking this link, it now has changed the scope to the scope where this record view is in. And now, I can just click here, click on the Remove, hit Save. And I'm pretty confident that this does the job. Another handy shortcut of SN Utils is a double click to reload a form. So when I double click the header, it reloads the form. And now, it is gone. So that's good. So basically, we fixed another two things over here. So when I say over here, removed, Post. And set that to a state of Completed as well. So as you've seen, in a short matter of time, we were able to complete three tasks, determine the course of the fourth task. So with that enhanced way of navigating, searching, and utilities, we can really boost our productivity. I hope this inspires you, and I love to keep in touch with you all. The best way to find out what new in then SN Utils is to keep in touch with me on Twitter. Follow me on Twitter. Every major update or significant update, I tweet about it. If you want a direct conversation, SNDevs is a good place. Make sure you are in the SN Utils channel. I always love to connect with fellow ServiceNow enthusiasts on LinkedIn. And on my website, I also have all the links to all the versions that I maintain. A last thing that I can offer-- I have a cheat sheet available in SN Utils itself, but you need to do a bit of deep dive investigate to find out behind which slash command it is hidden. So good luck with it all. Again, I love to stay in touch, and I hope this is beneficial for you, and I thank you for your attention. [MUSIC PLAYING]
Five things I wish I knew before attempting to localize my scoped application
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello, everyone, and welcome to five things I wish I knew before attempting to localize my scope application. My name is Maria Gabriela Ochoa Perez Waechter. My pronouns are she, her, and I'm a 2022 and 2021 ServiceNow developer MVP. Hi, everyone. I'm Jesalyn. I'm a ServiceNow developer, and I'm looking forward to sharing what we've learned about localization. So before we go further into the presentation, we thought it would be helpful to go back to the basics real quick. We're going to be using some terms throughout the session, and we want to make sure everyone is familiar with them. So what is the difference between localization and translation? Localization is making an application adaptable to specific regions without impacting functionality. This means your application can show the target language, currency, date formats for that region. Translation refers to changing source text into another language. You may be thinking can't ServiceNow do this for us. The language pack plug-ins that ServiceNow provides only cover out-of-box strings. This means that anything custom that you add or you modify to the system needs to be localized by yourself, and in a scoped application, that's everything. There's a couple of different ways you can localize your app. You can do it by hand or by machine, such as Google Translate. We're going to be focusing on the manual approach because that's what we decided to do. Here's some tools to help us localize our application. We recommend using them since they made the entire process a lot easier. The out-of-the-box tools that are available are the Translation Prefix System Property. It places a prefix-like message before each string to tell you which table a string is on, and that helps with debugging and identifying translation gaps. And then there's the Translate and Learn System Property that will automatically create records in the applicable translation table for any strings that are missing translations. So what you basically end up doing is you click through your entire application, and it's going to pull things like table names, options for the fields and automatically create translation records for you in the corresponding tables. Another great tool that is available online is the FetchCode project on the ServiceNow share. We used it to help us identify hard-coded strings in our script includes, in our business rules widgets, and any other place that has a script field. We use this to search for word code that is, in our instance, in a large scoped application with lots of legacy code. It's likely that you don't know where code exists or what it's doing, and it made it really easy to search for everything. Next, we use the website called Crowdin in order to obtain our translations of our strains. We basically compiled everything into a spreadsheet, and we uploaded that into the Crowdin website, where we were able to get quotes from multiple different vendors and select who we wanted to work with from there. And finally, we're going to have all of these resources and many more links in our GitHub repo that's available at the end of this presentation. Now that we've covered the basics and some helpful tools, it's time to learn about the five things that I wish I knew before attempting to localize my scope application. We've broken up the process into five steps, and the first step happens before you do anything. You need to plan your localization strategy. This means figuring out details like what language you're going to support, how you're going to source your translations, and many others. In our case, we decided to focus on Spanish, French, and German since that's what our customers currently requested. There's a few options for sourcing translations, like Jesalyn said. You can use machine learning, such as Google Translate, or you can use experts and native speakers in order to translate by hand. Our team had native Spanish and French speakers available to us, so we only had to figure out plans for German translations, which is where we went with a Crowdin tool. Now that you're ready to start because you have everything strategized. You can go ahead and turn on the language plug-in. During this stage of the process, you really want to focus on finding those missing translations. This is where you want to use the Translate and Learn System Property that we mentioned earlier. This property will create initial translation records for you because ServiceNow will only show translated text if there's a translation record for that string on any of the five tables. This property will create the records for you, so what we recommend doing is turning the property on and then clicking through everything in your application. Going module by module, visiting every form, every list, every widget, every portal page, and so on. And through this method, we were able to generate over 100 records of translations that we need to source. Another thing to focus on is the Display Translation Prefix System Property. What this one will do is it will show you if you have hard coded strings in your instance. Because if there's no prefix, which is what shows you what table a string is from. If there's no prefix, then that means that the string is hard coded, and that is not ideal. And what you need to do for that is convert that into a translatable way. So then ServiceNow knows to translate it, and it won't stay hard coded. And for that, what we recommend doing in the next phase, stage three, is Establishing Design and Development standards. So in order to make sure that everything is scalable and translatable, you want to have standards. So this means not hard coding any strings, and you want to be using the appropriate gs.getMessage depending on if it's the server or the client or even in a portal widget. So the best way to do that is to have gs.getMessage is to structure it by using a system-like message. So the general example you've seen with gs.getMessage is gs.getMessage hello world. So, hello world is what's displayed to the screen or the user. Rather than using hello world, we recommend structuring your gs.getMessage in a system-like way. So the key for the input to gs.getMessage would be a system-like description such as widget header text. Widget header text would then be your key, and your value for the record on the messages table could be hello world. So then, you're still showing the same output of hello world, but you're just structuring it in a way that makes it easier to maintain and to code. Because now, if you have it structured like that, where you're showing widget header text, then when you are doing your search for missing translations with the display translation prefix system property. When you're searching around your instance, and you see the output of widget header text, then you know that you don't have the appropriate translation record. Because it's showing that system description rather than showing the hello world that you would expect to see. So to sum it all up, static strings are bad, and you want to make sure you're always wrapping everything in your gs.getMessage. With everything localized, it's time to test all the hard work that you've done so far. We don't have a well-defined testing plan yet, partly since we haven't reached the stage ourselves. However, what we have done is taken a look at everything in our application to see how it looks when things are translated. Different languages are going to have different sizing requirements compared to English. So what looks good in the English version of the UI might appear cramped or overflowing in the translated UI. So, for example, the word new is three letters long in English, but it's nine letters long in French. This is something to be mindful of and keep in your mind as you go through this process, especially when users are zoomed into their browsers, or they have a larger default font size. Another thing that we plan to do here is have our customers try to navigate our application in English and then in the target language like French, using our service portal as an example. Our goal is to verify that our customers can navigate and use the portal functionality in the same way in English and French. If our customers are unable to use the French version of the portal, for whatever reason, that gets us feedback on what needs to be reworked. And now, great job. It's the future now. The localization implementation has been deployed, and now you need to maintain it. So like testing, we don't have a well-defined maintenance plan just yet. But we are planning on scoping that out and figuring out exactly what's required. One of the things to keep in mind is that as new content and features get added to the app, localization needs to be considered. Code reviews should be checking that strings aren't hard coded and that you have correspondent translation strings in your system for any new updates that are getting added, for example. A good thing about making sure that you're not hard coding strings and wrapping everything in the appropriate gs.getMessage, in your scripts is that this makes maintenance of your strings a lot easier. Whenever you want to change the wording of a message, you no longer need to edit your script includes or business rules. You can instead update the value of the translation record for that key which is a beta change. And finally, we'd like to thank you for listening to our presentation on localization. I hope that this has helped you all get started. If you want to get more resources, you should check out our GitHub repo linked down below, which is going to have a lot more information and links. You should also check out our blog post on WomenNow.dev. We're going to go way more in-depth on what we covered today, and we're going to have code samples that you can reference. You should also come hang out with us at sndevs.com, which is our community Slack server, where we all like to hang out and talk about ServiceNow and ServiceNow related topics. Thank you very much, and have a good day. [MUSIC PLAYING]
Build developer friendly APIs with JSON Schema Validation
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hi. I'm Jarod Mundt, vice president of engineering at Clear Skye. I've been working on the ServiceNow platform since 2014, and I've spent time at customers, implementation partners, and am now working at a product partner where we publish identity security and governance solutions into the ServiceNow store. Today, we'll talk about JSON schema validation and how you can take your APIs to the next level. Now, this is not going to be a deep dive into schema validation and also not going to be a deep dive for importing external JavaScript libraries into your instance, but we will look at the JSON schema validation concepts and why it will be worth the investment to implement this into your instance. We'll also take a look at some scripted REST API examples, but this validation can be used in any other server-side or client-side code in your instance. Both the schema and input object are both written in JSON. JSON stands for JavaScript Object Notation, and it's the data format that powers most of the internet's APIs, including ServiceNow. There are things like curly brackets for objects, square brackets for arrays, and things can be nested inside of other things. Now, the schema on the left we see has a very specific format so that the validator code knows where to find each object. There are many validators available online in a variety of programming languages. For these examples today, I'm using Tiny Validator a.k.a. Tv4 out on npmjs. I'll show a link to where to find this library at the end of the presentation. Now, in our first example, we have a very basic flat object. So hypothetically, in this example, we have a client that is sending the input object into our system, and the result of that will be some expensive database long-running queries and a variety of inserts and updates across multiple tables. So ideally, this will be an all-or-none transaction. We don't want to get half of the transactions completed and then find out that some of the data is missing or in the wrong format. So what we do is we pass both the schema object and the input object into the validator, and then we'll get a third JSON object that we'll call the validation result. Now, in this case, valid is equal to true. Great, we won't have to stop processing or send any errors back to the client. We can begin our processing. But what if our input object-- what if we had an age of negative 21? Technically, according to this schema, that's still an integer, but that may cause errors when we start processing. So in example two, we've added a few more attributes to the schema definition. Now, if we try and process it now, in theory, negative 21 is out of the scope so we'll receive an error. Notice the message and data path attributes of our validation object. We see that it says specifically that the parameter of age is less than a minimum of zero. And we did this with very limited code. This is part of the JSON schema validation standard. Also notice that we're on only example two and both the schema and the validation result are starting to get rather long for a relatively simple example. The definition on the left is 22 lines long and the validation result is 17 lines long already. So pretty quickly, when we start nesting objects and arrays, both our input object is going to get big but also our schema validation or our JSON schema definition also start to get pretty big. So for the next example, I'll only highlight the things that have been added or changed so we won't have to shrink down all of that code to get it to display all on the screen at the same time. So here we've added a few more items, specifically favorite movies. So in the schema, we've added a type of array, and the items inside of that array must be strings. On the input object on the right, we see that we've added some favorite movies, but one of them is in a integer format and not a string. So let's take a look at that. We now get valid equals false. And specifically, back to the message and data path portions, we see invalid type, number-- it wanted a string-- and data path, under favorite movies, position one. So arrays start at zero, so that would be the second item that was submitted is the problem item. Now, there are quite a few other additional JSON schema attributes to add value and to fill out the schema definition. Specifically-- I won't go into a variety of them, but one to look out for is called additional properties. So if we set that to false, any extra items that are submitted in the input object, if they don't have a specific definition, we can error out on those. Now let's move this stuff out of theory, get it into our instance, and build some scripted REST API checks and responses. So prior to this step, we must import a library into our instance. So like any good TV baking show, I'm going to skip over that step of selecting the open-source library and also the import to script include process and I'll go right to the code execution. Now, as a side note, if you don't recognize this interface, it's called the Xplore toolkit and I do highly recommend it for scripting and working with data on the platform. It's available from the ServiceNow Share out on the Developer Portal. Now, once our script is proven to work, we can just start coding away and start creating scripted REST APIs, right? Well, not so fast. I want to have a quick chat about architecture standards first. So when I've demoed this and implemented this in the past, one of the common questions is, why not just use the table API? That way, if somebody wants to integrate with ServiceNow, we just point them at the docs, give them a service account, and then they do all the work. We don't have to do anything as the ServiceNow team. My response to that is, as a whole, what needs to happen is the organization has a requirement, the organization needs to get some work done, and the organization needs to support it. So we get to kind of think about which teams should best pick and choose to support that. So I typically recommend centralizing as much of the development and centralizing as much of the pain as possible, and that allows us to reduce friction. What we don't want to have is making a junior Linux admin on another team that's writing an integration inside of a Python script have to learn the table API, do four lookups to get various sysIDs of locations, users, change request numbers, CMDB CIs, other things like that. We want them to just go right to building their query. What this also does is it increases happiness, can reduce the time to value, and also reduce costs and time on the other teams. Another advantage to building things in scripted REST APIs is that you can conform to the culture of your organization. I've worked at places where they had shorthand codes for locations. Everyone referred to people in every system by the employee ID. And so, by building it into a scripted REST API and not the table API, we get to choose which value we use for each of these things. And third, we get to continue turning ServiceNow into the control tower. We get to put ServiceNow at the center. Now, whether that data lives in ServiceNow or only an up-to-date copy of that data lives there, it allows all the developers across your organization to have access to all that data with a single service account. A fourth thing is also that it makes people love and trust the platform more when it's easier and lower friction to get access to the proper data. So don't underestimate that part either. I've seen, at some organizations, where the data center operations people get tired of the table API and they just want to-- they go the other way with their APIs. They replicate CIs, incidents, and changes out of ServiceNow into their custom database, do all the work in that custom database, and only feed back the very minimum updates and states into ServiceNow. So that way, the ServiceNow record only has the bare minimum of updates and activities. Also technical-- flow triggers are great, but everything's asynchronous and you have very limited control over your inputs and your outputs, especially for a flow trigger that uses an HTTP GET. So here, we get better control, better logging, better error handling. For example, if we wanted to open up an incident or an event or alert when APIs are sending in bad data, in a scripted REST API, we'll have control over that. So overall, before implementing this, I do want to recommend getting buy-in from the top technical people responsible for your instance to make sure that what we're doing here conforms with the roadmap for all internal and external data flows. So anyway, back to the tech demo where we'll be doing some validation directly in a scripted REST API. So here we have a HTTP POST example. So above, what we're doing is just grabbing the body that's sent into the POST body. We're loading up the schema definition that's stored somewhere in the instance-- it could even be directly in the POST record here-- doing the comparison, and then checking to make sure if it's valid. So again, here, we'll take that next step that we didn't do in those earlier examples and build out our error message. So I'll zoom in on that part. And notice, again, we're using the data path and message fields. One of the favorite features that I have inside of a scripted REST API is the ability to control specific error messages. So there's a one-line command that gives you the option to just send a error, but here we see the four-line option to set specific HTTP status message and the details of which is the concatenated string of that error array above. So if there is no error, we can begin processing away. If there is an error, we stop the transaction and reply very specific things back to the developer. So let's take a look and see what the remote developer sees during this error process. So when I'm coding integrations, I always make sure everything looks good using Postman and, like we saw, the Xplore toolkit to make sure all the data and authentication works. Now, in this example, I've set three errors intentionally in what I'm submitting. And what comes back from our scripted REST API is exactly this, the HTTP 400 error. What we see is, under the message, we see that static string that we programmed in. And then, under detail, we see the specifics. Where was the problem? Under first name. What happened? The string is too short. It was only one character long. It needs to be at least two. And then it loops through all the other errors as well. So this was a basic scripted REST API example, but like I started with, this could be used outside of these APIs and could be used anywhere on the platform where you want to validate parameters. For example, critical script include function, we can validate that everything's within range before we do any expensive processing or any record inserting or updating. Thank you for watching. If you want to continue the conversation, please reach out to us out on the ServiceNow Community Forums, out on the SNDevs Slack community at sndevs.com, or find me on Twitter. I'll see you around the community. [MUSIC PLAYING]
Dev-ternships: The best way to grow your ServiceNow Team
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Thank you for joining me for this talk about creating Dev-ternships as a way to grow your ServiceNow team. Finding the right talent for your team is always a challenge, no matter the industry. Now, I am Sharon Barnes. And nowadays, I am a developer MVP with two years of ServiceNow experience, as well as over 12 years of training and management experience. Now, my previous career, I was a training manager and branch manager for Eastern North Carolina ALM insurance company. And I transferred from that non-technical career to ServiceNow, because I felt overworked and underpaid. I'd had a friend working on the Now platform, who had talked about how much he enjoyed it for years. But I always assumed that it was out of reach for me, that the career was just for people with specialized skills or technological genius. Well, that friend asked me to help review his k-19 workshop for wording and screenshots. And I ended up completing and understanding the workshops content. I had just built a virtual agent with no degree or intensive training. I realized that this was learnable. And within one year of study, I was employed with a partner, New Access Innovations. And New Access allowed me to leverage my skills as a trainer and as a ServiceNow developer to found a Dev-ternships. Now, we're going to go over several points today. First, why we built a Dev-ternships. Second, what we built for version 1 and the structure around that program. And third, the future improvements that New Access will use for its next iteration. Now, why we built it. Well, I've participated in hiring for technology, insurance, and retail industries. And I see some of the same trends across all of them. First, great talent is rare and expensive. I'm sure you know of multiple openings that have been unfilled for months. Second, cultural fit is essential. Now, most businesses continue to scour resumes or search LinkedIn for the person with the most experience and certifications. Hiring firms and researchers are beginning to realize that in many industries, the most qualified candidates can actually damage a firm when they don't jive with the company's culture. And third, what people claim as their skills does not always equal reality. With a good interview process, you can help prevent this, but a few can slip through. Now with a Dev-ternship, you can train entry level admins and developers with precisely the skills you need them to have, as well as make sure that they are a fit for your company culture and the team that they will be working with. Now, beyond these programs, New Access identified one more issue they wanted to solve, a lack of diversity in ServiceNow candidates. According to Nelson Frank's career and hiring guide, individuals of Black, African, and Caribbean descent represent only 3% of available developers. Studies have shown that diverse organizations have better outcomes than their less diverse peers. And the industry of information technology is limited in that regard. Therefore, it's in our own best interest as leaders of our organizations to encourage and empower minorities and women to enter into our industry and grow the diversity of the ServiceNow ecosystem, so that we can achieve those better outcomes. Now, what we built. We created a network to recruit from historically Black colleges and universities. Second, we created a repeatable system to train interns on specific skills. And the system is flexible enough to allow substitution of different curriculum, forum, different departmental internships. And third, we created survey metrics for continual improvement of the program. Now, the first step to a great internship is recruiting. Getting quality people into your program. And recruiting takes more time than you think, because the go-getters apply early. So three months out to get approval from your schools, get the job posting up, distribute flyers to the students via that university's regular communication system, and schedule info sessions. About two months out, hold those information sessions. These should be led by somebody passionate about the program. And at the same time, start collecting resumes. Around six weeks out, you're going to want to run the interviews with your selected candidates. And by four weeks out, inform the interns that they've been selected for the program. And that at the start of the semester, they're also going to be starting working with you. Now, the overall structure for our internship was broken down into three phases. The first was eight weeks focused on learning the fundamentals of ServiceNow development. Then, we had one week of exam prep to help them earn their CSA. And the last three weeks were for building their capstone project, an application based on their interests. Now, we covered 10 topics. And our goal was really for them to gain more than their CSA. We wanted to ensure they had the experience to become effective admins. So we included a variety of topics, including ITIL practices, gathering requirements, participating in sprint planning, and just overall, understanding the development skills needed for the bigger picture of how ServiceNow allows people to work better. Now, our course was set up with a weekly tempo. We created a scoped application on the Now app platform, incorporating knowledge articles of the weekly curriculum. And the interns had a primary instructor throughout the entire program for a main point of contact, as well as having weekly lectures for members of our team to act as subject matter experts for each of the topics. We added gamification to the midweek review session to increase engagement. And just overall, we wanted to ensure that there were interactive elements, so that it was more than just instruction to go study remotely, but a constant feedback and engagement throughout every week. Now, we got our content from a variety of sources. And this is the most common question I get asked. We combined hands-on exercises from the developer site, as well as Now Learning with readings, videos, and lectures, as well as making sure that the students had that one on one mentorship to guide their learning. Overall, it worked. But you can constantly improve from experience. And I want to call out several points where we found for improvement, so that you can avoid them when you build your own programs. First, target schools with a solid science and technology programs. We noticed that the number and quality of applicants from these schools with that focus was better. Second, we wanted to make sure there was more practical experience. Make it feel a little bit less like a class with fewer theoretical exercises and more time on the real work needed by businesses. Third was business value added. Having the capstone driven by actual business needs. By having it driven by their interest, well, we ended up with a 100% sports related projects, which are fun but not exactly applicable to our customers. Now, looking at how this changed the format of our internship from the three phases into four phases, with the first three weeks focused on CSA prep. Consolidating that foundational information down to a shorter period of time. Six weeks of shadowing their mentor, being able to complete some of that same work and stories that their mentor is doing. The next two weeks are all about that capstone program tailored to that business scenario. And then, the last week is for the certification. And we placed this at the end, because we had noticed that some of the interns were demotivated by the difficulty of earning that certificate in the middle of the program. Now, these changes mean that for our first three weeks, we had to really consolidate the information down. So rather than it being a weekly schedule, we've switched to three times a week going through that lecture cycle of labs and quizzes. Now, overall, I want to thank each of you for your time today. Because with Dev-ternships, you were training entry level admins and developers in precisely the skills you need them to have, as well as making sure that they are fit for your company culture and the team that they'll be working with. And while they're gaining these skills through the paid internship with the company, your company is benefiting from the opportunity to grow their ServiceNow practice. Thank you for your time. And I hope that this information will help you in creating your own Dev-ternships programs. If you're interested in a little more information later, feel free to contact me, Sharon Barnes at SN Devs. And I look forward to hearing about the success of your programs. [MUSIC PLAYING]
Use “No” to pull the weight of future stress
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello and welcome to Using No to Pull the Weight of Future Stress. Today, we're going to talk about having a conversation with our process owners, our stakeholders, and improving that conversation so that we feel more comfortable expressing our boundaries about using best practices, not going against them, not making upgrades harder for ourselves, and those kinds of things so that we can deliver a better product for the customer that also means less work down the road for us. My name is Dave Atwood. I am a solution architect for Cummins, Inc. We make really big, giant diesel engines if you're not familiar with us, also some really small ones. I've been in the ServiceNow space about 5 and 1/2 years. And I have been onboarding processes quite literally since day one, since I transitioned from process owner to ServiceNow developer and then continued developing that process. So I've been working on this for a while. And this is a conversation that I've been thinking about quite some time. And I've asked people in the community have you spent training on this? Do you spend any time thinking about it? And a lot of folks answer no. And the ones that don't answer it as no don't tend to have formal training or any of that. It doesn't seem to be too popular a thing out there. But I'm sure there are ways to do it. And so I spend a lot of my time thinking about how to do this better because I see my coworkers, I see partners we work with all compromising in ways that are going to make my teammates lives and myself, our lives a bit harder on the platform, maintenance, upgrades, all of that. So we can do this better and make it better for everybody. What are we going to talk about? We're going to talk about why this is important. We're going to talk about why we don't want to say no, some things we certainly shouldn't do. And the real need is shaping the conversation and learning to redirect. So why is this important? It's important because we want to deliver the best thing both for us and the customer. And being somewhat of a selfish person, I think I'm more important than they are. But I realize the outcome for them is more important in the grand scheme. So I want less maintenance. I want to make upgrades easier. I want to do them more often. But I can't do that if a customer comes in and says, I want to do this only this way or I compromise and let them do something that's not up to best practices. So I think we can make everybody happier. And it requires us to do something we don't like to do, which is express boundaries and say no. I love this quote from Henry Ford and I think it highlights the entire problem. If he had asked the customers what they wanted, they would have told me they wanted a faster horse. People don't always know what they want because they don't always know what's possible. And so if we can change the conversation, maybe we can give them something better than they expected was even possible. So, again, why are we saying no? We're saying no because as a developer, I want less maintenance. I want to protect my instance. There are best practices to consider. ServiceNow is always changing the way they do things. And staying up to best practices means I have an easier transition to whatever new thing they come out with. Sure, it didn't work with Workflow and Flow Designer, but whatever. There are lots of other cases when it does. There's value here. If you do with what they want the way they want it, you lose that opportunity to do better because the way they want it puts them in a box. And that box is hard to get out of it. So by changing the conversation and getting them out of that box, you really expand their options. The customer cares because they don't want to wait as long for the work. They want it done yesterday. So keeping out of the box, keeping to better standards means we can deliver it faster. They can have more control or feel like they have just as much control or even more because part of that is giving them choices. They have choices. You build it the way they tell you, there's no choice there. They just did a thing and you-- they demanded a thing, and you did it. There's no choice there. Choices help them regain that feeling of control. And that makes them happy in the end. They feel like they had a say in what was done, which is really important when you're moving them out of that space. Better performance-- again, standards, doing it out of the box, all of that leads to better performance. Not to say that custom code is always super performance intensive. But there's a lot of bad stuff you could do in there that is. Again, more options for future expansion of work. Getting them out of that box makes it better to add on things, easier to add on. And going back to the first line item there, shorter time to ROI because I spent less time developing something. And to the company as a whole, that really matters. It may not matter to them that much. So we need to say this more often. We need to be more expressive about it. But when we do it, we can't actually use the word no. No is a giant brick wall dropped right in front of them that they're going to run into a full speed. And that's not comfortable. So we need to make sure that we're comfortable saying it and they're comfortable receiving it. So to do that, we shape the conversation. And I like to sit down-- or rather, email-- any time anybody says, hey, Dave. We want to move something new. And I say, great. Let's have a quick, half-hour conversation about some of the basics before we get into the real meat of it. Get to know you-- that kind of stuff. And in that conversation, I want their high-level goals, because their high level goals are what they really want to achieve. It's not about the doing it the way they've always done it. It's not about the way they think they want to do it on the platform, because they've seen somebody else's process, or whatever. Focusing on goals gets them out of that rut. It gets their mind thinking of it. We'll try to do a little bit of that more later on, but getting them out of that rut to start with is important. That initial pull that gets their vehicle out of that space-- that's super important. So then, we get into some of the priorities. And I make it clear to them up front, these are what I care about. And I feel like getting that out of the way early lets us reference that time and time again during the process, which makes it easier to say, because they'll understand why I'm saying it. So protecting the instance is my number-one priority. Because if the instance runs poorly, any of those things, then I have to spend a ton of time on it. I have to ton to spend a ton of time on maintenance. I don't want to spend a ton of time on maintenance. I certainly don't want to do super basic maintenance, like adding approvers or changing them every week. So next on there-- limiting the time my team spends on it. If I can build something that hands it off to them and lets them keep approvals changing every day or every week and they can do it and don't wait on me, we're both happier. They're happier, because they have control. They don't have to wait on me. I'm happy, because I'm not wasting my team's time with super basic stuff. Delivering the best product for the customer is obviously something that has to be on here. It is what we're here for. But it's third on my list, because if I don't do number one and number two, I don't have time to do more of number three. Most people understand these things. Most people aren't going to be a jerk and run roughshod over them. Some people still do. That's the way it is, sometimes. But at least this gives us a starting point to refer back to. When you say, well, maybe I could do it that way except for a few problems, they understand what those problems would be, and they understand why you're bringing it up. The last thing on the list is maybe the most dangerous. Encourage your customer to dream. This is a great way to get them out of the rut. You get them out of focusing on the way they've always done it, or the process they built up in their mind, or whatever, and they start focusing on the high-level things they might be able to do. You ask them to dream for that pie in the sky, and they start thinking. They start really exploring what could be done. And you have to be clear, you can't do all of it. I mean, ServiceNow is a great platform, but it does have some limitations for any number of different reasons. But most people, again, understand that. And most people will be surprised at how much you can do, because they're used to other tools that aren't as flexible. Or they had a custom app built that didn't have long-term development support. So something was built, and then it was done. There was no more changes. There was no more improvement. There was no more room for any of that. And so on ServiceNow, hopefully you're able to help them with continuous improvement, and you can work on a phased approach and really expand their thinking about what's possible. So we want to do these things to set the stage, because it sets us up to be able to express that there are limitations. But when we express that, we can't say, no, because that's a brick wall. So how do we do that without actually saying no? First off, we don't want to use the word but. If I say, that sounds really good, but that also goes against best practices. They don't hear any of the first part of that. They hear, but it goes against best practices. And so find other ways. Yes and is one of my personal favorites. Maybe, perhaps-- any word that goes on there. I used the but statement until fairly recently when somebody pointed it out to me. And I was like, yeah, that's exactly what I do. And so now, I try not to use it anymore. I also like to reference my three priorities. Unfortunately, that would take longer to develop than this other option. That references the ROI piece from earlier. May cause significantly more maintenance-- that's against my number two thing I care about. Would break an out of the box process-- that's against my most important priority, which is protecting the platform. So when you say these things, people reference back to what you said. You set the stage up for you to be successful as you redirect your customer. And that's the important part-- set yourself up to be successful as you express those boundaries and those limits, and hopefully, the customer understands you better. Choices are, again, really important. People like to have that control. You can point out the maintenance short for them. I mentioned approvals earlier. In our desktop process, we do worldwide approvals. I don't want my team doing that kind of basic work. They change too often for me to really want to be bothered by it. So we gave the desktop team lead the ability to do that. And now he goes in every day or every other day and adjusts approvals as people move around in roles in the company. Everybody's happy. He gets to do it on his own timetable. We don't have to deal with it on the regular basis. If you have to, you can redirect your product owner, but that's dangerous. Sometimes, if they don't come talk to you about it before they make a decision, they'll override you, in which case, you're really down a hole. So it's dangerous, but still, sometimes, an option. And the most important thing, again, going back to it-- focus on the goal. Don't focus on how you got there. Focus on that goal itself. Sometimes you do run into cases where there are a few milestones along the way to that goal. Those are probably also goals in themselves. So it should be a relatively easy goal-- goal to goal to goal process. Not always, but hopefully, most of the time. So this is kind of the beginnings of my thought process and my time I spent thinking about the onboarding conversation. It's a complicated one. It's a complex one. It's the very first time most of these teams really interact with us on a serious basis, so it also sets the stage for the entire relationship, which is why I think it's so important. Hopefully, using some of the things you've learned here today and maybe some further conversations we'll have, you can have a better conversation and have better outcomes for your team, for your instance, and for everybody that comes after you who has to take care of it. I really appreciate your time today. Thanks for listening to this and being here. If you want to reach out to me and talk about this more, I encourage it. You can reach out on sndevs. I am ReposadoDave. It's an amazing community of 10,000 people or more. Some of us are developers. Some of us are product owners or stakeholders or VAs or any number of different roles. We all interact with ServiceNow on a regular basis, usually beyond that of a user. And we're also all here to help out and talk, and you'll find so much good information here. And if you do make it to a Knowledge in-person, you can probably meet some of us, because we always hang out at Knowledge. Again, thanks for your time today, and I'll see you next time. [MUSIC PLAYING]
How to make your code available to citizen developers
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hi, my name is Philip Swann. I am a Managing Consultant at Rangoon. I've been working in ServiceNow since 2014 and in GRC since 2017. I'm also a two time ServiceNow Dev MVP and host of the "Phil Goes Deep" YouTube channel. In this session, I'm going to talk about how to make your code more available. We've all been in the situation where we've written some really nice code and it's really good. We're so proud of it because it works. It works really well even when we test it. And maybe it didn't work to start with, but it does now. And this code we've spent ages writing looks so good. If someone here was to look at this code right now, they would definitely be able to read it. It follows consistent naming conventions, includes meaningful comments with beautiful formatting. It's modular, performant, secure, elegant. But guess what? None of that matters. Gartner published this research back in 2019. And you have seen ServiceNow investing massively in this space. But this is not why citizen development is important. Citizen development is about partnering the people who need the solutions with the people who build the solutions and increasing the speed to value. Citizen development matters because if we do not respond to this demand, the business will be left behind. And business doesn't wait around. Servicenow.com has a page about citizen developers and it discusses these four stages to create an application. Back in 2020, I embarked on an adventure to convert the entire core application of GRC to Flow Designer in 24 hours. Why? To learn. To discover whether it was possible or consider if it even made sense. To be able to answer for myself what is Flow Designer good at? Where does it help? Where are the strengths and where are the weaknesses? As someone who loves to design and build solutions that solve business problems, I am someone who writes code and I want to make that code more available. No matter if I am building an application from scratch or if I have an existing application that I want more people to use more effectively. The problem is when you write code on ServiceNow, it is like gold. And your scripts include, now it is buried somewhere deep in the platform like some kind of hidden treasure that there is no map. There is no X marking the spot. Somewhere there is someone in the business who really needs it but they cannot find it. And even if they could find it, they would not be able to use it very easily, not without writing more code. Even yourself and your fellow developers could be forgiven for forgetting you wrote it. So your beautiful, delicious, elegant code is literally useless. It's useless not because it cannot possibly be used but because it is not practical and thus it is not being used. Or it is being used less than it should be or used less than it could be. So this person out in the business makes a request for a new function which someone else writes or they build. But they don't think about all the things you thought about and they don't build it the way you built it. And maybe it's not so beautiful or it's not quite as performant and it's not quite as secure. Now you have two functions doing the same thing in two different ways. I'm not saying that nobody can write code like you. I'm saying that they should not have to, especially if you already have. Especially if you have spent time solving that problem really, really well. This is the problem. We the developers, the ones who create the workflows and design the applications from the ground up, are not making our code available. Maybe we are not even making it available to our fellow developers and we are not making it available to ourselves, because we wrote a function and forgot about it. So writing code is one thing, but once we start to expose it, we are also documenting it. Flow Designer doesn't just give us the benefits of reducing our reliance on code by providing a lovely UI. It also helps to organize and communicate our application's functions and endpoints. And here is the main point I want to make. It's time to start thinking about our solutions in a new way. Script include is an API. Our public methods are the endpoints. If you build your application with Flow Designer it in mind, your code will become more available by default. But what if you have already built it? You and your customers can still benefit from these simple steps today. First we need to abstract the complexity. Focus on and expose the simplicity. In this example, I will be using the classic class pattern. Special thanks to Travis for his blog on codecreative.io for explaining the various interface design patterns for script includes. Note if you want to make your private functions truly private, you might want to look at the module revealing pattern. So first of all, put all your public methods at the top of your script include. These are the methods which you wish to be consumed from outside the script include. Consider these as our API endpoints. Have them return a call to the private function on a single line. The private methods are denoted with an underscore prefix, and these should only be called from within that script include. Even if the private method is extremely simple, just return the function call with those parameters passed in and this helps to communicate how the API is intended to be used. So we abstract the complexity, focus on and expose the simplicity. For each public message you want to be consumed, now in Flow Designer create an action. Ensure that you are considering the categories and creating them as required according to the design and plan of your application. Here I just use example ABC. Once we have created an action, we can specify the relevant inputs and outputs. Then just put a script step to cool our API and parse the inputs and return the outputs. Now we have created a wrapper for each of our script include endpoints, and we have also been able to enforce the validity of the inputs. And we have organized and published our code. Just take a look at how available our code is now. Once our actions are published, you can see how Flow Designer organizes the application for us. Let's create a subflow. We have the application scope. Here it is CCB1132 named according to this session. Thanks for watching. Next we have the category, example A, And the actions in that category with the info and annotation. When creating the subflow, we can assign that to one of the categories that we created earlier or we can create a new one if necessary. So what I've shown you today is nothing new. Flow Designer has been around for a while. And the concept of citizen development is not new either. What might be new is some of the thinking and the simplicity that allows us as developers to make our code more available, especially for the low and no code community, with just a few simple steps. So we can continue to do that heavy lifting and write the code we love to write while enabling the business to take full advantage and achieve maximum value from the results. In case you missed it, three simple steps. Firstly, organize our script include as an API. Put those public methods at the top so we know how we expect to interact with our API. Then we create actions for each of those methods in Flow Designer using categories to help organize them. And then that functionality is available to be consumed within our applications or by citizen developers. Thank you for watching. Please enjoy the rest of Knowledge '22. And if you want to get in touch, please check out the sndevs.slack.com or #PhilGoesDeep on LinkedIn and YouTube. Thank you. [MUSIC PLAYING]
Yes, you can design a great user experience
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello, everyone. I'm Sarah Toulson, and I'm here to tell you that you can, in fact, design a great user experience whether you are working from the Service Portal or the new Next experience. A little about me-- I currently work with the awesome people at Servos. I am absolutely living the dream, serving state and local governments through digital transformation on the ServiceNow platform. I've been on this platform for four years or so, and before that, I went on a very winding journey that includes over 10 years in graphic design and many years spent in the public service sector. That being said, today, I'd like to take you through the basic process that I use to put together a front-end design. We'll talk about gathering the information you need, taking that information, and planning the layout, and then we'll attack the scary subjects of colors, fonts, and putting together styles into a mockup that you can show your stakeholders. Unfortunately, due to our limited time I'm not going to be able to get into the weeds as much as I'd like to give you guidance on font pairing, inspiration, or some of the other details that go into this process. I do have a pretty robust list of resources on my website that can help, but please reach out to me if there's more specific guidance that you need. With that, let's get started. First things first, getting that intel-- here, we're looking to use a series of workshops or conversations to figure out exactly what we need the portal to do, what the priorities and challenges are, and what general direction we need the design to go in. The more information you have up front, the easier those design decisions are going to be for you to make. Here's a short list of what you're going to be looking to collect and establish-- the personas, the functional requirements, brand styles, and organizational culture. Though we're ultimately talking design, I'm going to start us off talking about function. Why? As much as bad typography triggers me, and as important as the design is to the overall success of the project, a pretty design that does not deliver the functionality needed or get the users what they need easily is a failure. So here are a few things that have helped me gather requirements specific to the front-end interface. The first thing I do, I pull up the out-of-box portal that you're going to be using for your project, and I review the major functionality of the site with the team or the stakeholders. You're then going to go through the portal piece by piece, page by page with them to discuss what functionality exists versus what they need. Bring your personas into play here. For example, when Mary comes to the portal, what's the most important thing she needs to be able to do? Your other option is to address each widget or feature individually and ask, for example, what links need to be present in the header navigation. Last, you'll want to use this workshop as an opportunity to suggest functionality that may not be present but that may be a possible solution to some of the challenges they've articulated. One of my favorite examples of this is to put the SC Popular Items widget on the landing page as an easy front-page way to display the most-used catalog items without additional searching. Once you know what the portal needs to do and the content you're going to put in it, it's time to have another workshop to talk design. In the meeting, you're looking to do three things. First, establish those final decision makers. Double-check to ensure that there's no one above the current team you're working with that will have potential veto power over your design. This can really hurt project deadlines if objections are raised late in the development cycle. Next, look to establish the design direction. This is most easily accomplished in a series of questions. Start by asking, do you have an existing site design or brand guide you want me to use? If yes, most of the design work may be done for you. However, you still want to review this with the team to ensure it contains the information you need. Most brand guides are limited to print, and they lack specific direction for a website. So you'll want to ask follow-up questions to determine how they want to handle that. One of the best ways to handle these information gaps is to ask them if they want to emulate their current public site. If this is the direction they want to go, you want to review that site with them and ask if there's any specific elements they want to include or avoid. Afterwards, explore that chosen website to find styles and see how colors, fonts, features, and accents are used. If they do not want to emulate their current site or if they think their brand guide is a little outdated or lacking, set aside time to conduct a lightning demos workshop with the team. The concept here is very simple. You have the team members come to the meeting ready with sites and apps that they found and that they like and would like to see emulated in your project. During that meeting, they're going to share their findings, and the team is going to discuss the different options. And out of this, the team should arrive at some conclusions for a design direction, some style guidance that they want you to take. And last, during the design conversation, take the time to review any and all assets you've been given, including logos, brand designs, and approved images. Try to get these items ahead of time so you can figure out what styles the brand guide, again, doesn't cover so you can ask for specific clarification. Now that you have all the information you can possibly gather to help inform your design, it's time to start putting it together. So what exactly is a wireframe? A wireframe is an illustration of a page's interface that specifically focuses on space allocation and prioritization of content, functionality available, and intended behaviors. Notice I said nothing about colors, fonts, or styles in that definition. Before you get started, here's a few things that I do to prepare both my team and my wireframing app for success. First, define the scope of your wireframes and subsequently your mockups. Wireframing an entire site can be really long, arduous process, so provide boundaries to the design process by specifying how many and what pages will be designed, deadlines for providing feedback, and limited number of feedback sessions. You also want to ensure that the team is on the same page about the purpose of the wireframes versus the mockups. Remind them in reviewing the wireframes the purpose is just to look at the functionality and the layout and make sure everything's as it should be and not to worry about styling at this point. Later, I'll give you some pointers for presenting your wire frames and mockups. And of course, set up your wireframing tool. Not everyone uses wireframing software on a day-to-day basis, so here are a few examples of software programs that you can use. Really, anywhere that you can draw a box and place text in it is going to do the trick. It doesn't take an artist to put together an intuitive wireframe, and honestly, this can be just as, if not more, important than whether or not you get the button color correct. Now, onto some best practices for putting together those wireframes. Think of your wireframe as an outline for your site page the same way you would outline a long research paper. This is what visual hierarchy does, and there's a few ways you can help to establish that. First, divide your page by functional sections. The portal design I have up to the right is a good example of the divided sections of a site. Here, I use titles, but you can also use alternating background colors and other tricks to establish these boundaries. Next, employ white space or the negative empty space on a site to separate your content and provide focus. Increased white space can help direct the user's attention to a particular item. White space is not wasted space, though I've heard many developers comment to the contrary. It helps give your users the chance to focus on only a certain amount of content at a time, which can really help prevent them from getting overwhelmed. And last, use visual cues to help direct users to different degrees of detail on the page. Just like in a research paper outline, use different indicators to help the user determine where on the scale of importance the item falls and further help them scan the content quickly to find what they need. A couple of other things to consider when putting together your wireframes is that you want to limit the number of choices available to your users, and you want to prioritize the placement of features and content to more quickly address those most pressing needs. As much as possible, ensure that your users only have to consider four to six items at one time. Keep this in mind for features like lists or groups of cards, especially if there are other content types nearby. If you have more than this number of items, use pagination, tabs, and filtering to help them narrow down those choices as much as possible. As I mentioned you want to ensure that the biggest pain points are clearly addressed early. If this means putting a link or button to that one catalog item that is submitted incorrectly 80% of the time right there on the landing page, that's what you do, even possibly using those visual cues to highlight that particular item. And last, I love to use my landing page as kind of the entry point or the triage point for the rest of the site. You're looking to give them an introduction to the different types of content available and by triage providing them with the most used or most useful content and services right there from the start, like I did at the top of the design scene here. All right, now that we've laid everything out, we have our nice boxes that tell us where everything's going to go. It's time to start putting those styles into place so we know what everything looks like after it's developed. So what exactly is a mockup? It's a high-fidelity model rendering of a product, or in our case, it's a picture of the pages that make up our Service Portal. First, let's talk colors. Overall, the thing you want to make sure that you do here is give every color a job. Start by working from the information provided by your team. If your color palette is limited, you can expand it by taking that main color and creating various shades, lighter and darker. I have been given portal projects where I was only given one color to work from, so I promise you, you can make it work. Next, strive to balance how the colors are used across the site. The 60-30-10 rule works really well here. 60% of the colors should be neutral and easy on the eyes. I tend to use a shade of light gray or a very light shade of the main brand color, which is used mostly alongside white for backgrounds. Next, 30% should be that secondary color you use to create visual interest. This is your main brand color, usually, that you're going to be using for links, buttons, and that sort of thing. That last 10% should be the accent color. This is your bright pop that provides differentiation and really calls attention to different things. And last, try your best to associate colors with a given functionality consistently. Interactive elements should be the same color. If you have headings the same color as your links, for instance, that can get confusing. You can see here on the screen, I've shown a bit of a color palette brand guide. We took the colors that our client gave us and expanded them into different shades and then assigned those colors to different functionalities, including links, text colors, and the brand primary colors. Next, let's talk about fonts. This could be a presentation in and of itself with all the nuances, voices, and styles out there. The big takeaway here is to use balanced variety to establish that visual hierarchy. First, consider all of the use cases for typography. You have the main body text, which is the majority of your site, but you also need to consider different heading sizes and how they're used in page section titles or in panels, for instance, but also the small text on your buttons and links as well. You also want to make sure that the fonts you choose are legible. I have up there a good use case for these different items. If you can't easily read the font at different sizes, you're going to have a hard time communicating effectively with your user. And last, use font weights and styles to establish that hierarchy. You can see there on the right that this can easily be accomplished with only one font. This particular client has Gibson as their typeface, and they show a lot of differentiation just using different font weights or thicknesses and different styles like all caps. If you use more than one typeface as I've done in many portals, choose a distinctive typeface for your headings and a steady, legible typeface for body copy. Open Sans is one of my go-tos. This next part is the hard part for me because there are so many little use cases and details that we could go into that are all considered elements. The big takeaway here is to remember that you're ultimately trying to put together a cohesive design where all the moving parts work together. Start by styling your common elements. These are your links, your buttons, your panels, and the other piece is provided to you by that bootstrap design. Next, consider the state changes and how they're going to look. These are your hover effects and such that are going to change when the user interacts with the UI. Taking the time to consider the state changes can really go a long way to making your site feel more dynamic and reward the user for interacting. And last, consider content changes. There's a lot of dynamic content on Service Portal sites. One of my friends, who is a phenomenal developer but very much not a portal person, really helped me see the importance of this attention to detail. At one point, I showed him one of my designs, and he peppered me with questions. What does this look like if there are no items on the list or 20 items? How about if the short description for one of those requests is really, really long? You want to have a plan for how the design changes as the content changes. All right, once you've put it all together, the hard part is still in front of you. So here are a few things that I do to get through presenting a mockup to a project team or stakeholders and handle the feedback that comes with it. First, put this in front of your internal team before you put it in front of a stakeholder or client. This is going to help you ensure that you fix anything obvious that you missed, and it's going to help you get a good idea of what kind of feedback you can expect. And it's free practice. As you go into the meeting, inform your stakeholders of when they can ask questions and how feedback is going to be taken. I tend to review a page section by section, like about as much content as you see depicted there on the screen, and then I will ask for questions before moving to the next section of a page. They're going to interrupt you anyway, but it does help. As you walk through your designs with a nice, calm voice, note the use cases, functional requirements, and other decisions that led to the design as presented. Showing the rational explanation behind the visual design can often move stakeholders to see the reasons behind your choices and move them towards approval and help you avoid unnecessary adjustments. And as a bonus note that I forgot to put on this slide, some of the common pushback that you may get includes disagreements with the features placed specifically on the landing page or disagreement with the general design direction. Make sure your project manager or your other leadership is on board and ready to support you and be ready to back up your decisions with the direction and the decisions given to you by the stakeholder team members. If they suggest a change that would be detrimental, ask them what use case or requirement such a change will support. This is going to help you understand the need for the desired change and possibly find a better solution. All right, again, I hate how limited our time has been because there is so much depth to different tactics and topics that we've covered here today. If you have any specific questions, please reach out and let me know. I'm happy to help you become more comfortable with the design process however I can. I hope this is encourage you to see that the process of front-end design is a skilled, practiced endeavor, just like any of the other development work you've done, and I hope this also provides you with a roadmap for putting together designs that you can be proud of. Thank you. [MUSIC PLAYING]
Using Advanced Work Assignment to get the right query agent on the job for users
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello, good day. In this session, I'm going to present how we can leverage the advanced work assignment concept in ServiceNow to assign the right query, right work item to the right agent so that we can increase the productivity of the agent. And by finding the right agent to the end user I will contact, they'll be getting the best services using this topic. Coming to my introduction, I'm Chandra Sekhar Maganty. I'm working as senior associate in PwC India Acceleration Center. Coming to my experience, I'm having 12 plus years of experience in both the academic background as well as professional background. During my academic experience, I've trained around those instruments on ServiceNow for developer certification and admin certification. With the help of ServiceNow, we ran the program which is called ServiceNow Academic Partner Program in India. So during my professional experience, I had worked with several ServiceNow models like ITSM, CSM. And in PwC, I'm part of enterprise technology solutions, where I mostly work with [INAUDIBLE].. And during this session, I'm going to walk through with the advanced work assignment configuration. And I'll be giving a demonstration. And then we'll be having some few takeaways. So before going to the configuration, I just want to brush up a few terminologies which are related to advanced work assignment. So the first term which I will be going with is service channels. So service channels is a medium where an agent-- sorry, the service channel is a medium where the end user will be having a interaction with the agent. It might be through a chat or interaction, or else, it might be a type of case. It may be an incident as well. So we have three service channels, which comes up with these, which is case, incident, and chat. So every service channel will be associated with queues. We'll be having a different set of queues which will be checking the conditions and which will be written in true or false, based on the conditions we describe in the queues. Next we talk about is eligibility criteria. This is where we can have multiple assignment groups which are associated with the queue. And based on the time we give the assignment. And then as I mark eligibility criteria will be assigned to the particular group. And we'll be selecting a right agent using assignment rules. And coming to the assignment rules, this is where it will be deciding which agent need to be assigned to the end user's work item with my pay queue. It might be an interaction, or else, it might be a case as well. So it depends on maximum capacity, which has been allocated to the agent or as it might be the last assigned work item, which has been given to the agent. And also, how much time we need to give the-- how much time the work item should be present in the agent inbox. And coming to the use case, which I'm going to present today. I'm taking a Spanish customer, Spanish contact. So that contact will be trying to connect to the live agent through Virtual Agent. And also, she'll be creating a case in Spanish language. So how it works is when our work item, is created by the end user, service channel constantly will check whether it is a chat, it is a case submission or not. Then it will decide what service channel it is. Then it will go with the queue, whatever queue is associated with the service channel. It might have separate views. And it will select the correct view based on the conditions which we write and then use. And I prefer going to the queue. It will check the eligibility criteria. It will check what groups are there in the eligibility criteria and what time we have given, the time we have given to the eligibility criteria. And after selecting the correct assignment group, using assignment rules, it will select the right agent. And it will assign to that work item. So that's how it works. Before jumping into the demo, I'll show some basic configurations which are required for data [INAUDIBLE]. So before discussing the configurations, I'll be showing the person as the first person I contact. So we are having a contact, Tokyo. So we can see language. Tokyo's language is English. So she would be expecting a better service by providing the Spanish-speaking agents whenever she creates any work item. It might be a case. It might be chat, interaction, or anything else. And we have two persons, two agents. So one is Professor. Professor is one of the agents. So I've created a skill in CM and underscore skill table. The skill name which I've created in Spanish. And I've assigned that skill to the Professor agent, Professor record. And next user is Berlin. Berlin is another agent. In the same way, I have assigned a Spanish skill to the Berlin record as well. So two agents are having Spanish skills. And Tokyo, language is Spanish. Now come to the configurations. So first configurations would be Chat and Case. So the configurations which we'll be talking about in service channels is giving the capacity, giving the capacity. So for the case service channel, I've given 50 capacity. So it indicates that an agent can handle a maximum of 50 cases at a time. At any moment, they can handle at max of 50 cases. So if it's having or if it's already allotted with 50 cases which are in that New and the Open state, then no other work item will be assigned to that agent. So I want to talk about Agent Capacity Override. Agent Capacity Override is nothing but if any agent, if we feel any agent is capable of handling more than 50 cases, then we can create a record in this related list by providing the name and by providing the capacity. Whatever capacity we provide here, it will override the default capacity we've already checked. And next thing I want to talk about is the Layout. In the Layout, we can configure the fields which we want to display on the card, which will pop up in the agent inbox in Agent Workspace. So these are what we can configure, particular fields. Next thing I want to talk about is queues. So let me open two queues, one queue for Chat and one queue for Case as well. So any service channel can be associated with multiple queues. How a queue will be selected once a work item is created is it will check the service channel. And it will check the associated queues which are assigned-- which are associated with the service channel. And it will check the conditions. If a condition is return true, then it will go to assignment eligibility. So before going to Assignment Eligibility, we can specify conditions in two ways, one is Advanced by writing a script, which I've written the script for the chat. And another one is a Simple condition mode, a normal condition mode by simply providing different conditions. If condition is satisfied, then it will go to Assignment Eligibility. In Assignment Eligibility, we'll be providing the assignment groups. We'll be providing the assignment groups. We can have one or more assignment groups. If we are having multiple assignment groups, then it will check the eligibility. Once an assignment-- once a work item is created by the end user, if this queue is returning true, then it will go to the Assignment Eligibility. And it will check the eligible time. So I've given 0 seconds for Heist 1. So it will be going into Heist 1 one assignment group. And then, there is one assignment group. Based on the assignment rules, it will search for the right agent. If at all-- if none of the agents are available, then after waiting 45 seconds, it will go to Heist 3 assignment group. And it will search for the agents in that. So that is about queues. Next time, we're discussing the important part, Assignment Rules. This will decide to which agent or to which agent the case should be-- work item needs to be assigned. So we are having two conditions here, one is by Most Capacity and another one is Last Assigned. So based on this, a work item will be assigned to the agent. So in our use case, I'm taking Most Capacity. It indicates that whichever agent is having less number of work items in his bucket, that agent will be selected. So Rejection Handling section, we'll be having a few options like Allow Agents to Reject. Once a work item is created, if that work item is bumped up to an agent inbox, we'll be having two options, accept and reject. Reject option will be there only once we select this option. What else? If we don't select this option, the agent option will not be there. It will be having only accept. That's it. And Timeout is nothing but how much time a work item should be present in the agent inbox. For our use case, I've taken 30 seconds. So for 30 seconds, a work item will be present in the agent inbox. And Reassign on Timeout option is nothing but after 30 seconds, what happens if an agent is not accepting the work item or as he's not rejecting you? So what happens after 30 seconds? If I select this option, it will search for next best available agent to assign that work item. So that is what this option is. Next option is Skill Handling. So I enabled Skills. And I've enabled Enforce Mandatory Skills. So this indicates that in order to assign a work item to an agent, that agent needs to be mandatory. He needs to be having those skills in order to handle that bucket item. So that is what Skill Handling is. Next is Presence States. We are having three states, Available, Away, Offline. These are the states where agent can select. Once he logs in, probably, he'll be selecting Available option so that he can take up work items in order to work. Away is nothing but when he's going away from the system. Offline, once he's logging off, he'll be selecting the Offline option so that no other-- no work items will be coming up in his inbox. So Reject Reasons are not-- we will be having four reject reasons. First one, it will automatically timeout after 30 seconds elapses. And the other three options are agent selectable options. If at all an agent is rejecting any work item, then he needs to provide any of these options. It is a drop-down choice list. He needs to select this. We can create other reject reasons also by simply clicking on them. But then, yeah, I'll go with the demo. I'll go with the demo. First, I'll create an interaction record. I'll connect to the live agent. Then I'm in Tokyo. Tokyo will be connecting to the live agent. So let me click on Virtual Agent. Let me try to connect to the live agent. Yeah, it is waiting for the live agent. I'll switch to the agent inbox. Yeah, so this interaction record has come to Professor's inbox. So it will be reset, I've given 30 seconds. So it will be there. This work item will be there for 30 seconds. And this is the card. As it is interaction, this is how I configured the interaction card here. So it will wait for 30 seconds. After 30 seconds elapses, it will go-- it will search for the next best available agent, which is Berlin, because Berlin is having the Spanish skill. So yeah, this is how it works. He can accept it if he can't reject it. If he accepts it, so he will be having an active chat. He will be interacting to the agent. He will be interacting with the end user. And let me do that. Yeah, so agent has provided a Hola option. Hello to the Tokyo customer. So Tokyo can provide her query there. So yeah, Berlin received whatever message that Tokyo has typed. And he can provide whatever he wants to do. And there are a few options there, quick actions to be precise. We are having response templates, which are predefined as response templates. Agent can transfer to another agent. He can create the case through the interaction. Several options will be there which we can use. If he wants to end the interaction, so I can simply click on End Interaction, End Chat. It will end the interaction. So interaction is sent here to the Tokyo customer. So next few skills I'll be discussing is creating a case. So Tokyo is trying to create a case. Tokyo is creating a product case. So I need to select an asset. And I'll try to select an asset. I'll provide some short description then subject. So yeah, the case is created. So a case will be popped up in any of the agents. It let me switch to agents window. It is not there in Professor's inbox. So it would be there in Berlin's. Yeah, it is there. So it will wait for another six seconds. So Berlin didn't accept that case. So let me switch to Professor's inbox. Yeah, in Professor's inbox, a case has popped up in this box. So we can accept it. Or else, we can reject it. Or else, we can just leave it. If he leaves, it will search for another agent. If none of the agents are there, it will go to assigned work items. Then the question is, if none of the agents are accepting the new case, then how that case will be handled, so how the manager can assign that case. So let me go to manager's perspective. So managers will be going to Unassigned Task Work Items module, where it will be showing the unassigned work items. So let me filter it with Created. So this is the case which is not accepted by any of the agents. So we can Open the Record. So manager can see. In the Offer Details section, manager can see at what time that case has been assigned to which agent. In this, it is assigned to Professor this time. And it is assigned to Berlin at 12 13:56. So manager, case manager, can see all these details. And he, case manager, can assign manually here by providing Assigned to or as Assignment Group. He can do that. So that is one thing I wanted to present. And also, case manager can see Agent Presence & Capacity. We can see-- case manager can see all agents that are available, all agents are offline, and what are their Capacity in Use. We can filter it with Available. So Professor is available for both Chat and Case. Berlin is available for both Chat and Chase as well. And this is the Capacity in Use. And another important thing I want to show is Operations Dashboard. So Operations Dashboard doesn't come with a basic AWA plugin. We need to install another plugin for AWA Dashboard. It is Advanced Work Assignment Performance Analytics Dashboard will be there. So once we install that plugin, we can have access to this out-of-the-box dashboard. This dashboard, we can see-- case manager can see what work items are waiting, how many agents are available at this point of time, how many work items have they accepted for the day, what is the average wait time, everything, how many agents are online, how many agents are offline, available agents, everything. Group-wise, they can sort it out by group-wise, queue-wise. Anyways, any piece of information regarding AWA will be provided in AWA Operations Dashboard. Yeah, that is for the demo. I'll go ahead with the few takeaways. Yes, the first take away I want to focus is skills can be managed from skill determination rules, which we have created a few skill determination rules, or else can be managed by using business rules as well. In my demo, I've used skill determination rules for chat. And I created a few businesses rules for case skill determination rules. So another important takeaway is we need to enable Virtual Agent in the portal so that end user can contact live agent, can interact with the live agent. And after installing skill determination plugin for AWA we'll be getting two business tools, out-of-the-box business tools, skill determination work case and skill determination for interaction. By default, both of them are inactive. We need to make them active in order to work on skill-based sorting. And for better visibility of work and agents' presence to the manager or else admin, we need to use AWA Operations Dashboard, which comes with the Performance Analytics, Content Pack, Advanced Work Assignment plugin. We need to install this plugin as well. And in my demo, I went with the Spanish language. So I need to install the Spanish language plugin as well. And a few more plugins are Advanced Work Customer plugin, Skill Determination plugin. And if at all if I want to have instant service channel and case service channel, then I need to install Advanced Work Assignment plugin for CSM and Advanced Work Assignment plugin for ITSM as well. Yeah, these are the takeaways. Thank you. [MUSIC PLAYING]
Where employees and agents get the best UX – Employee Center and Workspaces
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] According to Gartner report, only 13% of the employees are fully satisfied with the experience they're getting. There are over 87% of the employees that are not happy with the experience they're getting. This is not a good thing. So this might be due to many reasons, and one of the reason is that they are not getting a unified employee experience. User experience matters a lot. I am Sai Srikanth, and am a design lead at Kaptius. At Kaptius, I lead the Design Studio Team to deliver solutions and also help our clients to get full value out of the platform. And we also provide good user experiences and app engine solutions. So when we talk about the experiences in ServiceNow, it offers Employee Center for employee experience. This is standard multi department and dynamic portal for service delivery and engagement. It can easily scale to support all departments and services. Employee Center comes in two offerings. In the basic one you get the multi department service delivery, whereas in Employee Center Pro you get employee communication and engagement in addition to service delivery. Let's quickly see the basic picture of Employee Center. You can push your catalog items, knowledge articles, employee communications, and quick links to your Employee Center, and all your departments are added as form of topics to the taxonomy, and each topic has its own dynamic topic page. And you also have some page configured widgets. Don't worry. Let's go ahead and see it in action. Now I'm logged in as an employee, and this is the Employee Center group. On the top, I have my tasks and also my requests. And here you can see your department, and each department has its own topics and sub topics. I browse IT, and this is a dynamic topic page for that particular department. As you can see, it is organized into topics and sub topics. You can find all the information you need for that particular topic. You can filter it by article, and also you can filter it by catalog items. This is a sub topic in our IT topic, and it has all the content so you get all you need at one place. I'll go back to the home screen, as you have learned to explore. This is the content experience, and each of this content is actionable. You can add your campaigns to this as well. And here you have your search, which supports the enterprise search where you can search across your organization. You have your popular topics within organization, and you can also have your recommended items. This is the quick links. You can add the links within your organization so that it can act as an interact. You can put your video content and also any links to the My Applications, and you can have your upcoming events. And this My Active Items is kind of a mini dashboard where a user can get the holistic view of what's happening with his tickets and if he has any to do task. So it's easy for him to take any action quickly. So when I click on the task, it takes me to do, and I can just simply click on the button by reading the stuff. So this is how the Employee Center looks like. Let's see what's under the hood. So as we were discussing, in Employee Center, everything is linked to the taxonomy. Let's go ahead and explore the taxonomy. So this is our employee taxonomy linked to the Employee Service Center. We would suggest you to create your own taxonomy and create your departments as single topics here. Let's explore the employee taxonomy. Here you have the IT department as a child topic. In each topic you can have the taxonomy linked to it and ordered, and also can add cool icon and the banner images. And for this topic, you can add the child topics and also you can link the content to it. You can link to your catalog items, knowledge articles, and also the quick links. You also have the ability to feature the content. So this is how you can organize your stuff within the employee sector. You just create the records, and it creates a dynamic topic basis for you. Now, let's explore one more cool thing, activity configurations. It's the mini dashboard that you saw in the Employee Center. You just need to create a record here and define few things. Let's take an example of requests. As you can see, we just gave the name, and also we link the page to redirect it to once you click on it. The summary view script shows the count of that particular box, and this list view script populates the data for the cards. Let's go ahead and see what we are talking about. So this is the account you see on the card, and this is the data you see. So it's just that easy to configure the things in Employee Center. And you also can configure the To Do page, your Ticket page, you can add new request filters, and all of this by just creating records and configuring the things. Now, are employees happy? And it's equally important for us to make our agent happy as well, and Workspace does exactly the same. So this improves the agent efficiency, and it enables your agent to work on multiple issues concurrently into the layout. It improves their productivity. And this Workspace built with the new UI Builder boosts a lot of things. When you're talking about the Workspace, we have two different things. One is the Agent Workspace and HR Workspace which just have a few components, and which cannot use the full capacity of the UI Builder. In configurable Workspace, they can utilize the full capacity in the power of UI Builder. Let's take an example of CSM and FSM configurable Workspace. You have access to many components and you can create awesome experiences. And you can create your own components as well inside the UI Builder, and this UI Builder is not only limited to Workspace, but you can create your portal experience in this way. Let's see it in action. So this is the UI Builder where all the magic happens. You can create your experiences by defining the app shells. You can differentiate the experiences page on the app shells. And now for this demo let's consider CSM and FSM configurable Workspace. So for every experience or Workspace, you can create the pages and there are many existing templates for you to create the pages very easily. And there is one more cool thing. You can show different views for the same URL on the page, and this view is called variant. And this variant can be defined using the audience. You can simply create a variant and add your audience to it. Let's go ahead and explore components. You have access to lot of components, and all of these components can be added to your experience and they are configurable. Using the data resource, you can add and fit the data. Let's quickly go ahead and add one. You can see your scope here, and you can see many operations that you can pull from that fits the data. You also have client state parameters and also page scripts can be defined. Let's quickly go ahead and add a component and let's see how you can configure it. I'm adding a button to my experience. Another use case is to link it to the native UI. Another use case is to link it to the native UI. So this is the button. Let's go ahead and configure it. In configuration tab, you can pass on the data to your component and go ahead and add the label. While adding the data or inputs to your component, you can either add a static content or you can dynamically fix the data. Go ahead and dynamically fix the data. So as you can see, the data is dynamically fixed. And also, you can write the script to do the same. OK, we got the user's full name. Now let's straighten it. Right. We are done. So you can see it's reflecting on our product. And in the style step, you can define the styles for your component and you can also add your own CSS. And this event handler is a place where you define what should happen when you click on your component or when you interact with your component, and you have many options in this event handler. For now, let's take link to destination. I select my destination and we are done. So whenever the agent clicks on this button, it takes him to the native UI. It's just that simple. You have a lot of components you can add to your experience and make it beautiful. And if you want to create your new components, you can use the Now UI framework. There are a lot of good resources on developer channel-- service on developer channel, and also there are good blogs in the community as well. So there is no limitation for UI Builder. You can go crazy and create awesome experiences. So now both our employee and agent are happy. So here are the few takeaways so that you can crack on to implement this for your organization and also for your customers. For Employee Center, please check the licensing. And also while you are installing the plugin, use the out of box fix script to fix all the restricted corner accesses. And we would recommend you to create your own taxonomies and organize the content into topics and sub topics. There is a lot of stuff you can configure using Employee Center. You can configure your activity configurations, To Do page, Ticket page, and there are a lot of out of the box widgets you can use. And for the Workspace with UI Builder, you can create your own components using The Now Experience framework. And the UI Builder is not only limited for Workspace, but you can create different experience like portal as well. If you are using the [INAUDIBLE] Studio, you can create the Workspaces in just a few clicks. If something is not loading in the UI Builder, you can go ahead and repair the plugin and it works fine. So these are the few takeaways, and I hope you got something useful in this session. Thank you so much.
Accelerate the self-service experience using Catalog Builder
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello, everybody. I'm Paul Morris. And today, I'm excited to talk to you about how you can accelerate the self-service experience using Catalog Builder. And I will also be sharing some of my tips and tricks for success with Catalog Builder. Now, I've been working on the ServiceNow platform for over 10 years. And typically, once a service catalog goes live, everyone is falling over each other to get their catalog items added to the service catalog. And us poor ServiceNow admins and developers, we can't get them in fast enough for the customer. No matter how quickly we try and get them in, it's never fast enough. You'll never find someone that wishes their cadence of catalog development was slower. Everyone wants more items in faster and better. So ServiceNow has a tool called Catalog Builder that's been sitting in every ServiceNow instance for quite some time that's just waiting to be used to help you guys accelerate catalog development. So what catalog development typically looks like. You've got a business owner, and they go out and gather catalog requirements to build a catalog item, which then gets put on the self-service portal. Traditionally, what happens, the business owner or someone on behalf of the business owner I gather there's those requirements. They give it to a ServiceNow administrator or a developer, and then they wait weeks or months. And eventually, they'll get a catalog item, their catalog item on the self-service portal. But that's just not quick enough in this day and age where everyone's working from home, and they want to be able to request things on the service portal. So here comes the Catalog Builder. So first, the catalog admin comes in and creates a template for the business group. And then the business owner, as they already are doing, they gather catalog requirements. But now with Catalog Builder, the business owner has empowered themselves to create the catalog item themselves rather than waiting for an admin or a developer to do it. They can even preview that catalog item in multiple channels after they create it to get that immediate feedback, and then take it through a pre-published flow, and then publish it to the catalog. This is done through a new user interface, which is a user-centric design wizard that takes the user step by step through what they need to do to complete a catalog item. It comes with a drag and drop form designer, which not even the ServiceNow admins get. And as I mentioned previously, they can preview what the form would look like in various channels. And best of all is they don't need to have a ServiceNow admin account to be able to do this. So is it a good idea to be giving every single business owner access to Catalog Builder to start building catalog items? Well, we want to pick who our builders will be quite wisely. Someone who understands the organization's fulfillment process. At the end of the day, they're not just building a form. They're also building the fulfillment process that comes after that form is built. We want someone that's going to be building the right items, not just what they personally want, really need to take into consideration what the business strategy is to make sure that the right items get built. Someone that has a sound understanding of process and a good understanding of ServiceNow so they can roll with the terminologies that are in Catalog Builder. They need to be motivated to build the items, because most likely they're busy and they've got another day job that they're doing. And they have the capacity to build those items. You're not going to be able to accelerate the development of catalog items if you've got a Catalog Builder that wants to build all these items for their particular business area, but they don't have the time to do it. So it's important to choose your builder wisely. So once you've chosen your builder, they're now going to be building catalog items instead of your ServiceNow admin that has a lot of experience and was probably doing a pretty good job. So how do we make sure that our new Catalog Builder is doing a good job? We create design standards. We need to first define what a good item looks like, put it in a document, and all agree that's what a good item looks like. So we can give it to our Catalog Builder, and they know the correct language to use. They know how to present the form properly, doing it in the same way every time. So you've got a catalog that is consistent across all your different items. We define the roles and responsibilities around the service catalog as well. It's one thing having standards. But if number one is making sure those standards are met, they're not going to be very helpful. So you want to make someone accountable for making sure that these standards are met within this service catalog and noting down what all the catalog rules are so everyone can work together. You may also wish to define what the Catalog Builder can and cannot do. The catalog Builder unlocks around 80% of the functionality in a service catalog. But the other 20% still needs to be done by an admin. So you want some sort of process on how to handle those edge cases if you want to design an item outside of what Catalog Builder would let you do. So without that design standards, you might get items of varied quantity, quality, and that's going to stop you from accelerating. So it's important to stop and have those design standards. So once you've got them, you can accelerate forward and increase your cadence on your catalog development. So it's not just about the Catalog Builder. The catalog Builder has access to this great tool. But there's a lot of other people that are involved in the entire process of managing a service catalog. So it's important that everyone works together. This includes other roles like the ServiceNow administrator, a catalog admin, and even the fulfillment team that are actually processing the items once they've been logged by end users. It's important to leverage the expertise of others, especially if you're a new Catalog Builder. Your ServiceNow admin already has years of design experience building this catalog items. So it's wise to leverage that experience. And let's not forget the domain knowledge of the facilities who are actually completing the requests. You need to talk to them and make sure that you're representing the correct process in your catalog item. So when the fulfillment team run through the process, it makes sense and it's correct. So we're working as a team, creating all these catalog items. But when it comes to building these forms, how can we accelerate the creation of these forms in Catalog Builder? One of my key tips for doing that is using question sets. So what is a question set? It's a set of predefined questions that you can just plunk on to the drag and drop form builder that might have a number of questions already set out for you to reuse across as many items as you want. So that saves a lot of time, so you're not constantly rebuilding the same form over and over again. And it also helps you standardize what these forms look like. Now, question sets can only be created by ServiceNow developers or possibly your catalog admin. As I mentioned in the third tip, you really all need to be working together and communicating to accelerate and push forward with your catalog development using Catalog Builder. So speaking of building these catalog items, where should we be building them? Should we be building them in straight into production? Do we need to test? It's a good idea to follow whatever your existing development lifecycle process is in ServiceNow. I know the key word there, development lifecycle, but development does include testing. Testing is still quite important. Yes, in Catalog Builder, you can preview what the form looks like straight away. But you can't test the workflow behind that without first publishing it, which then puts it on the service catalog for people to order from. And do you really want to be doing that in production? Probably not. As you're building questions on your forms, Catalog Builder lets you create dynamic behaviors to show questions and hide questions based on certain things, though the way those questions react to behaviors might be different in the Service portal to how it does in the agent user interface. So you really need to test it there as well. And again, you don't really want to be testing in production. The process behind the form, the fulfillment team are actually processing that needs to be validated end to end. So it is just best practice as you would with typical ServiceNow enhancements to migrate those changes through the environments from dev, test, and production. And that's actually a best practice today. Yes, you can build them straight into production technically. But just because you can, doesn't mean that you necessarily should. And your developer needs to be aware that there are some technical challenges around deploying updates with Catalog Builder. But you can read up on some of those in my ServiceNow blogs. So tip number 5 there, follow your development lifecycle process. So summarizing my top five tips. We choose our builder wisely. Once we've chosen our builder, we make sure that they have design standards before they start pumping out catalog items. Make sure they continue to work as a team, and don't work in isolation. Work with catalog admins, work with ServiceNow admins. You're leveraging question sets, so you can build those forms quicker and get more catalog items out. And you're following your development life cycle process, which is in the long term is going to get you more throughput of catalog items, because you're more likely to get them right the first time. Now, Catalog Builder has been around since Quebec. So if you're looking to speed up the development of your service catalog, leverage these tips and tricks that I've shared with you today, and begin your journey accelerating the self-service experience using Catalog Builder. Now, I'd like to thank everyone for watching this video today. If you want to get in contact with me, you can find me by email, LinkedIn, one of my favorite hangouts, Sndevs Slack. If you want to know or see more of my ServiceNow content, you can read my ServiceKnow-How blogs. And if you want to know more about, Kinetic IT, the company I work for, you can visit their website. Thanks, everyone, for listening or watching. And hope you have a great digital knowledge experience. [MUSIC PLAYING]
