Knowledge 2022

## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hi, and welcome to the session called let's break down AI Search and how it works behind the scenes. I want to talk to you about AI Search. and what it is, but I'm not going to walk you through how to set it up or even show you what it looks like. I am, though, going to walk you through some of the main mechanics on how AI Search does what it does, and by doing that, give you a better understanding of how you can shape your content to provide better value for your end users. So the agenda is this. So we're going to quickly just look at what AI Search is, then we're going to learn about indexes, something called word stemming, and search term relevancy-- how to make your search relevant. And then we're going to look into how AI Research deals with typos, and in the end, look at how this matters. Why do we need to know these things to work with AI Search? So allow me to first introduce myself. My name is Anders Figenschow. I am a certified master architect, and also a ServiceNow developer MVP. I work at Sopra Steria as CTO and digital workflows, and I have about seven years of ServiceNow experience. But I also have 22 years of experience as a software developer. And if you hear me talking, just like now, my experience of those two years are heavily influencing what I'm talking about. So one of my last projects now was to work with Inter IKEA with their transformation of document management. And if you're attending the Hague this year at Knowledge, please do come by and have a look at that session as well, which I'm having with that customer-- as well as I have an in-person version of this session, which is a bit longer, and you can come and have a talk with me after. So what is AI Search? So it is the next-geneation search engine from ServiceNow. The previous one was Zing Search, and it's-- this new one is being made from the bottom up, so it doesn't really re-use anything from the old search, and then has a lot of new capabilities that improves it a lot. We're going to look at how that works. To install AI Search, you have to specifically ask for it. But you can do that from within your instance. You write AI Search status in the search-- in your instance, and it will give you a place. You can just click and request for it to be installed, and within a day or two, you'll have it ready to use. And you can just set up the search sources, and you're ready to go. So let's have a look at the architecture of AI Search. So there's data first-- so for example, knowledge articles, catalog items, users, or whatever you want to be accessible for the search engine as a search source. So the index is in the middle, and there's a reason for. That is the core engine, is the index, and we'll have a look at that in a second. You can also index external sources. So if you want to index data from, for example, SharePoint. You can set that up as well. And it's using API to grab the content, place it into the index table. It does not copy the articles itself, and it will not display it within ServiceNow. It will actually redirect you to where that content is originally. Then you have the service portal and mobile apps, and so on that is utilizing the AI Search-- which is basically a front end for the search engine itself And of course, you have the technologies that are underlying technologies that helping you out-- the machine learning the natural language and so on. So the features of the search engine AI Search is these index tables. It has typo handling, word stemming. It has some algorithms to create the scoring relevancy for a search. And it's something we'll look into also. And there's two things I want to mention while we're on this slide, which is the stop words and the synonyms-- so the synonyms first. So if someone is searching for a broken laptop in the search portal, in the Service Portal. Maybe it doesn't say laptop in that article. It says computer-- so broken computer. So instead of having to index every single variety of this to make your end users find the article, you would add a synonym of laptop to computer, and the search engine understands this, and it will find that article with the same sort of relevancy. The stop words is the opposite. So you have a dictionary-- and it's already in your instance-- that is containing words that are never relevant for a search, because if you have a word that is in each and every article, it carries no weight. So if the word me is in all articles, then searching for help me doesn't really work in the search engine. So you have to stop words that are basically excluding these very common words, so it doesn't mess with the weighting, and the scoring system, and the relevancy. Of course, if you're into that sort of thing, you can use stop words dictionary to censor. So you can maybe censor articles that you don't want people to see-- which, if you're in a country with as popular, that's what you do. Let's have a look at the indexes and how that works. So the index is the core of the search engine. It is a collection of all of the words present in your content library-- for example, the knowledge base-- with the listed scoring to each one pointing to each article. Now, it works the same way in, for example, a cookbook. So if you have a cookbook, you want to open up a cookbook and find a specific dish you want to make. You don't browse each and every page of hundreds of pages potentially to find your recipe. You would look in the back. And here's one example of a table of contents. So maybe I want to make light and fluffy waffles. So it's on page 21. So if I switch each and every page and go to page 21, it takes a long time to find it. So instead, I can just browse this very quick index and find that, oh, what I'm looking for is on page 21. There you go. There's my target. So I use that. So an index table in ServiceNow and other search engines as well is working the very same way. So it's creating a list of all the words that are relevant for you and telling the search engine where to find them-- so which article has this and that word or that term. And it will just be very much quicker to search through a smaller table with less data. And having less data is actually very important. So you need to, when you're building your index-- and how ServiceNow does this as well-- is to try to reduce the need to have these words. So stop words is one way. You don't need to index something that is in the stop word list. But you also need to take into consideration that you have variations of words. So when we get to that, we have something called word stemming. So let's look at one example of variations of words where you don't want to index all of them. So the word consult, that is the stem word for these variations-- consultant, consulting, even the plural, consultants. So instead of taking all of these words and indexing them, making the index potentially eight times bigger than, you have to making this slower to search-- then ServiceNow will just index the stem word consult. And when you're searching for consulting, it knows the stem of that word also, and it finds just the stem word. So it treats them as if it's the same one. And it will list up articles that has all these variations, and that's very useful as well. I have some code, actually I want to show you-- how it works. So there was a guy called Porter, who created an algorithm called the Porter stemming algorithm. So I found this just by looking around the internet. And it was fairly easy to find people who already made JavaScript versions of it. So I put it into a Script Include, and I want to look how-- see how it works. So in this one I'm just having-- inserting a word and finding the stem of that word. That's everything this does. I'm not going to show the code, because we don't have much time. So we just have to look at the results. So I'm going to try the word computerize. What is the stem of that word? So we can see here that the stem of computerized is computer-- makes sense. Let's see if we get the same result if you take the plural of computer, computers. No, actually not. So it's compute. So there's some surprises when it comes to these algorithms, but there's reason for it. We can even try to do something else. We can take computerism, if that is a word. And the stem of that one is computer as well. So with these examples, you can see how it shortens the world and finds the stem of it. There's a few words that-- not possible to use an algorithm for. For example, if you have words like verbs, like I am, you are, those are transformative, so they would be a little bit different. So in those cases, you have the most common ones are actually being translated into one of the forms of that word. And that's how you can use the Porter stemming method-- and how ServiceNow does as well-- to find a stem of a word. So then there's the search term relevancy. So when you have these words in the index, ServiceNow and the search engine needs to know your search query's relevancy to the different articles. So if you write broken laptop, some articles might be more relevant than the others. So how do we do that? So there are some algorithms again. So there's one call to TF-IDF algorithm. And ServiceNow is using this, and several other search engines are using the same one. So what it does is it's calculating the frequency of a word within the document. Let's say you have a document with 100 words, but the word laptop is mentioned twice. So you have a frequency of two. And then you have the inverse document frequency, which is basically count the frequency of a word across the document. So you can see, how relevant is the word in one document compared to the relevancy across all the documents? And with this algorithm, you can actually see that it gives some pretty good results when it comes to these search queries and which one's the search engine promotes to be the top match. And it places this into the index with the word. So maybe the word laptop is a pairing three articles, but one is more relevant to the other, because it has a higher TF-IDF score. That is the relevancy score. So the problem with people is that they can't always type correctly. And me being Norwegian, English being a second language, I type wrong all the time. So for these search engines to have type handling, it's helping me out a lot. So how does this work really you cannot add all the variations of typos into the index. It would make the index too big. So you need some dynamic algorithm to deal with these typos. There's, luckily, some smart people already figured out how this works, and there's something called string metric, or edit distance. What that means is that you have two words and you compare them to each other of how far away they are. What that means is, how many changes do you need to make to one word-- changes to the characters in that word to match the other one? So in this example, we have the word intention here, and you have another word called execution. One change is you can delete one character here, you can substitute these three characters, and you can insert another one here, and those five changes will transform the first word into the second one. That will give this a distance score of five, according to one of these algorithms called the Levenshtein algorithm. It's not documented ServiceNow is using the Levenshtein algorithm, but I'm assuming they do, because if you look into the Script Includes, you find the mention of Levenshtein a couple places. So I went and found that algorithm and tested it out in my own instance. So how about we have a look now and see how that works. So first let me show you that. I'm just making an array, and I'm just adding a few words into that array, just as a proof of concept now. And I'm going to look at a few of these words, but I'm going to write them as typos and see how the Levenshtein algorithm or the string metric at a distance algorithm works and gives me the best results. So first let me try to type in computer, but I'm adding an extra r. Like I told you, you don't want to index this word, because it has a typo. So I'm going to look through my array of words and see what the distance is for the nearest word. So here it says, you were looking for a computerr-- with an extra r-- and the closest word in the dictionary is the computer. And it has a Levenshtein distance of 1, which makes sense, because I just needed to delete this one. Let's try another word. Let's write comutre. I'm not sure this is a word. But it says that the closest word is commute, and it has a Levenshtein distance of 2. So this is the closest word. It realizes that this is probably a typo. Now, of course, as you can see, you have a much farther distance for all these other words ServiceNow is the distance of mine. So it's very far away. A good way to think about this is that you've put a threshold on it, and everything above, for example, 2 or 3 is probably not a typo, but a different word. So if I write something gibberishy, like this, let's see what-- it will find the closest word, but it probably won't be considered a typo. So the closest word is-- actually, several ones have this same distance, but 8 it is most likely not a typo. It's a different word. So this is how ServiceNow also uses algorithms to deal with your end users' typos and still give a good result. Even Google has this. If you write something which has a typo, it will ask underneath, did you mean, and the word closest to that one. And it will actually give you the results without the typo itself. So what? Now that we know how the search engine deals with typos, how it scores for relevancy, how it stems words and uses that in the dictionary, and how the dictionary's built, then so what? Why does this matter to us? Do we need to know these things to use the search engine? Well, obviously not, but it will help you to deliver better value to your end users if you know how it works. Let me explain. You can now advise your customers on how the relevance scoring works. So if you have an article with 100 words, if you have 10 words of those being the same, it will score very high in the relevancy scoring. So you can now tell your customer or end user that the frequency of word matters when it comes to the relevancy scoring in the search engine. Now, you can also tell your customer and user how ServiceNow handles the word variations. You don't need to put all of these variations in a meta field, for example, like computer, computerized, computers. ServiceNow will deal with that. So you can advise them to spend the time working with a search in other ways. Experimenting with stop words can give you totally different amount of results, and also using synonyms will improve your hit rate, so-- using laptop, and computer, and so on. So both stop words and synonyms already have tables in ServiceNow where you can have a look at some demo data as well. So by saying that, let me conclude and say thank you for checking in. And I'm hoping to see you in the Hague this year. Have a chat with me, and let's talk about how search engines work and how to make your life better for you and your customer. Thank you. [MUSIC PLAYING]

Anders Figenschow 7x MVP

CMA · KPMG

Watch

CCB1116-K22

Integrations for fun and profit

## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Welcome to Integrations for Fun and Profit. My name is Eric Riemer. I'm the development team lead for the ServiceNow practice at New Access Innovations. We're a ServiceNow partner working exclusively in the federal government space. I'm also a 2021 and 2022 ServiceNow Developer MVP. I work on a lot of interesting projects, but that's not actually why we're here, to talk about me. In this session, we're going to integrate, have fun, and profit. More seriously, we're going to go through what integration is, build some examples, and give you some tools that you can go and learn more yourself. So first, what is an integration? Well, there are so many terms that people use, as if you should just know what they all are. And this long list is only a few of them. The good news, you don't need to actually know most of them to get started. Eventually, yeah, you're going to have to learn a lot of them. But up front, very few are actually going to be important. So we don't need to boil the ocean. And let's simplify things. So there's only two things that you really need to start off knowing. What is an integration? And that's when computers talk to other computers to exchange information or take actions. And yeah, that's a gross oversimplification. The second is, what is an API? It stands for Application Programming Interface, which you don't actually need to know. What you do need to know is that it is the agreed-upon ways for the computers to talk to each other. So let's look at some examples of how to do this. So there's two major buckets that all integrations fall into. The first one is inbound. That's when somebody else is going to talk to you, rather than you talking to them. So some examples of this is a SRAPI-- a Scripted REST API. It gives you total control. It's my favorite one to use. There's out-of-the-box APIs, like the Table API and the Import Set API. They're out of the box. They're there. You don't have to lift a finger for them to exist. And they're super well-documented. Finally, there's the Flow Designer API trigger. And this one is super low code. You don't have to know any code whatsoever to use it. It does have the caveat that it's asynchronous. So you can't return any data. Makes it not so useful if somebody says, hey, give me the details of this record. But it is potentially really useful for somebody wanting to insert a new record, if you want to do that. Now, no matter which one you choose, you can and should make use of the REST API Explorer for testing. You can find it by filtering the Left Nav or the All menu, if you're using the Next UI. And one of the bonuses, not only can you test it that way by setting all your parameters, but it'll even give you code snippets that you can then pass along to that third party developer of like, here is everything you need to talk to this API correctly, so that they're not stuck only searching through documentation. Especially if you made a scripted REST API or a Flow Designer API trigger, if you didn't write that documentation, it doesn't exist. But at least you can give them, without having to write anything, here's how to call my API. And here's the code in the language that you're using to do it. So now let's get into an example, Scripted REST API. There's going to be a bunch of code, but it's not that scary. So here's the quick tour of what we're going to be looking at here. OK, so the first is a URL to call this API. The part in green is ServiceNow provided. It's your instance URL slash API slash your company code. Every company has a unique code. Even PDIs have a company code. So if you're just playing with this in a personal developer instance, you totally can. The next part in orange are the name you gave the API, a question mark, and the parameter name that you defined. And finally, in white is the actual value that's going to be sent as a parameter. You can have a whole bunch of parameters. I'm keeping it simple and only having one. And I'm expecting to receive an incident number. And I'm going to return some details. So here's the rest of the code. Again, looks like a lot. Not actually as scary as it might look. So lines 3 and 4 are just to grab the parameters from that payload that got sent. And so in this case, it's saying, find the number of parameter. And we're going to just hang on to that for a second. And line 7, we're going to do a GlideRecord.get on that record. And if it exists, build a payload of information to return. Pretty straightforward stuff, even if you don't understand what the heck this payload is supposed to look like. It's a JSON object. Almost doesn't even matter, because you're returning it to somebody else who needs to be able to handle that. Line 20 sets the response body with that payload that you're sending to them. Line 21 is the HTTP status. Those are those weird codes that you see and hear about, like 404, page not found, and 500 error, and whatnot. In this case, it's a 200, which just means you did it. You're good. And that's going to be returned to them. Line 22 deals with the bad incident number. Somebody sends me a number that doesn't exist, I'm going to send them a 404 not found message and an error saying, you gave me a bad number. And just like that, I've built a Scripted REST API endpoint that I can then make, that somebody else can call. And then they can get the information that they need. Now, the second major bucket of integrations is outbound. That's where you're going to send a message out to a different system and either get some information back from it or have it take an action. You should know, there might be ServiceNow licensing implications, depending on your contract. Ask your ServiceNow sales rep, if you have any questions about that. Because every contract is different, and I have no idea what yours says. So the easiest way to do this is to use an existing Integration Hub Spoke. There's a whole lot of them. ServiceNow keeps on coming up with more of them. Low code. It's great to use. If one of those doesn't exist, you can also make your own spoke. It's not actually that hard, and we're going to do an example of that in just a few minutes here. And it's pretty simple. It's sometimes even no code to build an entire outbound message that you can then do stuff with. Next is REST Message. This is the pro code way to do it, where you're going to have to write a bunch of code. You need to understand more what you're doing. But it gives you far more control. It also lets you test it with example parameters and see if you're getting back the results that you expect or not. Finally, there's Recordless REST, which is even more pro code. It doesn't have a REST message record that you'd find in the navigator. It just exists in a business rule or something, and that's the only place it exists. Another downside of it is it limits reusability, because it only exists in that one place. So we already built an example of an inbound API. So let's talk about how to make an outbound one. So how do you get started with that? Well, go find the API documentation, and then you might panic a little bit. This is the ServiceNow documentation to use the table API to get the details of one single record. It's fairly representative of what good API documentation looks like. It looks really long and complicated, doesn't it? And it's only one simple-sounding use case for an API. So let's break this down as we build a custom action and Flow Designer so that we can make use of it. So in the interest of time, we're not going to go through every single painful step. But basically, you go to Flow Designer. You go to New, Action, give it a name. We defined an input and added a REST step. And that's where I'm going to jump to on the next slide. And we're going to go through side-by-side with the documentation and what we're doing within that custom action in order to build on it. So I'm doing this with the ServiceNow API documentation that I just showed you. But any API should have similar documentation. Some APIs have absolutely horrid documentation, and I can't help you with that. I'm sorry. You just have to suffer through it. So we're going to do a GET. That's why we set the HTTP method, because I want to get information back into my system. I also copied the URL format into the resource path. And all of those parts surrounded by curly brackets are variables that we're going to need to replace. So those are the path parameters that we're going to replace them with. To make a simple example, I'm hardcoding in the incident table. So this action will get the details of an incident. And then I use the data pill from my input for the sys ID that I want to retrieve the details for. I'm skipping over the connection details, because depending on what you're integrating with, there are a lot of different authentication methods. Everything from a very basic username and password, or sometimes even no authentication, to far more complicated things that are way outside the scope of what I can talk about here today. But there's a lot of good documentation out there when you're looking for specific information about different authentication methods. Next, we have the query parameters. In this case, I set two of them. If you don't set them, they might have default values. The documentation is going to let you know if they're required or optional, and if they're optional, what the default is going to be. Just like the path on my last slide, I can stick the variable pills here from my input or anywhere else in my action, if I want to automate setting those or let the user, when they run those action, define it. In this case, I'm telling it that I want to get all of the details about the fields that I'm asking for-- not just the display value. Not just the raw value, but I want both for each of them. And that I only want to get back the values of a certain subset of fields. I don't want all of them. I only care about a couple of fields. Next up, we have headers. Same thing applies about optional versus required headers as well as the default values. In this case, ServiceNow is saying, well, would you like the response to be JSON or XML? In this case, we're just leaving it blank. We don't even need to set anything, because we're happy with JSON. Different APIs are going to have sometimes more, sometimes fewer things that you can set as your query parameters, header, body. That's why there's documentation. It'll tell you what you need to be building and setting. So great news, we built the request. And now we have to deal with the response that comes back to us. So the docs tell us we're getting name-value pairs. And we already saw that it's JSON name-value pairs. So I added a JSON parser step. And in that step, I set the source data field to the response body data pill from the request. So we finish the request step. We grab the output of that, put it into basically the input of this JSON parser. And the API docs were nice enough to give us a sample payload. So I just copied and pasted that into the source side and click Generate Target. ServiceNow did a whole bunch of parsing magic, and I have data pills for everything that the response might have. Now, some of you are looking at this and furiously writing me hate mail, because you remember that just a few slides ago, I set parameters to only look at some of the fields and not all of them. Then you look more closely and say, hey, you said you were querying the incident table, and that payload says the location table. And those fields aren't the same at all. And you are absolutely correct. Well done. So example payloads might not match your exact use case. And sometimes, you have to make a real request to get back a payload that you can use as a sample that's going to match what you're actually doing. How do you get that payload? Well, you test your flow. And when you run the test, you can look at the execution details. And you can scroll down a little bit and unfold the steps and then click on the response body. And that's going to give you the raw response of the actual API call that you made. So the system didn't know what to do with it, but it captured that you got a response. So I opened that up, copied and pasted into my parser step, clicked on Generate, and now I have a real payload for my API call with the exact fields that are going to get returned, and all of the types and everything else that I need to use for it. At this point, I just need to set up my action outputs. And then I can use this action in any of my flows. It's going to ask me as an input, please give me a sys ID. I can look that up from an existing record, if I'm saving those somewhere, or however else I'm going to get that input information. And then it's going to output those data pills with those values that I asked for. And that's it. You just made an action that's going to call an API and bring back useful data. And then continue on with your flow, and you can reuse this over and over again. Now, I know I went through a lot of stuff. And where do you go from here? I made a GitHub repo with some links to additional resources, the code that I used in this presentation, and other stuff that's going to help you as supplemental things to all of this. You can also feel free to find me on the #sndevs Slack. It is a wonderful community of developers, admins, and other ServiceNow professionals. It is a great place to go get help with whatever you need, talk to people, make connections. And again, if you have questions about this presentation, feel free to hit me up there. Did you like this session? I'm going to be doing it live in Las Vegas, and I would love to see you there. Thank you for watching. I hope that you found this useful and that you have a great time at Knowledge 22.

Eric Riemer 3x MVP

Senior Product Excellence Manager · ServiceNow

Watch

CCB1117-K22

Stepping beyond the portal: Transitioning your skills to the Now Experience

## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Welcome to Stepping Beyond the Portal. I'm Travis Toulson. In this session, we're going to be discussing how to transition your skills from the Service Portal to the Now Experience. So first of all, I want to cover a couple of things that we're not going to be covering in this session. And that's going to be NodeJS, now-cli, Component Project Scaffolding. For help on any of these things on getting started, you can check out the developer site, where there's a URL at the bottom. And there's a fantastic guide to help you get started down that road. So first up, let's talk about the editor experience. And for this, we're going to compare some of the features and attributes between the Service Portal editor versus what we are now working with in the Now Experience Components. So with the Service Portal editor experience, we're all familiar with that three-panel layout. And of course, there's a couple of hidden panels we can switch in. Widget source code is stored in ServiceNow in HTML, CSS, and ES5. The source code is combined primarily in a single record with the sp_widget. There are a couple of other widgets off of that. But for the most part, it's all governed within that single widget. Of course, the editor is browser-based, unless you're using the VS Code plug-ins. And whenever you save changes, you immediately get that update in the instance. You can immediately reload the page and see your results. And of course, one of the key features of Service Portal is that your server code and your client code sits side by side in the same widget, so you can rapidly iterate and build out those widgets on both sides of the network. Now, the UI Component editor experience really changes the game on this. First of all, your components are now stored in source code, basically in local files and folders on your local dev environment, using JSX, SCSS, and ES6. The source code is spread across numerous files. It's no longer consolidated to just one record. And you can bring your own code editor, which I highly recommend VS Code. Those changes also have to be deployed to the ServiceNow instance. So you're actually developing on a local environment. And you'll see those changes in the local environment. But if you want anybody else to see those changes, you're going to have to deploy your component up to the ServiceNow instance. Also, the UI component only contains the client code. So there's no server code inside of these components. And that's a very big difference between the two. So where do I put this code? Well, in the Now Experience, we're working primarily with JavaScript files and SCSS files. So your ES6 modules, in the form of JavaScript files, basically equate to your HTML templates, your Angular ng-templates, and pretty much all of your client-side JavaScript code-- the link function, the client controller, instance options, your angular providers. Basically any of this client's JavaScript that you would have put in Service Portal in various records is now all going to go into JavaScript files. And your SCSS equivalent, basically you'll have an SCSS inside of your local dev environment. And you will import those SCSS modules into your JavaScript modules. So it is a little bit different from what we're used to dealing with. But for the most part, there's really strong equivalent to the SCSS fields and the CSS dependency tables in your service portal widget. And as I said, there really is no equivalent for the server-side JavaScript. Basically, you can use UI Builder data resources or REST endpoints with the HTTP effect. But you really won't have the actual server code stashed in your components. Your components are strictly client-side. Now, in terms of how this looks in your local development environment, on the left-hand side, I've got the File Explorer for VS Code as the sample project that I'm currently working with. And you can see that the ES6 modules and the SCSS modules all fall under that SRC folder. And you can see the index.js and the styles.scss, which is part of your boilerplate project. Now, you can add additional files, additional folders, import things in. You can get as wild and crazy with the folder structure and file structure as you want. And that's one of the key advantages, is you can build larger projects in a very structured way, as compared to what we used to be able to do in Service Portal. So let's take a look at a sample project. And let's start out with the HTML template. So you can see in the laptop on the side there the example of what we're going to be outputting with the code. And so the view typically is done in the HTML template in the Service Portal. But let's look at how we would accomplish this in a Now Experience component. So in the Now Experience component, you can see the code on the right-hand side. And basically, if you look at that orange bar, you'll see a view function. Now, this is using the ES6 arrow function syntax. But trust me, it's basically just a function. So the HTML templates are going to be written in JSX. You'll notice the HTML inside of that view function. Now, JSX is a syntax extension to JavaScript. It's not actually HTML. We're not returning HTML out. Officially, your returning JavaScript objects that represent DOM nodes. But that's a little complicated for this session. The important part is to note that it is not HTML. And it has more equivalence to calling JavaScript functions. It does get compiled to JavaScript functions. And each view function can only return a single top-level element. And the last thing that I'll note is the parentheses after the return statement and at the end there. Those parentheses are very important when you're dealing with multiple HTML nodes. So you absolutely have to have that. And it basically creates the expression. So now let's talk about data binding. So in this one, you'll notice that I've changed the message from Hello, World to Hello, Travis. So basically, how would we bind that dynamic data? Now, in Service Portal, we used one way binding. And that used the double curly brace syntax in the HTML template. So let's take a look at how that's going to be done now. Again, on the right-hand side, you'll see the code. And you'll see in the first orange bubble that there's a var name equals Travis. So we're setting up a local variable. And then on the second red bubble there, you'll see a single curly brace with that name variable inside of it. Basically, since views are just functions, we can declare variables in them the same way we would in any JavaScript function. And that little single curly brace syntax is part of the JSX expression that embeds-- or binds the data to that particular expression. So it's very similar to our double curly brace syntax from Service Portal. And that's going to make the transition really easy. Now typically, we're going to want to get that dynamic data from somewhere else. We're not just going to use a static variable name. So let's take a look at how we can pass some instance options and hold internal state. And basically, this is going to be functionally equivalent to passing instance options into your widgets. Now, the one thing I want to highlight, though, is that there is a bit of a difference. Because in Now Experience components, the properties are much more powerful and a much more prevalent part of components than what they were in Service Portal. So once again, the example is there on the right. And let's take a look at the code. So first of all, take a look at that second orange line down there, where it specifies the properties inside of that createCustomElement call. And you'll see that we've defined a property called name. So this whole scaffolding is setting up our Now Experience component. This is some of the boilerplate scaffolding that is required. And the properties are basically equivalent to instance options. That name property is then being passed in to the view function via the state property. And you'll see on that first orange bubble, the Hello, state.properties.name. So the properties are exposed via that state variable-- or that state parameter. And you can use this in any of your custom components. Any properties that you add in that createCustomElement syntax is going to be available inside the view. And those properties can be updated as we perform different events and actions. But that, basically, is how you are going to pass data into your components in order to expose them within your view. So since we mentioned events and changing that data, let's go ahead and talk about, where's the ng-click? Where are these events? So once again, you'll see on the right-hand side, I have an example view with a button that says Change Name. So instead of changing that manually to Hello, Travis, we're going to change it when we click that button. So instead of using the on-click handlers in Service Portal, you usually use ng-click. And there's a bunch of other events we can use. But the short of it is that that triggers a digest loop, which reprocesses the view and updates it for you. Components are a little bit more straightforward. So once again, we're going to be using that view function. Everything basically goes inside this view function. It makes things very easy. And instead of the ng magic, you're actually going to bind events using on, dash, eventname, Just like you would traditional HTML and JavaScript events. And what's really powerful about this is that it even works with custom events. So if you define custom JavaScript events, you can just use on dash whatever event name you created, and it still works. Basically, behind the scenes, that on dash is just instructing the Snabbdom renderer to call element.addEventListener, where you pass the event name. So it's just a declarative syntax for that. And it makes it really easy to bind any event. So you really don't have to memorize any special magic ng incantations to make it work. You just have to know your event name. And you can see in the updateProperties where we are-- or sorry, we're passing in the updateProperties on that first orange dashed as a co-effect. And then on-- and I'm not going to go too much into that particular topic. You can find more on that in the guides. But we're going to call that update properties in order to update the name parameter to World. And that way, when we click on that button, that on-click event will fire. What's really cool is that we're still just dealing with JavaScript. JSX is just JavaScript. There's nothing particularly fancy about it. So we can create event handler functions the same way that we would in vanilla JavaScript. And this is going to be roughly equivalent to your c.handle something in Service Portal, c.updateName. So if you look at the second orange dash there, you'll see the updateName handler being called in the on-click. And up on that first orange dash, you'll see the updateName function being created. And because it's done within the view function, it has access to the updateProperties co-effect that we passed into the view function. All of this is handled by the Snabbdom renderer and by the overall Now Experience framework. So you just have to plug-in the right pieces in the right places. And the rest just fires and works. And of course, you'll also note that we're still using that curly brace syntax. Basically, any kind of dynamic binding that you will use will be done using the curly brace syntax, which makes it really easy to remember. Now, of course, no component is complete without a little bit of conditional logic. And of course, in Service Portal, we had ng-if ng-show, ng-hide, ng-switch. We had a lot of magical directives that we had to memorize in order to set up some of these conditional statements and some of these conditional templates that show and hide the view. So basically, in this one, when we click the button, we're actually going to hide that button. And once again, we're just using pure JavaScript here. So you'll see that, on the second dash there, the second orange dash, we call a getButtonTemplate function, where we pass the state parameter in. And then you'll see in that first long orange line, you'll see the getButtonTemplate that passes in the state. Now, the important part there is the if statement inside of that template function. So if state.properties.name name is not equal to World, then we will return that button template. So this is how we set up a conditional template inside of our view function. And you'll notice it's just plain JavaScript. It's just an if statement. This will work with switch statements. This will work with ternary statements. So basically, it's just JavaScript. And that really simplifies the learning curve on this. Because once you get a handle on the view functions and some of the magical bindings in the createCustomElement, you're really free to write those components how you want. You're not constrained to the magical directives that AngularJS offers. And also, I'll point out that you can separate the view functions. So you'll notice that I don't have all the HTML in one place. I can call functions to get other fragments of HTML out of it. And this is a really powerful capability. We can also move those functions off to other ES6 modules, which is really going to help us clean up our code and make it very compact and very well-structured. So then we've got lists. Of course, most of what we're dealing with is repeating over a list, repeating the same template over lists. In Service Portal, this is done with ng-repeat to loop over iterable objects like arrays. Once again, components have no problem leveraging pure JavaScript to accomplish this. So in the component, you'll see, first of all, that I'm passing in properties. I'm passing in an array as the default, with five items. And then in the first orange dash, you'll see my little ul tag there with state.properties.items.map. Yeah, it's just JavaScript, array.map function. So we're going to iterate over the array using plain JavaScript. And we will return the list item template that represent each item. So the map function is going to be similar to for each, except that it returns a new array, where each new item in that array is the result of the original item passed to the map function. I'm going to leave it to you guys to go look that one up in a little more detail because I don't have a clear demo of that one for this presentation. But suffice it to say, it works just like for each, except that it creates a new array using the function that you pass it. In this case, we're returning to LI tags that contains the item name. Similar to conditionals, we can separate that template fragment out into its own named function, like the getListItem one that you now see in the code section. And this can make templates much easier to read. And again, we can separate that off into separate files to get a very well-structured project out of it. And of course, we're just getting started with this. There's so much more to add. There's actions. There's life cycle. There's hooks and behaviors. There's a lot of stuff that we haven't really covered today. This is really just a foundation to give you those basic ng-ifs, ng-repeats, how to get data in and out of your components. But for more, you can go to the developer website, where there's a really good introduction, getting started guide, for building out these Now Experience components. But this should really help you get started on your journey in transitioning your skills from the Service Portal to the Now Experience framework. So with that, if you have any questions, you can feel free to reach out to me. My email is [email protected]. Or you can head to the codecreative.io website. Thank you very much. [MUSIC PLAYING]

Travis Toulson 7x MVP The Toulsons - Portal Explorers

Sr. Developer Advocate · ServiceNow

Watch

CCB1118-K22

007 A bond strategy to enable citizen development

## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello, everyone. Welcome to Knowledge 2022. You're watching a brief session titled 007, A Bond Strategy for Citizen Development. In this brief session, we will give you an eagle-eye view of citizenship development methodology. By the end of the session, our main aim is to push the idea that is innovation is not invention. Also, improvement or automation of current processes has better return on investment. I am Ashutosh Munot. I am a certified ServiceNow Technical Architect and two times Dev MVP, four times Community MVP. Currently, I'm working with an end group in Netherlands as a ServiceNow architect. I'm accompanied by another Dev MVP and a good friend of mine. Dhruv, please introduce yourself. Hi, everyone. My name is Dhruv Gupta. And as Ashutosh mentioned, I am also a ServiceNow Developer MVP. And I currently work as a ServiceNow Architect at Accenture. We are pretty excited for two decisions, so let's start with the agenda. So today, we'll begin with an exploration of citizen development. What is it? Why use it? What are the advantages of using it on the platform of platforms that is ServiceNow for citizen development. Once you are settled with the theoretical aspect of the program, then we'll share our experiences, the challenges we faced, and most importantly, the mitigation strategy along with some key learnings. And finally, there are resources you can utilize along the journey of your citizen development program. So if that sounds interesting, Ashutosh, please guide us through why citizen development is important. Oh, that's a very broad question. And every new initiative starts with a problem, so let's start with the problem. I will summarize this with some numbers. Basically, need for citizen development can be broken into two things-- business challenges and IT challenges. Let's first read the mind of business leaders. As per the research by Mendix, it says 50% of business feel that they are unable to meet their key strategic goals. And then, almost same amount of business leaders find it hard to grab the opportunity of cost reduction, or I should say, scope of improvements. And the usual culprit behind this are IT challenges. Let's see not-so-shocking numbers. When we say not-so-shocking numbers, that means we have experienced this personally, where 77% of tech leaders think that they are struggling because the pipeline is too huge, and stakeholders tend to go away from the requirement over the period of the time. And to cater to those needs, we end up having external parties for our rescue so that they can help us to reduce the pipeline. If you see, 77% of business leaders think that it's very hard in today's era to reduce the cost because of the huge pipeline. Hence, it is very hard to neglect also. These are my thoughts. What do you think, Dhruv? Definitely, these numbers are not shocking for me as well. The reason that I want to highlight is that we always tend to ignore our internal resources who can be a better fit in our IT ecosystem because they're aware of the ecosystem. They know the ecosystem. They know the actual crux of the problem. B, they tend to be less costly-- I should say that-- than if you go for a specialist role. For some domains, you need specialization but not for all. You can cross-train or develop the culture of citizen development. That was an interesting point, Dhruv. So please tell us what exactly citizen development is all about. Sure, man. Citizen development is a business process that encourages non-IT trained employees to become software developers using, how should I say this, IT sanctioned low-code/no-code platform to create business applications. This approach to software development enable employees despite their lack of formal education in coding to become citizen developers. That was the official definition. But in layman's terms, citizen development is basically a process of identifying your citizen developers that can optimize and solve bottlenecks for you using a local platform. So Ashutosh, I know you have an experience on identifying citizen developers, so tell us who is a good citizen developer as per your. Oh, a citizen developer can be anyone within the organization-- a non-developer or a non-IT guy. So basically, our stakeholders can be also citizen developers who can tap into low-code platform to build a specific business application. Since they are facing problems on day-to-day basis, their response is more agile towards the problem, and they can build the app quickly, and they are very quick to the dynamic business landscape. So citizen developers are different from traditional developers. How? You can see on the screen, there are some differences between both developers. So I would say, citizen developers are empowered business users who create new or change existing business applications without the need to involve IT department. So please take a pause and read this slide for a minute so that you understand the difference between citizen developer and the traditional developer. Thanks. Dhruv, you have been an advocate for ServiceNow, especially for citizen development. Why is that so? Please tell us. Yeah, man, I have been recommending ServiceNow, especially for citizen developer and because ServiceNow has literally almost everything that you need for developing an app that run a low-code/no-code approach. And it is scalable. And you can go and ask for your compliances as well-- what else you want. I can talk about this whole day. But in the interest of time, I'll just highlight a few capabilities but the platform has made most of. To begin with, first one is your Flow Designer. This is the main contributor to low-code/no-code functionality, where NLU plays an important role. The drag-and-drop feature in Flow Designer requires no coding and makes it easy for new developers to understand it quickly. Second one is your Integration Hub-- major player to automate things with 200-plus [INAUDIBLE] available out of the box. Automation is the key aspect of why people want to go for citizen development. This is because they want to handle their own pipeline and catalog forms which can automate their tasks quickly. Next one is App Engine Studio. It's a development tool for creators of varying skill levels to build applications that meet immediate needs of your organization. Next one-- my favorite-- UI Builder, a platform for designing and engaging UI experience. Its capability grows exponentially with the level of skill set our developer has. But it definitely caters to more than what is required. Apart from this, we have low code capabilities like virtual agent, machine learning, process optimization, et cetera, et cetera. So it's basically enhanced the arsenal for developer. You can find more details about them in the Resource section. So in short, in short, ServiceNow and citizen development is a perfect match for my site. Great, Dhruv. So this was all about the theoretical knowledge for citizen development, who are citizen developers. Let's deep dive into practicality now. We started our journey a couple of years ago, and we stumbled onto various issues out of which we have got some must do to, make the process moot and extract the best return on investment from the platform. First of all, choose the right use case-- that is those can be developed with no or very less involvement of IT resources. Citizen development is very exciting. And because of that, we end up trying to involve or overdo a few things. Basically, identification of resources and setting up guardrails-- that is governance-- along with their initial trainings are the key to success. We need to understand it's a journey. It's not a one-time affair. So don't do a big code life or onboarding of the teams. But start with a small team and then build upon it. Sharing your success story is equally important because it acts as a catalyst to motivate other team members and citizen developers within the organization. Having the right tool does not always solve all the problems. You always need a right approach along with the right tool to get maximum return on investment. So Dhruv, please enlighten us with the recommended path for this. Yeah, as you mentioned, it's a journey. It's definitely a journey. It's not one-step process or one big goal life. I usually divided into four steps. Step one, prepare the environment and culture. When we say, put on the guardrails, we mean to clearly state what is expected from citizen developers and what they are not allowed to do. And the next step is the enablement of the team. Based on your organization's vision, set up a training plan for citizen developers. And in that training, don't forget to include some challenging activities. And once someone gets the basic skill set, I usually recommend-- or this is something that has been beneficial for us as well-- give them an instance to sharpen their skill set. They can use their PDAs as well. But give them an instance before putting them into some project work. It would be most important for their confidence. And now, it's time for bringing them into the mainstream, assign requirements to allow them to take responsibility. Make sure your IT team is there to help them out but not building on their own. And finally, it's time to scale up. We use the components as it's built. And don't forget to share the success of this journey. By the end, you will realize that you simply use your employee to build something that is cost-effective, quick, and, most importantly, it empowered your employee. Great. Thanks, Dhruv, for showing us the path. Now, as we are approaching the end of the presentation, let's take a moment to summarize some key takeaways of the presentation. If you remember, we had an issue of use pipeline, and we also saw how to solve it. And the answer is citizen development, which is the need of an hour. Also, we saw how ServiceNow will act as a tool or act as a solution to help implement citizen development and how it can help you to bring maximum return on investment. Also, change enablement governance is very important to explain the importance of citizen development and how ServiceNow can cater to this. On your screen, you can see one QR code. It will take you to one of the community articles that we created for this session. It contains link for all the articles that we read while doing this research, while setting up this session, and all the recommended webinar sessions-- whatever we want to pass on. Also, can use this article to put on your queries, and we would love to answer them. Thank you for patience. We look forward to interact with you all. Keep learning, and enjoy Knowledge 2022. [MUSIC PLAYING]

Ashutosh Munot 12x MVP

EMEA Delivery Director · NewRocket B.V.

Dhruv Gupta 7x MVP

Lead - AI Control Tower · NN Group

Watch

CCB1119-K22

Automate provisioning and entitle users in three minutes with Integration Hub Spokes

## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello, everyone. Today we'll be talking about automating provisioning and entitling users in three minutes using integration hub spokes. So to start off with the introduction, I am myself, Ishaan Shoor. I'm a senior technical consultant working with a ServiceNow partner, Thirdera And my primary function is ServiceNow development and consultation. I've got around four years of experience in ServiceNow and seven years experience in software development and IT. My favorite part of ServiceNow is working with integrations, orchestrations, custom applications. And that is why we are here. So again, the topic relates to integration of our Flow Designer. So in today's agenda we'll be covering the following topics. We'll be going through the overview, process flow diagram, use cases, benefits, key highlights, and demo. So I'll start off with the overview. So overview-- we, as every organization, uses Active Directory and Azure AD. but the provisioning in the Active Directory and Azure AD is pretty much limited to provisioning of the users or de-provisioning of the users. But there are a lot of other activities that take place around this, which is giving users access to a particular group, a particular application, having some shared mailboxes, some distribution list, and updating some user details-- might be a phone number, might be a second name, first name. It can be anything-- or just starting an email alias to a user. So a lot of other activities are involved, but they are all manual activities that the team do while the-- they get a request, and they get those requests as a manual-- using manual intervention. So using ServiceNow platform, we can automate all these tasks. And we can fully cater these identity management requests. So this automation can be done in two ways again. So the first one is having a third-party software and ServiceNow as a middleware and having connections with AD, Active Directory, and Azure Active Directory and leveraging the integration of spokes and the Flow Designer. The second one can be where we don't have a third-party tool, and we go to the Forms Automation. So, we'll be covering Forms Automation in this demo, as I don't have a third-party tool with myself. So this is a process flow diagram. This pretty much covers all the use cases that we were discussing in the last slide. So as you can see here, there can be some third-party systems involved in this process, where we have got a third-party system, like Workday, SuccessFactors, which generate an event and create a request in the Microsoft product. And again, Microsoft is Active Directory and Azure Active Directory. And from these, the request goes further down to ServiceNow. And then we have got some capabilities to enrich the accounts through ServiceNow, add the users to a particular group, or we can also notify the account details to the manager. So this is one process. And the second one is we don't need the Microsoft works in the middle. So we can also have a direct connection with the third-party tools and ServiceNow. And then we can go around with the enrichment of the user accounts, adding the users to the group, and a number of use cases that we have there. And there's a third step, where we don't have a third-party tool. We don't have any requests coming in through the Microsoft products. We have got ServiceNow just acting by itself, where we can use the service catalog, the ServiceNow forms. We can automate those forms to fulfill these active user account requests or updating some user account, adding users to group, application access, remote network access, employee onboarding/offboarding. So this is where ServiceNow comes into the picture. And we have got all the capabilities to pretty much get a lot of flavors of employee profiles sorted just by using ServiceNow automation. So this pretty much wraps up the process flow diagram. I'll move over to the next slide. Again, I've been [INAUDIBLE] it all over. So for some possible use cases that we have here is updating my cell phone number, updating group membership, user account creation, creating a new shared mailbox, creating a distribution list, rehiring an employee, offboarding an employee. And there can be plenty of use cases that we have here. Now, some of the benefits that we have realized over time-- so I have worked with a lot of similar projects. And plenty of clients are moving towards the ServiceNow or are involving ServiceNow automation in their onboarding/offboarding and user update requests. So basically they are doing this to reduce the manual intervention and fully cater the identity management requests. So what happens when this manual intervention is removed? So in turn they also remove the errors, so reduce errors in processing. Also, dependencies are removed of in-house legacy automation scripts. So these scripts are basically which the AD team or the Exchange team or Active Directory team is having in their systems. So those dependencies are also removed. After all this, the biggest factor is a quick turnaround time. So we'll be coming to that. I'll be circling back to that later in the slides. But the turnaround time is the biggest change that we have here-- reducing the errors, no manual intervention, and also a quick turnaround time. Moving on to some key highlights-- OK. So some of the key highlights here, a number of employee profiles can be digitized. So, as we have got, we can create a user account. We can add users to the group. So many times we just, if we want to give a user access to an application, maybe Workday, we are creating an HR profile. We can simply add that user into the Workday group, and other automation will take place around it. And we have set up a HR profile. And similarly, we can set up a service desk profile, where we are adding user to a service desk group in the Azure AD. So there are a number of levels that we can set up using the ServiceNow platform. And a request form can be configured and automated. And again, this all can be done through the service request form that we have been using all around, all the time. And the design is future proof, configuration friendly, and robust. So why this is the case? Because ServiceNow is highly moving towards Flow Designer. It's promoting Flow Designer and the use of it because it's easy to use, it's user friendly, and in terms of the debugging of the logs and everything are pretty straightforward, if you can just read and see what they show is. And every six months, we are getting an upgrade for ServiceNow, which is again a plus point. We don't have to worry about anything. So there is no technical depth. So if we are having some kind of custom integration, it is on us improving and maintaining the code. But here we don't have to worry about it. So automatically everything is getting upgraded. It's getting better every day. And the biggest point that we have here is the average fulfillment time. As I was just speaking in the last slide, it gets reduced to around three minutes from around 24 hours. And again, these 24 hours can be even more so, if we have got some approvals and they are just sitting there to be approved. And once they are approved, they might take a couple of more days to fulfill those requests. So in those terms, this time can be even more. But when we are using this automation, once the request is approved it just goes in and it's done within a few minutes. So this is a drastic change. And also, the return on investment on this one-- like, if you are having a manual employee sitting there fulfilling these requests, you can get a big turnaround, maybe save a-- so one of our clients had emailed me that they were saving of a full-time employee using this automation. So they were saving a lot on that one. So these are some of the key highlights. And where this can be applied to? So this can be applied to HR systems, as we have already seen in the process flow diagram, some HR systems where we want to automate the identity management requests and also streamline the requests by removing manual intervention errors and unstructured time-consuming processes, also customers who want to transform manual processes into self-service forms automated by ServiceNow workflows. So these are some of the places it can be applied. So before we go off to the demo, we have got some prerequisites that we need for this automation to happen. So first of all, we need a ServiceNow instance with the Integration Hub subscription. The second thing that we need on the instance is we need to install a Microsoft Azure Active Directory Spoke. Again, this can be different for different use cases. But the demo that we are going through today, we'll be using the Azure Active Directory Spoke. And also we need access to the Azure Portal and also the credentials to build a connection between ServiceNow and Azure. So I have got my ServiceNow instance with me. And I have already sorted out the connection between the Azure Portal and ServiceNow. So that's all good. So what I'll be doing the first thing, I will be raising a request for a new user account. And this user account is a fully automated form that we have. And once this form is submitted, it will go ahead and create a user for which we are requesting in the Azure Active Directory. So let's start off. No problem. Now look for-- we'll put 567. And we don't need to worry about the comments. We need to press Submit. So now, once this request is submitted, if I click on it, and as you can see, just within a minute it has actually gone to complete. So if I go to Azure and go to the users, we do have that user created here. So Tom Molly-- and we have got the job title. We also do have the phone number that we have entered. And that's how quick it is. And also, I have got the user provisioning setup from Azure to ServiceNow again. So I think every 30 minutes the users are synced back to ServiceNow. So all the new users that come in are also going back to ServiceNow at the users. So we are also provisioning a ServiceNow application for those users. Now, if I go to the back and backend of this one and check with the executions, so this is the flow that was executed in the catalog item was requested. We updated the record. And Work notes has request-- work in progress. We get catalog variables. So this is a custom action that I've created. I'm building out the account name and password for the user using this. So it's a basic script action that we have, which takes the first name and the last name of the user and generates an account name with first letter and the last name of the user and also gives out a generated password text. Now, once I've got this, I'm again updating the record with the account name-- the requested item record with the account name of the user that we get out of that action. [INAUDIBLE] the next action that I'm executing is create a user. So I am almost setting every attribute that's required for the user. So I'm setting the account enable to True so that the account is enabled for the user, and he is able to log in. So display name is set up through the catalog item, first name, last name, user IDs. We have got it from the previous step [INAUDIBLE].. So this is a servicewow.onmicrosoft.com. So this is my application on the Azure. And we have also got the email alias as Tom Molly. And we've also got the password. So we are also changing force change password for the user. We can set it to False as well. And we also got the other attributes, given name, surname. We've got the phone number, job title. We can set a lot of other attributes, but for this demo I've just used some of them. And once it has success, it gives out a user ID as the output. Now, once this is done, I'm also sending out an email to the manager, so Adam Haro. I'm sending out this email. If I go to the email logs, we should be able to see that there. OK. Let's look. I'll go back to the email in a bit. And, yep. At the end I am marking the request as complete. OK. Yep. So we have got the email there. So, Hi Adam. The account details of the new user request, RITM-- full name this, network account name, and username, and the password. And the manager can, further down, share these credentials with the user to log in. And, yep, post that, we are just marked the request as complete. So once this is completed, it's all good. We're done. We're done within, I think, less than three minutes or so. It was completed. And just in case if something goes wrong, I am also having a error handler, where I'm creating an incident and assigning it to a team, to action, just in case if anything goes wrong, to look at the logs and see what has gone wrong. And they can reticket the flow or the request for that particular user. And, yep, I think that's quite magic. And also just one more thing-- this was just a create user. Again, if I search my Azure, we have got around 39 actions with us. We can look up user stream. We can add users to group, reset user password, disable user, and delete a user, and also update a user, create a user, enable a user. So there are a number of use cases that we can get at. So it's just a small thing that I showed you. But there are a lot of possibilities around this. Thank you, everyone. Thank you for your time. If there are any questions, do reach out to me or my email address, LinkedIn, Twitter, SN Devs, Slack. And Flow Designer is the way to be. So I have been using it since 2018, and I think it's just awesome. And there are a lot of other spokes that we have outside of this use case, Azure AD and Active Directory, that can just do brilliant stuff. And it can be done in hours. So that's also an amazing thing. And thank you. [MUSIC PLAYING]

Ishaan Shoor 5x MVP

## 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]

Arnoud Kooi The Toolmaker

Founder & Creator · SN Utils B.V.

Fred Luddy Fred the Founder

Jenny

Watch

CCB1128-K22

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]

Maria Gabriela Ochoa Perez Waechter

ServiceNow developer MVP · ServiceNow

Jesalyn

ServiceNow developer

Watch

CCB1129-K22

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]

Jarod Mundt 3x MVP

Vice President of Engineering · Clear Skye

Watch

CCB1130-K22

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]

Sharon Barnes 4x MVP

Sr Outbound Product Manager · ServiceNow

Watch

CCB1131-K22

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]

Dave Atwood

Solution Architect · Cummins, Inc.

Watch

CCB1132-K22

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]

Philip Swann 6x MVP

Head of Technical Consulting · Wrangu BV

Watch

CCB1134-K22

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]

Sarah Toulson 5x MVP The Toulsons - Portal Explorers

Principal Platform Architect - Federal · ServiceNow

Watch

CCB1135-K22

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]

Chandra Sekhar Maganty

Senior Associate · PwC India Acceleration Center

Professor

Berlin

Tokyo

Watch

CCB1136-K22

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.

Sai Srikanth

Design Lead · Kaptius

Watch

CCB1138-K22

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]