Build a Simple, Native, DevOps Process with Clicks, Not Code
In this session, we’ll discuss methods to manage configuration changes, sandboxes, testing, deployment, and documentation.
You Might Also Like
Rapid Restore: Data Rescue for Dynamics CRM and Power Apps
PwC and Own Partner Together to Protect and Activate SaaS Data
Future IT Considerations for Federal and State IT
Enhancing the Resiliency and Security of Your Hyperforce Org
(upbeat music)
- Hello everyone and welcome to you
another Salesforce Band linked in live.
So my name is Dana Darr and I'm the events
content producer at Salesforce Ben.
And I'm really excited to be your host for today's event
where we're gonna show you all of you Salesforce admins
out there how to stream your line,
your DevOps processes all without writing code.
So while we wait for everyone to join,
let us know where you're logging in from today.
We always love to see what the global audience
we have attending.
So many Salesforce admins face challenges
when it comes to managing a comprehensive DevOps process,
whether it's limited time, resources or expertise.
We understand the struggle.
So that's why we're here today to equip you
with the skills and knowledge that you need
to succeed in your career by implementing
an efficient change management process.
So I'm thrilled to introduce to you Gina Marquez
and Matthew Kennedy from Own Company
who are here with us today from their
Snazzy New Studio to share their insights
on how to simplify and optimize your DevOps processes.
Gina, would you like to introduce yourself?
- Sure, I'm Gina Marquez.
I'm the director of enterprise applications here at Own.
I've been at Own for six years now
and I was the first admin here.
I've been in the ecosystem 10 plus years,
Salesforce MVP, user group leader
with my friend Matt Kennedy who is joining me today.
- Yeah, Gina, happy to be here today.
So my name is Matt Kennedy,
principal technical evangelist here at Own.
Like Gina, I've been in the Salesforce ecosystem
10 plus years.
Been at Own just a little over seven years
initially as a solution engineer
but then transitioned to working with partners today.
So happy to be on this webinar we've talked about.
- Thank you for joining.
- Great, thank you.
So before we get started, just a bit of housekeeping.
So as this is a webinar, all lines are muted.
But don't worry, we'll be having a Q&A at the end
for you to ask Gina and Matthew
and you burning questions you may have.
So feel free to submit the questions
in the comments throughout the webinar.
The webinar will also be recorded
and will be available on ourselves
whilst Ben LinkedIn and YouTube channel
just in case you need to drop off
or would like to share it with your colleagues.
Something I just wanted to mention is
that you also want to stand a lookout
for a link in the chat to a raffle
where you will have the chance to win a Sonos Bluetooth speaker
which is worth 150 pounds.
So exciting stuff, look out for that.
We'll all hand it over to you, Gina and Matthew
to take us through the presentation
and I'll see you at the end for the Q&A.
- Awesome, thank you.
- Great.
So I think when we talk about this, Gina,
we really have a lot to cover today.
So let's just jump right in.
I think when you look at, it'd be great for you
to take us through your change management process,
gathering information, organizing, prioritizing,
through all the challenges with data and testing.
So before we celebrate the success of this process,
let's go step by step to understand
how to tackle this challenge.
- Yeah, so I wanted to do this
'cause whether you're in a new job
or you've transferred into the Salesforce opportunity
at your existing company
or just looking for a new way to track your work,
I started at own six years ago
with a 34 item backlog.
Things like replace application X,
move to lightning, automate lead processes,
implement a Netzween integration.
It was extremely overwhelming.
And so have you ever felt overwhelmed
with just there's so much work to do
and you just don't know where to begin?
- I think, you know,
that's interrupt you there,
but I remember when you started it.
We never had an admin before.
We were kind of doing a little admin by committee.
So we did have a pretty big backlog
and it was great to see you come in
and kind of take hold of that.
- But with that was a laundry list of items, right?
So being an admin of one,
I wanted to talk today about how to organize your work,
how to structure the changes you'll be making.
But before we begin,
it's really important to talk about the importance
of protecting your Salesforce org.
- No, absolutely.
I think when, you know, it's just a great point.
Anytime, you know,
you're undertaking a major digital transformation project,
you should really first establish, you know,
a clear data protection strategy.
You know, most Salesforce users think
that the SAS provider is responsible for data protection,
but as you can see on the slide,
it really is a shared responsibility model.
When you think about a SAS provider,
they're providing the infrastructure,
the uptime, the availability of their platform.
And as a user of that platform,
you always have access to your data as it exists right now.
But think about all the changes that occur on a daily basis.
You think about, you know, whether it's just end users
making changes, if it's admins developers deploying code,
if it's admins running large integrations,
you think about all the ETL tools
and all the data that changes on a daily basis.
What own provides is an automated daily backup
of all the data, the metadata, the files, the attachments.
So you can see what's changed from day to day
or week to week or month to month.
Oftentimes, you know, somebody runs some type of integration.
It doesn't realize there's an issue to a day later.
You'll be able to compare and identify exactly what changed.
So with data protection addressed,
you know, how can we now safely launch
a change management process?
- Yeah, so let's review what change management is, right?
It's how we manage all the changes
that are being requested of us.
How do we gain business alignment or business approval?
Especially if you're working in cross-functional projects,
cross-functional teams,
you wanna make sure you have alignment, right?
And then most importantly, prioritization.
What do we work on first, right?
Me being an admin of one in the beginning,
you know, I can only accomplish so many things at one time.
So you'll need to complete some impact analysis
of the work that's being requested of you.
And at OWN here, we love everyone to innovate.
If there's things in our applications
that can help people do their jobs better,
we welcome those suggestions and every admin should,
as it shows your colleagues that you're a trusted advisor.
- I think, you know, admin of one,
I think if you use an army of one,
we did have a lot going on.
So it's interesting, you know,
as you define that change management process,
now it's time to take a stock of where you are today
when you're looking through things.
First thing is documenting what's being done
and how it's getting done.
Specifically, if you're new to a job or a process
and you have a lot of information to gather,
Gina, what would you do first?
- So, I mean, first thing that I did when I started
was interviewing different people
in different parts of the organization,
how they work, what they actually do,
and then how they use Salesforce.
There's this concept of SABLA,
which is Salesforce Administration by walking around.
And gathering of information should be never ending.
You constantly wanna learn what your business is doing.
I tell everyone that I'm mentoring
to be a really good admin,
you should know what the business is doing.
That's where your value is.
The technology is kind of the easy part, right?
You have a community of people behind you,
you have the trailhead platform.
So the tech could be taught,
but the business is a little bit difficult.
- I think that SABLA concept is interesting.
And I do see you walking around a lot,
but I think I see a lot more people walking to you.
So sometimes maybe it's SABLA sitting around
and everything's--
- Sometimes they find me.
I think it's new hire orientation.
They just sort of picture up and say, go see her.
At this point, you're just gathering your workload, right?
You wanna start some type of backlog,
or define a backlog if they hand one to you, right?
And you wanna put some effort into analyzing
like how much work it's gonna take
to actually do those things
and put some type of priority around it.
- Excellent.
So, backlog, right?
I agree, it's the form moving forward
with any new initiatives.
It's really important to look at all those open requests.
Azure gathering information, you need to optimize,
you need to figure out what tools are available
and what you need to track and report on
as you're going through all that work.
Should you build something in Salesforce
for tracking or use a free tool, purchase some tool?
Gino, when you take us through like your day to day,
how do you consume work today?
- So starting on, I quickly built out the case record type
for an intake process.
So I was getting all kinds of requests
along with having this backlog of work.
And I classified that, right?
The tasks, right?
A user needs help with something versus,
here's a big project like ImplementNet Suite.
This helped to keep everything in one place for me.
It enabled me to prioritize things very simply.
And now we have three teams and almost 20 people.
So now we've moved to more, you know, formalized processes,
formalized tools, purchased tools.
But we still use those support cases today
for those user tasks.
So the point here is you need to start somewhere.
If you have nothing yet in place,
don't get hung up on the tools.
But you do wanna start somewhere.
- So three teams, 20 people,
you must just be sitting back and relaxing today, right?
- No, no, it doesn't happen here at all, unfortunately.
In those beginning days, we formed a review board.
We had the key stakeholders in the business
who would review all the project-related work.
And together we would prioritize those items
and the business would approve any new requests that came in.
Again, going back to any user could ask for something.
And this was critical for alignment
and making sure that I was working on the right things
at the right time for our business.
One takeaway here is every year we sat down
and did like a two-day kind of kick-off review.
What we were doing, how we were doing it,
how we were reporting.
And we actually started changing our processes
to reflect changes in the business.
So you have to evolve just like the business evolves, right?
And you must be able to report at least what you're doing,
how long it's taking, what's getting done
and the level of effort that it takes.
- Okay, so what you're saying is that
an intake process should include method
for work to get requested.
Don't forget those maintenance items, right?
There's like three releases a year on Salesforce.
There's constantly package upgrades
from some of the partner packages you're utilizing.
Do a high-level impact analysis, right?
You wanna be able to make sure
that you're meeting the cadence,
to review the work and prioritize those items
every two weeks, once a month.
I don't know, what is your current spring process?
- We do everything two weeks.
We always have, yeah. - Okay, important.
And then you wanna sign off on what was requested.
You wanna make sure that what you're getting done
and it should not be a requirements gathering meeting, right?
You really wanna make sure you're being productive.
As you're evaluating these requests,
what do you recommend to really set your priorities?
- So for prioritization,
you do have to do some assessment of effort, right?
You have to do some impact analysis
and this really should be done
before you meet with your business.
And that will help you to discuss prioritization.
Looking at the chart, you see the work
should be balanced between quick wins and major projects,
some fill-in, some maybes,
quick wins really for me should be at the top.
Their high impact, low effort,
and then kind of mixing everything in the rest, right?
When you have projects, you might have deadlines,
so that might take a little bit more priority as well.
But the important thing is to get your leadership
to buy into whatever type of prioritization method
you are using.
And at this point now, we have all the work collected,
we have the work prioritized, so we're ready to go.
- I think it's so easy to spend lots of time
right on those fill-ins.
Sometimes you can just get bogged down,
you think you're being productive, you're being busy,
but you're really making an impact.
So that's important to really prioritize.
So let's think about it.
You've got this intake process,
you decided what should be getting done first.
And with that completed,
when you think of the method to get started,
what do we do next?
You got your list, go ahead and run.
- So people hear the word agile,
and it's like to agile or not agile.
The point here is like you don't have to have
a formal sprint scrum process,
but you can commit to do work in two or one week sprints.
And this is your call based on your business
or your business review meeting, right?
But the earlier you adopt some type of a process,
the better.
Here at own, that's exactly what we did.
Once we had the work prioritized,
we would work on those items
till the next business meeting.
Some things would get finished,
some things were bigger projects.
So we would just provide an update on those projects.
And we'd also review what new things came in
in that two week period.
Remember, you can manage with cases
and drive your business review meeting
with a really great report or dashboard.
- I think the interesting thing that I saw
is as you like evolved and developed in this role
is that by setting those priorities
and agreeing to the business review,
then you could say no to some of those requests
that would just pop up. - That's not my vocabulary,
by the way. (laughing)
- I've heard no a lot.
And in a lot of requests that I've put in.
But I think you know, you can make a great point
by getting the business to sign off
on what has to get done and when,
it makes it easier to really prioritize
and kind of put off things that may be of that lower value.
All right, so we're about halfway through this webinar.
And now we can actually talk about getting the work done, right?
You've sorted through everything,
you've prioritized, you're ready to go.
Most things in Salesforce can be done in clicks, right?
The Flow Designer has come a long way
since when you started back here in 2018.
I think it was probably classic back then, right?
- It was classic and not the Flow Designer it is today.
- Not even close. (laughing)
So today we're focusing on the clicks portion
of administration and using native tools available to you now.
So tell us what you would do.
- Yeah, nothing I'm gonna review today is code related,
using Apex, you know, I wanna show you native tools.
But first, let's talk about data protection
and the importance of protecting the work that you're doing.
- Yeah, I mean, as we mentioned earlier, right?
Protecting your data is your responsibility.
Every SaaS vendor, you know, protects their platform,
but they put the responsibility of data protection,
you know, on the users.
And this is true not just for Salesforce,
but ServiceNow, Microsoft Dynamics,
really every other SaaS vendor out there.
And the burden of shared responsibility goes beyond
ensuring business continuity when the data is lost
or corrupted.
It also extends to securing it against unauthorized access
and ensuring compliance with regulations
and governance policies.
- Yeah, it's really important to protect your data.
You don't wanna close a business disruption.
And these limitations can also stifle innovation, right?
As an example, 90% of the Salesforce developers
report that they don't refresh their sandboxes frequently.
It takes time and there's effort required.
And so they lose out on the ability
to have fresh, accurate data for testing.
Data that could help identify bugs
before they get to production.
Data could also help reduce the 50% of the time
they spend fixing code and redirecting that towards building
and innovating and knocking off that backlog.
- Yeah, no, I think, and one of the challenges
I know that we wrestle with here all the time
is sandbox seating, right?
You think about manual sandbox seating, right?
You're wasting a lot of time with CSVs,
with Excel, VLOOK, up data loader, right?
And you're just trying to get like a representation
of your data in a sandbox, but it's a very manual process
with a lot of steps involved.
We also think production backups are critical,
but what about all those sandboxes?
I mean, they really should be protected as well.
Think about accidental refresh of a sandbox.
If you have a project that's in flight,
you could potentially lose some of the work
that's being done in there.
So the other thing is, you know,
when you look at deployments,
we think it's really important that backups are done
before and after deployments, right?
You wanna be able to do those comparisons
to see what's changed.
So our compariutility and own recover
allows for both the metadata and the data
to be identified between one day, one week, one month,
whatever you're looking at.
And you know, lots of those applications store configuration
and data objects.
Think of something like CPQ.
- Right. - You're doing products,
- Price and rules. - Price book entries, right?
Those get configured and set up in a sandbox environment
and then get deployed to production.
Well, if something goes wrong,
how do you identify what's been changed
as part of that release?
- Yeah, I can say sandbox seating is one of the top products
that we use here.
We use all of our products,
but seating is by far my favorite and most used.
- Awesome. All right.
So the other critical factor I think
when you think about sandbox seating is, you know,
our tool will move production data down
to a sandbox environment.
And I think any customer you talk to,
the first thing they say is,
well, whoa, whoa, whoa, be careful there.
We got a lot of sensitive information.
So there's also the ability to anonymize.
You want to be able to mask information
that's going from that production environment
down to the sandbox.
Think of fields like name, address, email, phone number,
credit card data, so security information,
all highly sensitive information.
You want to make sure that whatever you're doing
when you're populating those sandbox
is going to mask that information.
So when we think about, you know,
going through these sandbox types,
help me, help me understand how all these work.
There's a lot here.
So we always start with sandboxes, right?
You're never building in production.
So I wanted to just take a minute to explain the sandboxes.
First on the list here on this slide
is the developer sandbox.
And it's intended for development and testing
in its own environment, right?
It includes a copy of all of your metadata,
the configuration.
It does come free.
You can refresh it every day.
It holds about 200 megabyte of data and files.
And this is really where you should start.
Next is developer pro.
Now this is a paid solution.
It's intended for development and testing as well
in an isolated environment,
but it can just hold a larger data set.
So you can still refresh it every day,
but it holds one gig of data,
yeah, one gig of data and one gig of files.
You can do, you know, more development there,
more quality assurance testing, integration testing,
et cetera.
Yeah, now you have to, you correct me if I'm wrong,
but when you started six years ago,
were you doing work in sandbox or is it right in production?
- Always in sandbox, always in sandbox.
- All right, I'm not sure I'll remember it quite that way,
but I'm-- - Just don't ask the 19
of the other people that are from the team.
(laughs)
- All right, well, and I think that's true of a lot of companies.
Right, a lot of companies today have developer,
developer pro sandboxes,
but they may not be using them
because of that complicated manual seating process,
we talked about earlier.
You know, these sandboxes, when you spin 'em up,
great, I got a brand new dev,
I got a brand new dev pro,
it's got all the configuration data from my production org,
but it's empty.
- Right. - Now it's up to me
to put in some valuable information to test.
And if I'm doing these two weeks sprints,
I gotta be doing that every two weeks.
That's where I think companies sometimes wrestle
with just keeping those sandboxes up to date.
- Exactly.
Partial sandbox, depending on your edition, is free, right?
But it's not anonymized.
So you do have to go in and mask some of that data
that's in there.
It's intended to be used as a testing environment.
It includes a copy of your, all of your orgs configuration.
However, it only gives you a sample of your production data.
And you can identify that by using templates.
You could use it for quality assurance testing,
user acceptance testing, integration testing,
and you can also do some training in there.
That could be refreshed every five days.
And it holds about five gig of data
and all of your files from your production environment.
And then we move to full sandbox,
which again is a paid solution.
It's intended to be used for testing as well.
But full sandbox to support more performance testing,
load testing and staging.
It's a total replica of your production org,
all the data, all the metadata,
files, attachments, everything.
But you can only refresh it every 29 days.
So if you're working in two weeks friends,
that might be a little bit of a challenge.
But I just also wanna know here on Sandboxes,
there's lots of enhancements coming and the recent releases.
There's things like Quick Clone, Quick Create.
There's some scale testing features
and there's more to come.
So please watch your release notes
because there's always some things happening here
in the sandbox world, which is nice to see.
- I see one of those was release notes.
You get so excited, you have to go through all 300 pages.
(laughing)
- Luckily they give us the hybrid versions.
(laughing)
- All right, so that's a lot of information.
Thanks for clarifying all those different sandbox types
that are available.
Can you walk us through how you establish a structure
for admins to isolate their work
until they're ready to merge into a team testing environment?
- Right, so using the native structure,
this is kind of what it would look like.
You would eliminate that full sandbox
if you don't have one.
Admin Sandboxes, which are the developer sandbox,
would be where each admin has an environment.
So I would have a sandbox, you would have a sandbox.
Everybody gets a car.
Once everything's tested, those changes get moved
into your partial sandbox.
And you can have users testing there,
you can do some load testing integration testing,
you could document your changes for training.
Load testing is really not ideal in partial,
'cause it is only a subset of your data,
but it's better than nothing, right?
And as admins, sometimes you hear these terms
like promote, deploy, change set,
there's lots of things to move changes
to sandbox to sandbox.
And there's lots of tools that allow you to do this.
Using code and repository and branches,
more formal DevOps processes.
But right now we're just focused on just moving,
moving that data from sandbox to sandbox.
- Yeah, I mean, we could do another two or three webinars
on all the DevOps processes, those tools.
There's a lot of third party apps that are available, right?
That it can assist with this, both free and paid.
And you can research things like Salesforce DevOps Center.
It's a good next step.
Obviously everybody in Salesforce says go to Trailhead.
Start with there, if you're not sure,
see what's available, actually learn the process.
I think when somebody looks at this slide,
they may go, wow, that's a lot.
And you're not saying that you have to do all of this today.
You can start with a single admin
in a single developer sandbox,
and then promote the production.
And you can add in these layers as the team grows.
- Exactly.
Salesforce, by the way, is introducing CodeBuilder, right?
Which is now in an IDE environment.
It's now browser based, where Visual Studio
is a tool that gets installed locally.
It's the newest tool, it'll be a managed package,
another managed package we gotta upgrade
in your production environment.
And once you enable it, you can then connect any sandbox to it.
And we're focusing here just on basic and simple.
Full teams would have multiple developers and admins,
QA testers, UAT happening, enablement.
You could have a formal Scrum team, ScrumMaster,
release managers.
I'm just really staying focused here
on getting kind of back to the basics.
Just the simple thing, right?
- Yeah, and I think the key point is,
as you're going through all these different promotions,
there is a lot of moving parts.
So this kind of goes back to what we were talking about earlier,
and only cover being in place,
then not just back up to production environment,
but all these sandboxes as you're moving through stages
of a project.
It's important to have those daily snapshots in time.
- Yeah, so let's summarize here.
If you're following some sort of print process,
which I hope you are,
once you're deployed to production,
your partial and your developer sandboxes
can be refreshed, receded and anonymized
for the next round of changes, right?
You really wanna focus on making sure
your production environment is as close
to your sandbox environments as possible
as far as the metadata is concerned.
And you should also have a refresh process in place,
some kind of refresh schedule, right?
Document how you're gonna refresh your sandboxes
and when you're gonna do that.
- Yeah, as we talked about earlier,
if it is a manual process, you're less apt to do it, right?
And you're gonna go with a month, two months.
I've heard some customers with full sandboxes
that haven't been refreshed in a year,
just because it is so cumbersome to get that done.
And I think when you look at like the own recovery utility
and getting those daily snapshots,
that's where the compare really comes in
because you can identify and isolate
what's being changed on a daily basis.
- Right, and you could have consultants working
in this sandbox structure, right?
And you really need to make sure you know
what changes they're making, right?
And making sure that your data is protected.
So I wanted to touch on testing, right?
It's really important to test with real-world data.
You know what you changed on the metadata side
and you know what to test.
But it's important if you develop a plan for testing.
You wanna make sure you're including positive
and negative outcomes.
If you're touching anything that touches an integration,
whether it's upstream, downstream,
you really wanna do testing with those integrations
to make sure that you're not breaking anything.
When you're rolling out changes,
you wanna make sure that your users know
how to use your new functionality that you're implementing.
- Yeah, I think, you know, testing is critical,
but also anytime you're doing any kind of new release, right?
You wanna get some of those users
into actually test out the application.
And we do that all the time.
We get the users set up in a sandbox environment.
They can add the lead, they can change information.
They can run an integration and actually see
how the data is gonna move.
And you know, getting those power users
in a sandbox environment is really important
before it goes to production, right?
Let's find those issues now
before we're actually releasing into our live environment.
- I also like to say, you suggested I made this change
so you have to help me test it now.
(laughing)
- Deal.
- You need to help them to document what they need to test.
They're not gonna know how you build something, but yes,
and users definitely should be engaged.
Another point I wanna make here on testing,
which often admins might miss, is monitoring, right?
Once you deploy a change, you wanna make sure
if you've deployed something that should be updating data,
that that data is getting updated the way you intended, right?
It's really great to create an exception report,
as an example, if you say this field can never be blank, right?
Create an exception report, right?
And subscribe to it.
If the record count is one, your criteria is not blank.
Boom, you'll get an alert saying,
"Hey, there's something here."
You might have missed something when you developed it.
It's really important to monitor for the success.
The last thing you wanna find out
is three months down the road, someone's like,
"Hey, there's a problem with our data."
And then you realize it's because you made a change, right?
You don't want to disrupt the business.
I'm constantly telling that to admins.
You don't want the business to come to you with a problem.
- I thought once you released your done,
you just move on to the next project, no?
- Exactly.
- All right, so let's celebrate.
You've just taken a stroke.
Yeah, you take a stroke a lot of things, right?
And as an admin, you do all this work,
but you really need to kind of track it, right?
You wanna look at reports, dashboards, show work,
that's waiting, that's being prioritized,
getting done, right?
What are you using to do that today?
- So you wanna make sure you celebrate your success, right?
And you wanna measure the process
before you implemented it and after.
You wanna document the changes that you made
to any process so you can show
what efficiencies have been added or gained, right?
You wanna capture the hours it takes
for you to work on those individual tasks
or those projects, right?
It helps show that the high effort projects
that were delivered and you can report that monthly,
quarterly, whatever the works for you or created dashboard,
but you wanna show what was done, what was added,
what's currently in the backlog by the priority.
And this all sets you up for your next review
beginning with the business,
so the process starts all over again.
This also helps to identify when you need help,
when I need to go to leadership and say,
you need to hire another admin,
'cause look at all this work and I can't get to it.
(dramatic music)
(upbeat music)