Duke: Woo hoo.
One week, two recordings
CJ: Duke man, we are on a roll man.
We are back
Duke: helps when you get a day off, though.
It really does.
CJ: man.
Seriously.
Duke: So we've ever recorded at 11 in the morning
CJ: N sh.
Maybe during the pandemic,
Duke: maybe.
Yeah.
Alright.
What are we talking about today?
CJ: All right, duke.
Today we're talking about the anatomy of an app.
Duke: Yeah, so it's all stuff we've talked about before on CJ and the Duke, but
every once in a while it's good just to like jot down your high level knowledge
of things at least inspired it for me on my side is, I work at ServiceNow.
I help build release ops, which is our awesome new tool that helps you
push more stuff, more often of higher quality with greater confidence.
And in my,
I'm not saying I built it, I said I helped build it.
They gave me the really tiny, pieces and, somebody else created the big bad stuff.
CJ: Uh.
Duke: But it kind of made me think again, if we forget for a moment how we get
this thing from Dev to test, to prod.
how do you build a comprehensive, successful, long lived,
awesome thing on ServiceNow?
CJ: Man, you put a lot of adjectives in that.
Duke: Well, everybody's, built good apps, and I would argue that people have built
good apps that lasted not very long.
You know what I mean?
It just didn't hit the mark.
Right?
Everybody's built something awful.
CJ: Oh, every single day.
Duke: Yeah.
Or at least,, maybe that's a little bit broad, but
everybody seems something awful.
CJ: No, you were right the first time.
Everybody's built something awful, no matter how good you are, I think,
you know, the whole, progression of getting good necessitates that
you have built something awful, at least at one point to learn from it.
Duke: Or accidentally stumbled on something awful.
CJ: Yeah, that too.
Duke: I remember I was building this app for a, compliance team
at a strategic resource company.
And this is like, they're being audited by NSA and like all the three letter
agencies are, have their fingers in this.
'cause it's like, where's the oil?
How, how much of it do we have left?
And so they had these tight restrictions again around What
people are allowed to have.
What stuff?
Like, are you allowed to make calls from your desk phone outside the country?
This, this kind of stuff.
CJ: Yeah, yeah,
Duke: And they had this kind of, I certify that I have this right and
it's under these terms and conditions.
This was like certification process
CJ: yeah.
Data cert, baby data cert.
Duke: it felt super tasky.
And so it would be like, okay, let's do this, close it, and
then in a year reopen it.
see if it's still, anyway, that was back in, legacy workflow
CJ: Yeah.
Duke: and there was some job they had there.
That'd be like every six months if the flow is still there.
And it's not like it hasn't been touched in a while, just toss it.
And so basically like a year a, a year after I built this thing, it was like
none of the flows existed anymore.
So it wouldn't do what it had to do a year later.
CJ: Uh oh.
Duke: Yeah.
but it just exposes, right.
There was probably two or three smarter ways to build this.
CJ: Yeah.
And sometimes you don't know . What you don't know.
I feel the same way when I'm writing code.
I write some code, I come back a month later, I was like, who?
What?
Dummy built, wrote this, right, and then I'll look in the comments.
Oh, that was me.
Duke: Yeah.
Who was the last updated by?
Oh,
Anyway, it's not, this is maybe not to make you a better.
Like developer, you can be a good or bad developer
CJ: this us.
Disagree.
I think this episode will make folks a better developer, right?
Because it's not always just about writing a code, right?
Building an app is more holistic to that.
That's the whole point of this, But then a large part of that falls
on the shoulders of the developer,
Duke: I stand corrected.
CJ: yeah,
Duke: You're absolutely right.
CJ: you know.
these are things that often don't get thought about , when the
app build is requested, right?
Or when the, work is ascribed to someone, right?
It's like,
Duke: Yeah.
And something that maybe separates a senior resource from a junior, one
is the like, I think a junior might presuppose that somebody's already
done all this great thought onto.
what does success mean in its totality for this app?
And we just need you, Mr.
Junior, to plug in the build bits.
And that is not always the case.
That is in fact, rarely the case.
And so especially for you, kinda like early ServiceNow career people write the
stuff down because like this is all the check boxes that gotta get looked at.
In order for this app to be comprehensively successful.
CJ: absolutely.
And on top of that, being able to recount this stuff in an interview, bonus points.
Duke: Seriously, like imagine being able to talk about what it takes
to deploy a successful thing with very few of them under your belt.
So, without further ado, we are gonna discuss the anatomy of an A app.
And we're using app in big air quotes here, right?
Like that can mean a lot of things.
. And again, we're just like, we're just a couple guys.
Like we did our best to research this and, we hope it's pretty comprehensive.
So, these are all
CJ: people will tell us about it in the comments.
Duke: that's right with,
uh, trust the haters to tell you what you missed.
CJ: Absolutely.
Duke: That's why we, that's why we love our haters.
so we're just gonna list off a bunch of things that should.
Be considered or checked off before, during, and after you build.
And we got 'em roughly broken down into , process factors,
build factors and legacy factors.
CJ: So first thing, let's talk about Catalyst.
And we've done an episode on Catalyst before.
, We'll have that in the show notes below.
, But yeah, duke, this one I know is one of your babies.
So why don't you go ahead and dive into it.
Duke: I might have named it, but I think
everybody knows how things start in ServiceNow.
So basically just keep a list of.
The different ways things start in ServiceNow and as you are studying
the customer's process, see which one of those make the most sense.
So, you know, everybody knows stuff can start with email.
Everybody knows stuff can start with with phone, with SMS messages,
with integrations, with other catalog items, with walkups.
CJ: Yeah.
Duke: With agents, you know, just like put some thought into how do we
know that this thing should start?
CJ: Yes.
Duke: of people take this for granted.
Like it should be obvious.
No, it's not obvious,
CJ: Yeah.
? Because not all apps are going to be, , immediately interactive, If you
are getting an email and then an email is causing something to happen, maybe
this app is self-contained, maybe you never do anything once it's built.
That doesn't mean that it's still not an app, right?
Catalyst can take on , all shapes and forms and I think it's important to
know what is actually causing the work to be done so that you ensure that
the work is being done, like being kicked off, like the app's being kicked
off when the work needs to be done.
seems like it's circular, but, um.
Duke: Yeah, exactly.
Well, it's just knowing when it should start.
And the, the other reason why you want to do careful consideration of Catalyst is
that what exists today might not have the benefit of what's available in service
CJ: Oh man.
Duke: Like, have you ever had a process that ends and then the consumer has to
go do something to start another process?
CJ: Yep.
Duke: like the, my very first Service Now job was, , building an, a new employee
onboarding process and literally none of the backend teams took any accountability
for the entirety of the result.
And so it was literally the requester who would be like, go to system A
put in a request for systems access.
Then once you get it, go to system B and put in requests for hardware.
Then once that's all there.
go and make requests for software.
CJ: Right.
Duke: see what I mean?
And so it's kind of like you could have one catalyst, which is just fill out
fricking everything and just make it go.
Or those swivel seat ones where like you're gonna receive an email
from this external vendor and then you're gonna turn around, take that
email and plug it into ServiceNow.
And the catalyst there can switch from.
Mail to integration, and so that's why like it's not just see what it is now,
but see, see if it can be approved.
We're going way over time.
We're going over time.
CJ: Yeah, I mean, yes.
Let's just move on.
You took me back to the nineties there for a minute.
You're like, yeah, swivel chair.
I'm like,
Duke: We're gonna do the whole Catalyst episode over again right here, right now.
CJ: Right.
Duke: Okay.
Remember description.
In the description, we'll have a link to this whole episode.
We talked for a full on half hour about this.
Okay.
What's the next one?
CJ: flows, flows, duke, and look, I know you're the flow master
and I, am coming around, right?
Like for me, like legacy workflow editor was, that was my jam.
I love that thing.
, I am.
Coming around to the perspective that I can't just be an old guy
who only likes the old things.
And so Flow Designer is, steadily becoming one of my more
favorite, parts of the, platform.
But, in context to this, it's all about what do you do next, right?
I mean, that's what flows are, you know,
Duke: Yeah, like, I mean in a whole lot more abstract sense, right?
You have to know.
their process flow.
If somebody says, I need you to build me an app for X, and the X is, is based
on a process, then wouldn't it be nice to see like a Visio of the process?
CJ: Yes.
Duke: we can't make that up as ServiceNow delivery experts.
Some of us can help guide the customer who maybe doesn't have experience doing
such things, but ultimately the owners of the process who are not us, have
to tell us how that process works.
It is up to us to apply the tools in ServiceNow accordingly.
And it's not just flow designer.
It could be playbooks, it could be, chained business rules or whatever.
I hope it wouldn't be, but think of it in a broad sense.
CJ: It used to
Duke: gotta know how this works.
CJ: Yeah, no, absolutely.
Duke.
I think one of the ways that I like to think about, flows, or
at least in terms of, , capturing that while you're , talking to.
The client is and then what, right?
And this is one of the things that Warren Buffet always asks when he's considering
an investment, if Apple, launches a new iPhone on in September, and then what?
And you ask that until you get to the end, to the logical end of the process.
Right.
And then now you got the flow.
Right.
Now you know exactly what's gonna happen and now you know how to build it.
And I only throw that in there, there, because I think sometimes
folks get into this, situation where they don't know how to ask the client
what their process looks like or how to assist the client and building
out what their process looks like.
I think for me, the simple thing is just to ask and then what or what next.
Right.
Duke: Last point on flow is that if your goal in the ServiceNow ecosystem
is to become a ServiceNow ba, you had better know how to run Visio or,
what are some of the other ones now?
I think Figma does flows, but
CJ: Miro.
Duke: Miro yeah, you had better understand how.
A flow diagram works so that you can build it because , not a lot
of customers do know this, and it might be that you have to walk them
through and actually build out what this looks like irrespective of tool.
CJ: Yeah.
95% of the clients that I've had don't have their process is documented.
Right.
And, I always try to start there because you can't build what you don't understand.
Duke: Just think about all the steps in a new hire, right?
How could you possibly know you were done unless you had a flow that says
this, then this, then this, then done.
All right, next thing we got is, integrations.
And
sometimes it's obvious, where this system is literally feeding us.
But you might be in the middle of discussion of an app and they
just say, oh, and then you fill out this field with this data.
Hold on a second.
Where do we get that data,
CJ: Yeah.
Duke: right?
Do we have it?
, We're gonna talk a little bit about this later during the build part, but
integration is the cognizance of where does the data that we need come from?
And also do we need integration for either a catalyst.
Or part of the middle tier of the process, or as something we send as an exit.
So understand your integration points.
CJ: this, brings me back to one of, ServiceNow's previous brand
messages, platform of platforms,
Duke: Mm-hmm.
CJ: This is , one of the things that.
ServiceNow has always excelled at just being that hub of being able to
integrate with practically everything out there And so knowing that,
those integrations could potentially exist or likely will exist based on
the way that, , the platform gets, , embedded in someone's organization.
Looking out for those integrations is always one of the things you
wanna have on your checklist.
Duke: The next thing we have to understand for processes is, , expectations of work.
Okay.
So the idea is like, we gotta have the, we gotta have this work done.
Why?
So that this other team can get their stuff done in time.
'cause this all has to get done in five days.
Okay.
Well, Anytime your stakeholders are talking about intensity of time or
expectation of delivery, then we have a mechanism , in ServiceNow it's
called SLAs, NOLAs and underpinning contracts and all that kind of stuff.
But you want to be cognizant of those upfront before you start to build.
So just put this on your checklist of things to ask when you're
sitting down at that table kind of negotiating , the build of an app.
CJ: Yeah.
And I think you soft sold this one a little bit, duke, right?
Uh, work, because work expectations are probably one of the things gonna
make or break your app, your client's gonna ask you to build something, you're
gonna build it, but you're building it because they want an outcome out of it.
Right?
And how do you manage the outcome?
Well, you gotta manage the work expectations in order to understand
the outcome so that you can ensure that , you're hitting the, points
that the client wants you to hit.
So, this one's phenomenally important.
SLAs are, are a great way to, keep track of it, but just know this
isn't something that you can skip,
Duke: No.
CJ: This is, this is absolutely, a necessity to the process.
Duke: And again, people come to you who don't know ServiceNow won't know to ask
for SLAs, and so just Take that need to know outta the equation for them, just by
asking them about expectations, how they work, so that you can build it in SLA.
So they'd be like, oh my God, that's super awesome.
CJ: Yeah, but they will know to ask you in six months,
whether or not the app's working
Duke: Yep,
CJ: right?
And so how are you gonna tell them?
Right?
So.
Duke: All right.
Second last thing in process that you have to understand is, closure.
we might get this in terms of like flows and knowing how the thing flows,
but most people have a bias for the happy path, this is how it works and
it works every single time, but does it really, like what if we get to the
middle of it and something happens that prevents it from proceeding?
you just have to think about all the different ways you can close.
So we look at things like graceful closure, something
else, like a disgraceful closure.
Like what if we couldn't close the incident?
Like we just don't have a resolution.
You're just gonna have to live with the way this thing is now.
Like, we hate that, but.
It's, it's a disgraceful closure.
And then we have cancellations.
Some work is timeout.
Like I think about, anything that's like a daily task that resets every day.
Like, if you didn't do it today, you missed today's task, tomorrow
you have another task that you can do for that same thing.
CJ: Yeah.
Oh man, that's, yeah, absolutely.
Duke: so just think about the ways things close and you have
to, factor for both the graceful.
And the disgraceful, the unexpected, the,
CJ: Yes.
Duke: kind of things.
Yep.
CJ: Yeah, because that's incredibly important.
Duke: And don't be afraid, they might not have it articulated
on the process flow diagram.
So be the best consultant you can be and say, okay, you
say that there's a task here?
But what happens if the task doesn't close as we expect?
What happens?
CJ: Yeah.
Duke: Sometimes that's an easy thing to answer, and sometimes it's
like you open up a can of worms and let's think about it some more.
CJ: Yeah.
And sometimes you only have the successful path.
This is what we wanna see.
And , and it's like pulling teeth to figure out what happens when things don't,
don't go down that, that happy path.
Well then you hold for the everything else scenario, this is success
and then everything else is not success no matter what it is.
Right?
And then, you can always pick that apart over time to tease out,
okay, well this was a timeout.
This was a cancellation, this was a disgraceful end to the task, right?
Like sometimes you might not have that and your client's not necessarily being
very, forthcoming about those things.
Then I would say the way I, typically do is then I fall back on the
success and then everything else
Duke: All right.
The last, area in process that you gotta, put a little effort into.
This is one area that I can, do hours and hours and hours and hours of episodes.
All on its own is outcomes and reporting.
I believe we have several episodes on this.
We'll link them all in a description.
That's how important it is, but that we put this in the process area for a reason
because it's happening before the build.
We should know the outcomes of this process.
We might know exactly how the process works, but we need to know
the outcomes of the process before we start building because we need
to start building for the outcomes.
If you know the outcomes, again, all kinds of benefits, not only can you
like build reports in so that day one we can find out if the process
is working the way we want or not.
CJ: Yep.
Duke: But also it's like a litmus test for the inevitable, nice to
haves, being disguised as need to haves midway through the project.
We really, really need this.
Okay.
If we gave you that tomorrow, how does it underpin one of these outcomes?
Or which of these outcomes are you willing to give up in order to get that feature?
CJ: Oh man, that's, yeah, dude, that's, oh, we, I don't even
think we have prioritization of, deliverables in here, man.
But we could definitely go, on the tangent about that, but I a hundred percent agree.
outcomes and reporting.
If you don't know what you're trying to accomplish, how do you
know when you accomplish that?
And how do you measure that, and what is the mechanism by which your client would
measure it, And how are you presenting that to them, these are all things, look,
, I know we, largely talk to a technical audience, but I've said this before.
You're not getting paid the right code, you're getting
paid to solve problems, right?
Duke: Bingo.
CJ: So like the outcomes, that's your pay dirt, that is your evidence that
the checks that were written to, pay for your work, were worth it to the client,
? So don't shortchange on this one.
This one is probably one of the most important things on these lists.
Duke: Yeah, I mean, how many times have you sat with a stakeholder who's kind
of been told, okay, you gotta move your stuff to ServiceNow, and it's like.
you come in?
Okay.
Why do you want this app on ServiceNow?
Because it needs to be on ServiceNow.
Why do you wanna do incident management?
'cause everybody does incident management.
Why do you need CMDB?
'cause everybody needs to CMDB, but you don't know , what
you're looking to measure.
You know what I mean?
Like, what questions are you gonna answer?
What value are you gonna squeeze out of it?
So at the very least, on incident management, we should be able to look
at some graph that shows us, you know.
Our volume, like our volume metrics as well as our performance against them.
CJ: Yeah.
Duke: how long is it taking us to close these?
Hey, look, our volume has increased, but it's taking us no longer to close 'em.
We're doing pretty good.
CJ: you're, you're just gonna throw money away if you don't
have these things done, right?
If you don't know what the outcomes are and the reporting is, you're just
throwing money down a hole, Because you're, you're inevitably going to
build the wrong thing and have to go back and make some changes, right?
And, and now that's just cost extra.
Duke: Yeah.
And it's how you get invited back, right?
If you can deliver something where day one, they can start saying,
see, wasn't this a great decision?
CJ: Yes.
Duke: You know, let's get that person to come back and solve another thing for us.
Alright, on to build
CJ: So good practices validated by, in instance, scan.
I love that we here are saying good practices.
Note that, ? That we're not saying best practices.
because
best practices can fluctuate, depending on what you're doing or depending on
who you are, depending on where you are in the lifecycle of a product.
like best practices today are different than they were
when I started 10 years ago.
You know,
Duke: Not to mention that it is not like some, vast governing body that says this
is best practice, thus say it the Lord,
CJ: Yes.
Duke: know, but, and so it's kind of this weird collection that we all
maintain in our own minds collectively.
and so it's easy to confuse common practice with good practice, but I The
key here is we have an excellent tool in ServiceNow to capture, you know,
more legit granular, like you shouldn't do this, and it's called instant
scan and you should be running it.
if you are a ServiceNow , resource, if you're a ServiceNow product
owner at a customer, you should be getting people to run it.
You should be automating it, so that your scan can look
for, stuff that shouldn't be.
CJ: Absolutely.
Duke: Stuff that exposes you to risk.
CJ: Yeah.
So then you can change that.
Duke: so the next one in build is failure detection and remediation.
I worked for 15 years in the ServiceNow ecosystem to become a air quotes
real developer at ServiceNow, and I started learning about failure
detection and remediation that day.
Wow.
I, you, you know, those things where you think, you know,
CJ: Yep.
Duke: and then someone tells you, no, no, no.
The start line is way over there.
CJ: Absolutely, dude.
Right?
I got a bunch of like proco developer friends, right?
And they're all right.
They're, deep in it and I'm like, man, I just play a developer on tv.
Duke: It's, yeah, it is so easy to assume it's gonna work.
I have a catalog.
It's gonna call a flow.
It's gonna take this as an input, and then that's gonna get fed to this flow action.
It's gonna output this, which is gonna feed another piece of
the activity, and it just works.
'cause that's what happens, right?
Just takes that value of the field.
And so I'm talking to my developer peers in ServiceNow.
They're like, yeah, but what if it doesn't?
I'm like, how could it not?
I don't know.
Well, what if it doesn't?
I'm like, because the interface makes that field mandatory and it's
gonna force you to put something in.
Or like what if they don't do it through the interface?
What if it's done by a script?
I'm like, I don't know why somebody would do it by a script.
Yeah, but what if they do?
And it's hilarious after the fact, but you really do have to build in
a skepticism or a paranoia almost
CJ: Yes.
Duke: I'm expecting this input, but what if I don't get the input I'm expecting?
I'm expecting this output, but what if I don't get the output that I'm expecting?
And at the very least, at the very least, what this will do is help you isolate.
Where things have gone wrong, everybody's the 500 line script
include that mostly works, you know, except for when it doesn't and
it's like, where did it go wrong?
And then you're having to invent testing scenarios to try and
figure out what went wrong.
But if you start with a paranoia of things can go wrong, and so let's
handle almost every case where I'm dealing with inputs and outputs.
Just assume it can fail and what do I do in the failure case, it's gonna be so much
easier when things break and things break.
CJ: Duke, I think it's important too, the way that we arrange these things, right?
Is that we put.
Closure, disgraceful and graceful closure, timeouts, cancellations,
outcomes, and reporting.
We put that in the stage.
That is before building failure, detention and remediation, right?
Because the
Duke: Hmm.
CJ: of those processes, Determine how you build the app.
so all this stuff is related and, you'll start to see that sprinkled in
as we go through, a few more of these.
, Duke: Now that we talked about failure detection, remediation, we also
gotta talk about data governance.
So I think most people that got into ServiceNow understand the
concept of a data structure, but.
The next level is understanding the governance of the data.
So whenever we think we need a new table, like sometimes we don't, sometimes that
did, like we need to store locations.
Well great, we already store those.
or computers.
Great.
We already store those.
so when you're talking about data governance, you gotta ask yourself
questions like, do we need new data or does it exist in ServiceNow?
Or do we maybe need a new property of the data?
CJ: Yeah.
Duke: also, if it's a thing that we're talking about, real or
abstract, can it go in the CMDB?
CJ: Oh man.
Exactly.
Duke: Yeah, yeah.
Or, or, or is it addressed by the CSDM somehow?
Do we have to build some new service table, or does CSDM have
something ready made for it?
And on top of that, where do we get the data?
We're not just hand keying into a ServiceNow, are we?
Are we,
CJ: flat files, baby.
Duke: where do we get it?
And then who owns it, all these things together, data governance, and let's
just pour one out for data certification app, which made it all so much easier.
CJ: Yeah.
Yeah.
We miss you.
Data cert.
I won't speak for everyone who's listening.
I personally have encountered, several instances where I'm, logged into an
instance and I've seen a table recreated that already exists out of the box.
And you know, it's a large part because of a lack of data governance.
I've worked with a client and,, they're using contracts, But they're
using contracts as a custom app that does exactly the same thing as the
out of the box contract module does.
and that's because the folks who built that app didn't
understand ServiceNow at the time.
It was the, they didn't understand, like there was no, data governance
portion of the, the requirements done.
And so no one knew that there was a contracts.
module that was already there, so they rebuilt it.
Awesome.
Duke: There's also kind of the case of , oh, this body of users is
the team that, does the approval.
So I've seen people try and build another user table that stores user information
you gotta think about the ways , to do it.
So if I'm looking at an approval group, build a group, you know,
CJ: Right.
Duke: having a group doesn't necessarily mean it's an assignment group.
the main key there is just.
Does the data exist?
If so, do everything you can to use that data versus create a new table.
CJ: Absolutely.
, And then this is just all architectural in nature, it is all about understanding
the data that you have in your instance, the, way that instance is
set up, and then also how that aligns with the business as a whole, right?
So that you understand how you can utilize that to build an
effective and streamlined app.
Duke: once this starts happening, then you're really rapidly gonna
go into groups, roles, acls, and other security concerns.
CJ: Ooh Lord.
Duke: yeah, like, I'll, I'll give you an example from release ops, right?
We have this concept of, a pipeline.
And a pipeline is a set of records that determines at this company we go from dev
to test, to quality assurance, to prod.
And so since everybody's got different instances and different
amounts of instances and different ways things travel from Dev to prod,
it's something that everybody has to define for themselves, right?
but who defines it?
Like there's probably a user of release ops that has that knowledge that isn't
necessarily the ServiceNow admin could be like, it could be overlap, might not
also be, but for that matter, everybody else who's using release ops, like the
developers are saying, my stuff's done.
Like please release it.
they have no business going and managing the pipeline.
CJ: Yeah.
Yeah,
Duke: You know, no business whatsoever.
And so in the data governance, you'll start seeing that, these types of
people can do these types of things.
And we call it crud access, create, read, update, delete, and those form
the basis of your groups, your roles, and any acls that you might need.
But more often than not, I'd say you have to coax this outta the customer with your
questions because they can't even see the tables in their mind half the time.
CJ: This is so true, duke, and, this ties back to that
the first part of this process.
Well, when we're going through the process and you're building out the flow.
Of your app, ? And it's gonna be decision points in that flow,
typically in those decision points of where are you gonna be asking
yourself, alright, now who sees this?
Or who can do this?
Or who needs to be notified about that's where you surface.
The groups or the rows and acls, right?
That will be needed to, uh, be associated with this app
Duke: Yep.
And Groups covers the operational aspect of it too.
Like if it's a task app we're dealing with.
Who are the support teams, right?
Who are the teams that can get this stuff right?
And so that would be your roles anyway, your groups.
And then , you defacto lump that with roles because
that's how roles get defined.
Don't let me catch you assigning roles to humans.
CJ: Oh my God.
Duke: Don't.
CJ: Oh, please don't do that.
Oh my God.
I will tell you though, the ServiceNow does make it a little
easy to like uns sortt that, to when you, if that is screwed up, right?
Because it shows whether or not a role was inherited, to a user or not, right?
So you can see some things that have been directly assigned, but man, just don't,
Duke: It's just effort and Right.
It's just effort and risk.
You know, you have to know that Bob got fired so that you can manually
take the roles away, like, and, you know, and, and then the risk.
It's just the risk maybe you missed it.
Maybe the user didn't get ACT deactivated.
Maybe they still got access.
CJ: And then there's encryption, And you know when you need encryption,
Duke: No, well do you, you might not know.
CJ: right?
That's fair.
Duke: luckily every time I've been, in a situation where we
needed it, like the customer knew,
CJ: Yes, that's true.
That's good.
but sometimes the customer doesn't know because sometimes it's dependent
upon, regulations, ? That, your particular stakeholder might not
have any line of sight to, and
Duke: I,
CJ: Right.
Duke: I remember having talks with the hedge fund , they had just like data by
compliance process where it's like, oh, some dude in Saudi Arabia says he can
get me all the information on how much reserves they have in all the oil wells.
And there's some legal traceability that they need can I buy and
trade off this information?
CJ: Right.
Duke: And so how do we put this on ServiceNow but guarantee that
nobody even ServiceNow can see it,
CJ: Well,
Duke: and know what I mean?
And I was like, I don't know.
mean like, does it matter that much?
And they're like, oh yeah, our enemies would buy ServiceNow
just to get to that data.
I'm like, oh, okay.
CJ: Oh.
Oh, okay.
Duke: was a, it was, it was a while ago, but.
CJ: No, man, I, I mean, I totally get it right.
I've worked with a, hedge fund too, I think a different one than
the one you're talking about here.
And, we had a similar thing where we were, doing group management and there's concept
in trading called, uh, Chinese wall.
I think that's what it's called.
And, people on one side of the wall can't see things on the other side of the wall.
and it like, not just can't see things.
legally, under the penalty, right?
Must not.
Thank you.
Legally must not see things on the other side of the wall, And, talk
about pressure when you're trying to build a system that ensures that, by
default you're not breaking the law, and that's where one of the other places
where encryption can come in handy.
, Duke: Last thing on build is a TF test.
Yes.
It's a ton of extra work.
And it's getting easier every year.
However, it's not just about you, there's the amount of time it takes us
to build a fully, robust application, And we argue that robust application
would include a TF tests, so that as this app changes, we just push a
button and and see if it still works.
CJ: Yeah.
Duke: and that might mean I work more or there's more expectation for me, And
yeah, it's always like, uh, doing more with less and can we just cut this out?
But the payoff when everybody does it, is that you just have push button tests
CJ: No, dude, that's, that's not the payoff.
Duke: It isn't.
CJ: No.
The payoff is when it breaks and you've gotta fix it.
You've got a much easier way to locate what's broken.
Duke: Yeah, I hadn't.
I do need to think about it evidently.
CJ: push button testing, great.
Right?
Absolutely.
But the, the whole point of testing is yeah.
I mean, you hope that when you press the button, everything's gonna come up green.
But what if it doesn't?
If you don't have those tests, all you're gonna have is a broken system.
If you have those tests, you got something that's gonna turn red at, and you know
where you need to go, start looking.
That's gonna save you.
That gonna save you hours of time.
It can save you days
Duke: think about it that way.
CJ: right?
Duke: didn't think about it that way.
I just assumed like, oh, I got my everyday normal operations and oh,
I just brought in this third party vendor and they're changing stuff
and like I, every time they change I just wanna push the button and test.
I don't wanna have to call my users and say, okay, everybody jump back on
the system and see if it still works.
I just want, I just want to like press a button and do the test.
especially, I'm just gonna say it.
With release ops, which can automate the A TF part.
Hey, just take this update set and move it to test and then run the tests.
CJ: Yes,
Duke: And no, don't need nobody to remember, remember?
Did you remember to do?
CJ: Yeah.
If you got kids, you know exactly how, foolproof that is.
Duke: Yeah, exactly.
Exactly.
So,
CJ: Did you remember to take out the trash?
No, I didn't.
Do you realize you're sitting next to the trash can?
Duke: Can you smell that?
Ah, alright.
One more category to go and then we're done.
CJ: End user documentation, duke.
All right, everyone at home take a shot for documentation,
Duke: Oh, there's multiple types, right?
And so we're not talking about documenting what you built.
Right?
end user documentation specifically, . Is okay, somebody's gotta use this new app,
or somebody's gotta understand how to use it now that we moved it off of legacy
forms and onto workspace or something.
CJ: Absolutely.
? Duke: These people aren't ServiceNow admins who are using it.
So do they understand how it works?
Do they understand when to press what button?
CJ: No, they don't.
If they don't, duke and man, and they never, they never do.
That's the thing, right?
And like this is just such a pet peeve for me right now, right?
Is that,, I am encountering so many folks out there who are, ServiceNow customers.
And they are, not getting the value outta the system.
I'm like, okay, show me.
And I was like, yeah, we got these processes.
All right.
So how do you use them?
We don't know.
It's like, how, how do you not know?
Like, where's the documentation?
We don't have any.
It's like, okay, so what happens when you land , on the page, right?
With all the data and the data?
Like, we don't know.
We don't know what's next.
We don't like, no.
Duke: you take somebody who's been using Microsoft Project since
forever ago and oh, congratulations.
You have this new red hot SPM tool and Suddenly they have absolutely
zero knowledge on how to create a baseline, how to build a project from
a template, how to add a resource plan.
Like it is all different.
It's all different.
And they're not the ServiceNow admin.
They ain't seen this even once beforehand.
So the good news here, this is just a checkbox that you have to
make sure to make sure you get a robust, capable app, right?
Most of the time, luckily this won't be your responsibility, but we talk
about maximizing your agency, right?
If you can make sure you drive this is completed by somebody, it just
makes your app a lot more successful.
'cause your users will know what to do with it.
CJ: Yeah, and this is how you ensure that your app actually
gets used instead of just built.
. Duke: Use instead of just built.
I love that.
Okay, next thing on the Legacy uh.
Guided tours.
This is an older feature in service now, but it's still valuable even if
you have the documentation sitting in front of them, , very few people
are gonna open up the how to PDF.
So if your app is simple enough, you can add a guided tour to it and this
buttons for this, this buttons for that.
Like go ahead and do it.
it's worth the time.
CJ: Yeah, I a hundred percent agree with this.
I've used these in the past and they've been very successful, I think.
so I a hundred percent agree that guided tours are, functionality.
They've been around for a while.
That means they're, a bit more mature, right?
Which means they, are gonna work more often than not in terms of
like bugs and things like that.
and, they're good.
They are very self-explanatory for, uh, end users.
Duke: and they don't even have to be a hundred percent thorough to be useful.
They can just be very thorough and useful, you know?
CJ: Yeah.
Here's the best selling point I can, I can give for 'em, right?
ServiceNow includes so many guided tours out of the box, If you, , load up a PDI
and load up a module that you've never used, go use the guided tour, Once you
get through the guided tour, I guarantee you you're gonna know a lot more about
that module than you did when you started.
that's the best selling point I could give you right there.
So if you do it well, your end users will love you for it.
Duke: And people are like, oh, it just takes a lot more
effort to add it to the app.
Yep.
But you want your app to be used, right?
CJ: Yes
man.
This, we might be able to retitle this episode.
, Building a usable app or
Duke: Yeah.
Building an app.
People actually,
CJ: Yes.
Building an app people actually use.
Duke: Okay.
God, my voice is wearing out.
next point on legacy, platform owner documentation.
Surprise.
CJ: Take a shot.
Duke: How is it that I, that I ended up talking about this?
Huh?
CJ: I
Duke: Um,
CJ: it like.
Duke: so listen, building out all the objects that you touched is
one thing, but you must describe.
The why of the app, ? Capture that now.
Capture its major features.
Write it like an essay, write it, as if it's being consumed by a human.
There are platform owners out there that don't know all of the special things
that have been built onto their app because nobody bothered to write it down.
I'm Chad, I'm the ServiceNow admin for a company X, Y, z.
I know what's going on, but Chad hits lotto.
Chad goes off, does whatever, Then you're the new person that comes
in to own it, and you got a team underneath you, and it's like, what
do we have on the system right now?
Unfortunately, there's no push button, receive a gigantic memorialized list
of the things that were built and why, which is why it's imperative that we
memorialize the things that we build.
We've talked about it a hundred thousand times.
We did,
did a dedicated episode on it.
CJ: Yep.
Duke: We'll put that in the description.
Oh, we can have a huge description.
I hope we have enough room.
CJ: We're gonna do a separate episode on the description below.
Duke: We should have an index of all the things that we've
ever added to our description.
CJ: Man.
Dude, that would be awesome.
Duke: Okay, buddy, take the last one.
CJ: Uh, succession plan.
All right, so what happens when you're gone, somebody's gotta
take this thing over, right?
You've built it, you've deployed it to production is in use now,
and you now have been promoted.
You're now VP of software engineering, so you're not doing dev anymore, so
who's going to take over that app?
How do they know how to take it over and how to run with it?
Those are things , that really do need to be talked about
before you win the lottery.
Duke: Yeah, exactly.
Or get hit by bus.
Right?
There's always the, the anti-lock.
CJ: Yeah.
Duke: Um,
CJ: Was trying to keep it less morbid, but yes.
Duke: yeah.
Hey, listen, if you've been in this space long enough, you've been at one
of those customers where it's like.
I don't understand how this app works.
Yeah.
Jane built that app and Jane's now on a separate team that does stuff just for hr.
But now you're begging Jane for her time, taking away Jane's time from her current,
outcome she's trying to deliver so she can come and explain to you how she built
this thing, if she can even remember.
'cause it was eight years ago.
CJ: Yeah, which again highlights the importance of documentation.
, Duke: How do we sustain knowledge of what we have over the long run?
Because newsflash, the stuff we build is invisible.
CJ: Ooh,
Duke: It's intangible.
, It's abstract.
And unless you mindfully build something to encapsulate it, a document.
It's the whole reason we invented writing and numbers,
, CJ: I was watching a, comedian on, , YouTube, Facebook somewhere, . And,
and he was like explaining, school from the perspective of, the people
who first invented it and it was really very much like what you just said.
hey kid, we're going to take you out of what you're doing and
come put you in this building for eight hours and teach you things.
Why, why, why?
Why do we have to change?
Well, because we're going to die and someone needs to know
these things after we die.
but that's pretty much what it is, right?
succession planning is we're going to move on, Whether that's inside the
company or out, and somebody needs to know this stuff, before we leave.
And I will tell you though, I'm still stuck on the stuff we build is invisible.
Like I really like that.
I'm, my whole, I got half my brain working on that right now.
That might be a future episode.
Duke: I mean, getting into like DIY, car repair with my son has just opened up.
I've always talked about the invisibility problem, but it's just a whole new world.
Like we changed our brake pads and our rotors.
couple weeks ago, you take the wheel off a car and you're like, oh yeah, there it is.
that's how they built the rotor.
The brake pads, the mechanisms that compressed them and keep them in
place and stop them from sitting on the wheel the entire time.
you can see it, you can see the inside of a car, you can know jack squat about
cars, take off a wheel and be like, that is probably meant for stopping a car.
You know, like you can't open service now.
As easily.
Yeah.
I mean, yeah, you got the records, right?
The script includes the business rules, the flows, but there's so many of these
things in so many different places.
what if the owner's manual of your car was the only way you could
understand how your car worked?
Except every page of it is in a different cabinet somewhere in your house.
CJ: Yes.
I mean, I mean,
it would be impossible for you to figure it out.
Duke: It is impossible to figure out if you come in sight
unseen to a brand new customer.
Everybody hates doing the legacy planning work.
It sucks like it's a slog, but they don't hate it as much as when it's all
screwed up years later and somebody new is trying to take care of it.
You don't hate documentation and legacy planning nearly as much as you hate
the consequences of not doing it.
You just don't know it Now.
CJ: Yeah, absolutely.
I'll tag on to this one too, duke, I was just talking to a client, and,
you know, we were talking about they were gonna do an audit to understand
who owns all various different services in the, in the company.
, And I said, okay, so once you do that audit, you also then have to
set up a process to ensure that you never have to do that audit again.
Right.
You know, because doing that manual audit's gonna , take a lot of time.
It's gonna take a lot of effort, but now that you've collected all those individual
pages from all those individual file cabinets and put them in a book, you
need somebody to ensure that the book is kept up to date, and so, that is another
one of those things that is invisible typically until you have to do it again.
Duke: gosh, it's been a long episode.
CJ: Man, dude, we were just like, this is what happens when
you get a day off and record.
Duke: all right.
Let's just do a quick roll up of all the concepts we covered.
Write 'em down.
Take notes, especially beginners, so you can start how do I know I've got a
good, solid, comprehensive application?
CJ: Yeah.
And,
Duke: in your own blanks here.
CJ: and, and, and I wanna, and let me jump in on that, do this roll
up , and have this so you can build your applications on the build with
challenge that kicks off tomorrow
Duke: Oh, bingo.
Well, hey, let's put a link to that in description below.
CJ: Absolutely.
Absolutely this one's is, targeted around the build agent.
But if you go to ServiceNow community, right?
Like you can get a whole lot of information on, what's going on there.
And this list, will help you build whatever you're gonna build
in the build with challenge.
Duke: here's a recap.
We have process areas, understanding your catalysts, trying to
improve the catalyst you have.
, Understanding the process and how flows, playbooks, ServiceNow
Logic can execute those.
Understanding your integration points with, , external systems, beginning,
middle, and end, managing any work expectations, , especially in terms
of time, understanding how everything closes, and then understanding
the outcomes and reporting.
Corey, you wanna cover the build ones.
CJ: Yeah, duke.
Absolutely.
, So we got good practices validated by instant scan.
We've got failure detection and remediation.
You got data governance, Groups, roles and acls, encryption and ATFs tests, and
note, as you listen to this, how these things are all interconnected, right?
So build relies upon process.
Duke: And then remember your legacy, like nobody's gonna be in their jobs forever.
We want this product to last as long as possible.
We want people to remember that we were the ones that did it for them.
Okay?
So pay attention to your end user documentation.
Use guided tours as you're able to, , be obsessive about your
platform owner documentation, and be sure to have a succession plan
to pass on everything you know.
CJ: And with that, we will kick it over to the outro.