Paige Duffey
Principal Product Success Manager
Paige has been working with ServiceNow since the early days with over 13 years of experience on the platform. During that time, she worked for several customers as a developer, an architect, and a product owner. She is passionate about pushing the platform beyond the norm to deliver value to teams that are often overlooked in the technology space and creating opportunities for non-developers to take advantage of the low-code/no-code offerings within ServiceNow. She is also a co-founder and a contributor to womennow.sn, which was created to provide a spotlight for women in the community.
Recent News
View all
App Collaboration - Creating Custom Descriptors
New article articles in ServiceNow Community
·
about 1 year
Application deployment: AEMC managing it all by configuring the pipeline
DD
Designing Apps: A practical guide to thinking like a developer
Panel: 15 percent and fearless: A discussion among developers that happen to be women
ST
Citizen Developer 101 - Unleash the citizen developer hero in your organization
MT
Citizen Development-Themes of a Successful Citizen Development Program
Citizen Development-Understand the Foundational Elements
Citizen Development-Define a Clear Value Proposition
Conference Sessions
Revolutionize your versioning upgrades
CCB1123-K22
## Transcript X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:0 [MUSIC PLAYING] Hello. Thank you for joining me today to talk a little bit about how to revolutionize your versioning upgrade. I am Paige Duffey. I have 12 years of experience developing on and supporting ServiceNow. I've worked in the capacity of a senior developer, product owner, and process developer. So why should you listen to me about upgrades? In that 12 years of experience, I have run dozens of upgrades for various customers, and then in the last five years, I have successfully run twice yearly upgrades for a customer who was in minus 1. Today, we're going to talk a little bit about the problems that I found during the upgrades I've have done then some solutions that have put in place over time to try and solve those problems. And then ultimately, an app that I built to try and help solve all of those problems in a nice single solution. Just to be clear, this presentation will not be covering the overall upgrade process. So first, the problems with upgrades. A lot of my issues with upgrades came around tracking. I needed to track a lot of information, and it was sometimes difficult to do. I wanted to track the testers, the areas to test, testing compliance. Ongoing defects and incidents after the upgrade, and then I needed a way to effectively communicate out all of that necessary information to my stakeholders. And then lastly, providing relevant resources in a way that was easy for them to access. Over time, I built up several not so great solutions. They worked for the time, but they all had their problems. One of the first things was trying to track the testers. So I would create a bunch of scrum tasks off of a story. That story was for UA testing for Rome. We would create those testing tasks for each individual tester and then they would go in and complete them. And while this worked, there was a lot of manual work that had to go into that. So after each upgrade, I had to manually load the data. I would export it, make the changes that needed to be changed, and then re-import it. So not only was that time consuming, but it also made it really difficult track those testers over time. So if someone changed in between upgrades, even if they let us know, I'd rarely remember when the upgrade came around again that person needed to be changed out. Secondly, in order to provide all of that information to our stakeholders, I did create a dashboard. And while, again, it served a need, there was a lot of manual effort that had to go into that. It provided those resources, but for each and every upgrade, I was going in and making a lot of manual changes to it. And then on top of that, there were some reports that were developed for that to track things like defects, and because there was no easy way to connect those records back to the upgrade, the best I could do was update the reports each time to look for keywords like Quebec, and that was always somewhat unreliable. And then lastly, there was a lot of stuff that was being tracked within the changes and the releases, but it was all being done manually free text in things like work notes. There was never a single place to store it, so oftentimes, you have to go hunt it down. Where did Paige put the ServiceNow change record this time? Was it in the release? Was it in the chain? Was it in the work note somewhere? We did take advantage of releases and ServiceNow, so every story was associated to a release, and those releases were associated to the change, so that was one easy way at least to track everything that was going into that upgrade. And then manually built out release notes for every single upgrade. But I wanted a better solution. So about a year ago, I started thinking through how we could do that better. I tried a lot of different things. I tried project management. I tried changing how we were doing it in Agile, and none of it really worked for me. So eventually, I just decided to go ahead and create an app. And what I needed this app to do was house the version versioning information, including like the release notes from ServiceNow. I needed it to track the upgrade dates which included things like the go live date, backup go live date, and testing completion dates. I needed it to house our internal release notes, our internal change release records, and then a place for the external ServiceNow chain record. I also needed it to help me manage the testing better. So I wanted to manage all the different testing areas. I wanted to be able to associate an individual tester with those testing areas, and then I wanted to get rid of that manual process and automatically generate those testing tasks, and then lastly, of course, being able to track the completion rate of those tasks. And then lastly, I wanted to be able to associate other records with my upgrade. So no longer did I want to have to look for keyword. I wanted to be able to look at a single field and go, this is all associated to the Rome upgrade, and then automatically build up the release notes. So this was the design I came up with for the app. Each box represents an individual table. This is what worked for me. Obviously, if you were to go build something like this yourself, you could do it a little bit differently. You probably don't necessarily need five tables. You could put a lot of the versioning information on the upgrade table. Maybe you want to use something like test management instead of building out your own testing tasks, but this is what worked for me in the environment I was in. And it's the versioning table that contains all the information on the actual version. The upgrade table, which will contain all of the other relevant information around the upgrade, testing areas and testers, which are associated and then all that comes together to create the testing tasks. So next, we'll look through what those records look like. This is the versioning record. Like I said, it contains basic information about the version. I did-- when I developed this-- try and make it something that could be used for other products. If it was successful. Maybe there were other products that had the same struggles that I did, which is why you see the field for product. Additionally, it's got the release date and then the version information, as well as a link to the documentation. Next is the upgrade record. This really holds a lot of the need of what I was looking for. It references back to the versioning record. It has a state field so I could track that upgrade from planning to testing to the free state between testing and actually doing the upgrade and then completion. It house the go live and backup go live dates, the testing completion dates, and then towards the bottom, obviously, you can see where it relates to all of those other records that I wanted. The change record, the release record, and then some internal KPs. And then lastly, the ServiceNow change record. Next, we're the testing areas and the testers tables. So these are two very simple tables, but they were just a really easy way to track that information. So it's a table that just contains all the different testing areas that this organization wanted to test against. So change management incident management compliance things of that nature. And then the actual testers table associates a person to the testing area, and then because it was done this way, you could associate multiple testers to a single area or a single tester to multiple areas so that they could track that they had tested each area that they wanted to sign off on. And then next was the part I was most excited about, which was getting rid of that manual task to create all of the upgrade tasks. I created a UI action, and that UI action would go and query the testers table and then generate all the testing tasks that were necessary for that grade and make all the appropriate associations within those tasks. So it would associate it back to the testing area to the upgrade, assign it automatically to the person and let them know that they've been assigned to it. And then there were fields for test results in the state. So you could easily report on what had been completed and what hadn't been completed, who had done their testing tasks, and who we were still waiting on. Next, this is actually a picture of the old dashboard. I did want to go through that real quick and just show you what that looked like. And while it was very, very useful really, really, really get into how much of that was manual. So this is what we provided our stakeholders, and while all of it was incredibly useful, prior to every single upgrade, I had to go manually make all of these changes. I went in and changed it from Paris to Rome, changed the dates manually, updated the links to the proper release notes, went in and manually changed the reports to search for those new keywords. Went into the user acceptance testing reports and changed all of it to point to the now new story for the test. And that was something that I did every single upgrade. But with my app, I created a new workspace and with that I created its own dashboard, and I was able to automate all of that. So I created a single place to store all of the relevant information for the upgrades, and because of that, I was able to automate all of these manual tasks that I used to do. So now, whichever upgrade is marked as the current upgrade will determine what all is shown on the screen. So I don't have to go in and update all of those dates within the dashboard. I just create the upgrade record and market is current, and it automatically does this. Even things like the release notes link is automatically grabbed from the versioning record. I'm not doing anything else other than just filling out a couple of forms. And then because it's so much easier, it actually allowed me to pass that on to other people to allow them to do it. I wasn't trying to explain this complicated process of exporting things and importing things and go to the dashboard and change all of these records. All I had to do was go fill out forms. So what I really hope that everyone gets out of this is that, while it is a really simplistic app, I think it shows the power behind even the simple apps and the value they can bring. It brought a lot of value to me into the team that I was on, because we were able to cut out some of the manual work that we were doing. So it's really easy for us as developers to get caught up in what we can do for everyone else and not take the time and effort to improve our own workflows. So I invite everyone listening to this to spend some time on yourselves and improving your own internal processes. And by doing so, I think you'll see that you save your time a little. You save yourself a little time and a whole lot of sanity. Lastly, thank you so much for joining me today. Feel free to contact me. My email address is paige.duffey@servicenow.com. You can also usually reach me on SNDevs Slack. My name on there is just Paige, and then lastly, be sure to check out the women now blog. There's some excellent content out there. [MUSIC PLAYING]
Application deployment: AEMC managing it all by configuring the pipeline
CCL1195
<p>Development to production via a pipeline for app engine studio apps, and how to get away from Update sets for Citizen developers. This includes an overview of app intake, collaboration requests and deployment requests. As this will give you everything you need to understand and get an app deployed using the AEMC pipeline.</p>
Designing Apps: A practical guide to thinking like a developer
CCL1187
<p>This lab focuses on guiding you through the practical aspects of designing and building Applications within the ServiceNow<span style="font-size: 12.0pt;"><span style="">®</span></span> platform while employing leading practices. Engage in interactive exercises to develop an in-depth understanding of the App creation process, from conceptualization to implementation, using hands-on experience and real-world scenarios. Walk away from this session armed with the knowledge and tools you need to build robust applications.</p>
Panel: 15 percent and fearless: A discussion among developers that happen to be women
CCB1225-K23
<p>It is well-known that the tech industry lacks gender diversity, and the ServiceNow ecosystem is no exception, with women representing a mere 15% of the ServiceNow<span style="font-size: 12.0pt;"><span style="font-family: Calibri , sans-serif;">®</span></span> community. Why is this the case? What barriers do women face that discourage them from pursuing a career as a ServiceNow developer? Join developers and administrators, who happen to be women, as we discuss the everyday challenges we encounter in the field, explore some of the hurdles we've faced and how we are able to overcome them. Find a community of women around you to share your experiences with and grow with.</p>
Citizen Developer 101 - Unleash the citizen developer hero in your organization
SES1656-K23
<p>At the end of this 60-minute workshop, you'll learn how to get started with a Citizen Developer program for your org with ServiceNow®. We will dispel common myths about Citizen Development programs and participants will have tangible examples of what strong Citizen Development looks like while learning about the differences in No, Low, and Pro Code tooling.</p>
Turn words into action with the art of Prompt Engineering
CCL1553
Dive into the fascinating world of prompt engineering and discover how it acts as the vital bridge between user intentions and AI capabilities. In this lab, we will use the Now Assist Skill Kit to build custom prompts as we explore why even the most advanced AI models can fall short without precise and thoughtful prompting.
One studio to rule them all: Unified development in ServiceNow Studio
CCL1545
Embark on a development journey in ServiceNow Studio to create the "Shire Rest and Relaxation Planner." This lab showcases the power of a unified developer experience, enabling seamless app development across multiple scopes and builders. Design an employee wellness app inspired by the tranquil Shire life, offering users the ability to schedule second breakfasts, plan walking challenges across Middle Earth, and form Fellowships to support wellness goals. Explore the new unified interface, where all development needs are integrated for a truly cohesive and engaging adventure.