Subscribe
Share
Share
Embed
Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk
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.