Description
Using Salesforce in financial services is a challenge: delivering business value, managing risk and scaling fast across complex orgs. Scaling at speed while maintaining control, compliance and confidence in every release is a high-stakes balancing act.
It doesn’t have to be. Join experts from Peoples Bank, Coastal and Gearset for a practical session on how a smart DevOps strategy empowers financial services teams to:
- Future-proof their Salesforce investment with scalable, compliant delivery
- Reduce operational risk through automation and guardrails that keep data and deployments secure
- Accelerate delivery by aligning deployment schedules with business priorities
You’ll walk away with proven frameworks showing how to turn Salesforce into a platform built for resilience and growth.
Transcript
Hi, everyone. Wanna welcome you all to today's webinar. It's scaling Salesforce and financial services, how to derisk, deliver, and drive growth with DevOps. I'm Jason Courier. I'm one of our strategic partnership managers here at Gearset. I'm gonna be moderator for today's discussion.
We're really excited to have you all with us today as we explore how leading financial services institutions are scaling Salesforce safely, efficiently, and with confidence. If you're working with Salesforce and financial services, you likely know how challenging this can be to deliver business value quickly while managing compliance, security, and your operational risk.
Today's session is all about some practical strategies that you can use, how to align DevOps with your business goals, how to automate safely, and future proof your Salesforce investment for long term growth.
We've brought together, I think, an incredible panel of experts who are leading these kind of transformations every day. First off, we're gonna start with Gina Rohnberg. She's the director of financial services at Coastal. Gina's background spans banking, lending, and finance law. As a former Salesforce product owner and executive leader, Gina's gonna share some of the lessons that she's learned from leading major transformation initiatives across many different financial services organizations.
You'll then hear from Nicole Bezarova. She's one of our sales engineers here at Gearset. Nicole has a super deep experience in Salesforce DevOps, helping teams accelerate delivery and strengthen governance through automation and scalable release processes. And then finally, we're really lucky to have Erin Weisenberger with us with today.
She's a VP of digital solutions at People's Bank. Erin brings over twenty years of banking experience and more than eight years of hands on Salesforce and nCino expertise, helping financial institutions scale with smarter, more efficient processes. She's gonna talk a little bit about her experience leading those kind of process improvements at PeopleBank. So we'll start by looking at some of the give you a sense of our agenda today.
Sorry. I I missed a slide here. This is our esteemed panel.
But we're gonna start today by looking at some of the key challenges that financial services teams are faced when they're trying to scale Salesforce with Gina. Then we're gonna move into some of the DevOps in action where Nicole will actually walk through a short demo with Gearset showing how automation and smart guide rails can make delivery both faster and safer. Then we'll hear from Erin's story at PeopleBank and finally wrap up with some audience q and a. So I encourage you to drop your questions in the chat as we go, and we'll collect them and start to answer those at the end.
So all of that is, like, some context for today. We're super glad that you were able to join us. Let's dive in, and we'll start with Gina. Gina, wanna take it away?
I think you're on mute.
There we go. Thanks, Jason. So excited to be here and join you all today. Hopefully, you can hear me well now.
Before I tell you about the challenges of working in financial services, and and specifically in the force ecosystem. Let me tell you a little bit about why Coastal is uniquely qualified to speak on that subject. We have over sixty professionals who are dedicated to our financial services practice, and many of us, like myself, come to this organization, as Jason said, as former product owners, as accidental admins. A lot of us came through financial institutions very similar to yours.
We have experience in banking and lending and wealth and insurance, and we bring all of that to the table. And that gives us a very unique perspective on financial services as it applies to Salesforce.
We're also passionate about leveraging the latest technologies like Gearset so that we can deliver those high value solutions to our customers in the most efficient way possible. So I'm so thrilled to be able to co present this with Gearset today. So what makes the financial services industry so complex that it requires these special balancing acts? As many of you know, it's a highly regulated industry.
For all of us, we we're struggling with balancing those competing concerns of maintaining that strict compliance with our regulations, but at the same time, being able to move quickly through the the process of delivery to our business units. The world is changing very fast. We need tools that are going to support the delivery of important technology to our customers, and at the same time, we need to maintain complex audit trails of every change. We have to have segregation of duties.
There has to be a a a clear process to ensure that our admins and developers who are all working as fast as possible to deliver those solutions aren't overriding each other's changes as they build more and more complicated solutions for your folks. And so with all of that being said, this is this provides tremendous pressure for us to deliver those solutions as quickly as possible.
What else is interesting, if you will, Jason, about financial services is that the data model for Salesforce itself is complicated. We're we have balancing acts of so many different objects and fields and profiles and security that deployments within Salesforce using standard tool sets are very complicated to manage. And so while it's important for us to maintain all of that complexity, we also have to add all those extra validation steps, which creates a lot of friction.
There's amazing functionality in financial services cloud, and not all of it fits into the standard Salesforce change set methodology.
I think of, in specifics, the OmniStudio components, which provide us with a tremendous opportunity to enhance your user interfaces as we build more and more complex screens that we can also expose to our customers in our customer portals. These things are tremendous, but they rely on data, not metadata.
And as any of you who've ever tried to build a change set knows, it's metadata that we use as part of that standard change set deployment tool. But we can't reach record based configuration.
They are incompatible with our change sets. A similar situation, which I know Erin is familiar with and will speak to a little bit later, is any of you who've worked in nCino, which is a loan origination system that is built primarily on record based configuration. And that's, again, a tool that or rather a a system that doesn't have adequate support in standard Salesforce deployments.
And so as a result, we have to go through a lot of complexity, which adds a lot of cost to our deployments.
Our deployments are manual processes. They can be error prone. And as a result, it's an all hands on deck event every time we have to do manual deployments. Right?
Everyone has to get there and and be on board to check all the configuration steps, which hopefully you've all been following best practices and keeping track of as you've been building, but we all know that things fall through the cracks. And so what we really need is something that's gonna provide us with a a tool that allows us to see where the changes were made, make sure that the right changes are making it into the system. Without that, our high value developers and admins are spending important time that they could be spent developing new new functionality for our business units, and instead, they're managing those manual deployments.
They're troubleshooting issues, and that just adds delivery time and overhead that's going to detract from the velocity that you're hoping to achieve in deploying your important business solutions.
So all of that complexity means that we have slower time to market.
So here at Coastal, we do recommend that we start to move towards a more robust DevOps experience.
And Gearset provides us with a best in class tool for Salesforce deployments that maintains those governance structures that are so important and critical to our financial institutions, at the same time aligning to our best practices and allowing you to rapidly deliver things with safety. So not only does it speed up our those deployments, but it also provides us with some invaluable analysis.
It actually allows us to see ahead of time where those validation errors are going to occur. We can provide some dry runs on our validations, and they're much more robust than what the standard Salesforce change set of validations look like.
It will preempt and tell us when we're about to make a mistake. And even before we try those deployments, we can visualize the dependencies that are necessary, and I know Nicole's gonna show you some great stuff there in a few minutes, we were able to see what are the things that are necessary to put into our packages as we start to do those deployments so that we're able to reconcile problems before they actually occur. So no big surprises on Friday night when you're scrambling to try to get that deployment out. Instead, we could all go home and have dinner.
We can but get those deployments out much faster. And at the same time, we've got tracking and traceability that is so critical, that audit trail for our auditors to know who's been making changes and where. We have the segregation of duties that are is necessary to ensure that we don't provide access inappropriately to people to different levels of deployments. And so this is now a system that provides us with the opportunity for growth.
If you're a two billion dollar credit union and you're just getting your feet wet in the Salesforce ecosystem and you found that change sets don't satisfy your requirements, this is a tool that's gonna assist you. But at the same time, as you're evolving and you're reaching that ten billion dollar mark and you're being subjected to higher and higher levels of scrutiny, this is a system that's gonna continue to evolve with you as you move through that. I like to call it the crawl, walk, run of the DevOps experience. And I know Nicole is gonna do a fantastic job of walking us through how we mature into that true CICD process where multiple groups can all be coexisting, building collaboratively, deploying solutions as quickly as possible.
So with that being said, maybe I'll turn things over to you now, Nicole, and let you get started because I know a picture's worth a thousand words for me, and I just wanna see demos. So let me let Nicole show you what it is I've been talking about for the last few minutes.
Perfect. Thank you, Gina. Yeah. So I think the most important thing, as Gina said, is really the balancing act.
It's between ensuring that you've got your security and compliance in place, but also delivering quickly. And I think something that maybe a lot of you are thinking is Salesforce already has represented a pretty significant financial investment. So it's easy to wonder why you need to spend even more to accomplish that. And unfortunately, it's just because, as Gina said, the native tooling isn't enough.
And if we take a pretty simple example of why not, it's clear from the evolution of the Salesforce platform recently, you know, with Agentforce, with Data Cloud, that we're moving more into the world of automated AI agents and centralized data. And that starts presenting enormous risks. The risks almost that I'd say grow exponentially because you need to ensure then that you're planning all stages of your Salesforce DevOps. When you're planning, when you're building, testing, deploying, you're monitoring, you need to make sure that that data is safe.
And it's simply not possible with change sets.
However, the good news is, and reason why I hope most of you have joined this webinar, is to see how Gearset can help you with your DevOps journey. And the good news, like we said, is that even if DevOps is completely new to your team, Gearset can support you in that DevOps maturity process. So I'll go ahead and steal the screen from Jason. I think you can now see something else.
And like Gina said, what we really wanna focus on is this crawl, walk, run approach. So regardless if you're just starting out or if you have a team of fifty developers that have all used get their entire lives, Gearset can derisk your Salesforce deployments and development from day one. And that's a pretty lofty claim to make, so I'm sure some of you are wondering, well, how can that be? How can it be so quick to implement?
And the reason why is that Gearset is a web based tool. So what that means for you is that you simply need to connect your Salesforce environments, your sandboxes, your production orgs via OAuth to Gearset. And that is it. Once you've done that, you can start using Gearset to solve your DevOps challenges within minutes.
But as Gina said, there are additional layers to consider. Connecting those orgs is step one, but we also need to consider with financial service the separation of how do we make sure that only the correct people have access to the correct environments. So once you add those orgs to to Gearset, I suppose there is an additional step of creating those roles, making sure that you're really tightly locking down who can access what, and ultimately moving towards a world where you're really reducing how many number of end users have actual direct production access so that you ensure that if anything is in production, it has gone through this deployment and auditable process that we're gonna take a look at now.
So let's take a relatively, I guess, common use case. Let's say your team has spent some time building some new development in a lower sandbox. With Gearset, you'd simply select that sandbox as the deployment.
So I will take my and now you're ready to take your integration for your end users to start testing it, getting some UAT out. So we simply select that as the target.
Now an important thing to think about here is ROI. And to get the best ROI from Salesforce, it's really about getting this new functionality into the hands of your end users as quickly as possible while still balancing it and ensuring that risk is minimized.
A fun stat that I like to share is that on average it takes Gearset customers around thirteen minutes to deploy, well sorry, to identify and select their changes, and after that we have a ninety eight percent successful deployment rate.
And this speed and this accuracy, as I'm sure some of you are also thinking, that's not possible. The reason why we can do this is because of what you're about to see, which is Gearset intuitively visualizing your development and how it all links up together.
So what we'll see as soon as we start this comparison is immediate visibility into the differences between your dev sandbox and your next integration or UAT environment.
So here is an example of a static resource that looks relatively normal here in my in my sandbox and quite funky here in my next environment, but side by side visually visually rendered for me.
You'll also see that Gearset highlight any new, changed, and deleted items, which unlike change sets are fully supported, those destructive changes. But importantly, for your auditing and SOX compliance, for every single item, you can see who made the change and when it was made as well.
So if we zoom out again and we think about the sandbox, you maybe built a flow. You've been working on a flow update there. As we know, flows are of course only getting more and more powerful. They're handling more and more critical business processes, and that of course means that the risk of deploying them is also growing. So with Gearset, if we simply search for the name of the flow that I'd like to deploy across, we'll immediately see that Gearset will visualize this flow for us. So it's calling out on the left hand side any new, changed, deleted elements, and we're able to very quickly understand exactly how that element has been updated.
Here, the purpose really is to make sure that you're selecting the correct version of the flow that you're trying to deploy. And if you realize, oops, there's a test loop in this. This is definitely not my correct version. You can even change that flow version directly.
That visibility is really crucial to ensure that your team is deploying the correct development each time.
But to help you derisk your deployments even further, on top of just visualizing the changes, it's also crucial to make sure that you include all of that related configuration. Minimize your deployment failures, make sure you're testing your actual full development. And what Gearset will do to help with that is show you your full dependency list. So for example here, Gearset's showing me that my flow depends on a couple of new things, a custom field and an Apex class.
This again gives us that visibility to make sure we include these, but if we forget, Gearset will also give us a safety net and tell us, hey, we've got some suggestions for things you should include in your package, and we'll tell you exactly why we think that you should include these.
This, you can see, is even bringing in some nested fields that weren't immediately visible to me as well. And this is really the core reason why we have that ninety eight percent successful deployment rate, because this happens even before you validate. You're building that successful package first time.
So we'll help you, obviously, here accurately identify your development and bring across the relevant changes. And the key here really is relevant because a very common risk that we hear is if you're working on shared metadata, shared sandboxes, accidentally deploying work that's not ready for testing or having to delay your releases significantly waiting for it to be done. So for example, I'm sure you've all experienced this with things like permissions and profiles and layouts.
In this case, Gearset does not just visualize these for you, but it also helps de risk by allowing you to be able to pick individual sections. So if I take a profile that I have got here, you can see that Gearset quickly shows me exactly what the differences are between the environments, but I don't need to deploy the entire profile. I can deploy individual field level securities. And this applies, of course, to permission sets as well. This also applies to pretty much any metadata where this makes sense. So similar layouts or lightning pages, very very common where not everything is ready to go. You can see here, guess it will visualize it for you, and you can take individual things like visibility rules, making sure that not only do you have the knowledge of what's changed, you have the control over what you're deploying.
But the the savvy among you might be wondering, okay, but so far we've been looking at metadata. Obviously financial services like Gina said, OmniStudios is crucial.
For those of you that might have newer orgs, OmniStudios is luckily now regular metadata. So as Gia said, we've just seen it will basically be able to handle it in exactly what the process we've looked But for the majority of you, especially if you've been in financial services for a longer time, OmniStudios is still unfortunately data. It's that record based configuration.
And typically what that means is right now you'll have to be using two split processes. That adds of course to the complexity and the risk of the auditing and controls that you need to do.
But the good news is with Gearset, you can deploy OmniStudio's data through exactly the same process as we've already seen. So even though OmniStudios is data, Gearsup will treat it like metadata.
So here, for example, I've got a comparison. It's got some metadata in it, but I will also be able to immediately look up and say, well, I've got a new OmniScript that I want to deploy. And we will see exactly in the same way the side by side differences. So here it's a new OmniScript. It's not comparing against anything in the target.
And on top of that, which is really crucial for OmniStudios, is the dependencies, the relationships. And that's especially important, I would say, here because there is no concept of validation. So the only time that you'll know if you've forgotten something is once you actually go to deploy and have it fail.
So Gearset will instead show you, okay, for this velocity OmniScript, there's further dependencies on an integration procedure, a data raptor, and even showing you the dependencies between the data and the metadata, which can be deployed all at the same time.
So, crucially, really, what this does is give you a single process regardless if you're using OmniStudios as metadata or data, And that ensures that no matter what you're deploying, your team can understand their changes intuitively. They can select just the sections that are ready for deployment and have Gearset automatically select suggest any things that might be missing to derisk that deployment first time.
So anything that's left for us is to continue ahead with our deployment and to deploy it. We can see here what's in my deployment package, and I can even have Gearset save me further time by automatically detecting relevant unit tests to run. So again, managing that risk without having to slow down by running absolutely everything.
Now I'll go ahead and validate for our purpose here. But if we talk in deployment and we've successfully deployed these items to integration, one key thing is if you're deploying Omniscripts, Gearset will automatically activate those Omniscripts automatically. So like Gina said, one less manual step to try to keep track of.
But if we imagine we've deployed this to UAT, you've had your users test it, everything's passed, you're now ready to deploy it to production. You do not need to waste time recreating the change set and opening up the risk that you might once again forget something or create the package in a slightly different way which will of course have very big consequences sometimes.
Instead, Gearset is going to keep an unlimited history of every single deployment that you have done. And what that allows you to do is first of all have that audit trail built in so you can see exactly who deployed, when they deployed, seeing exactly line by line the differences that were deployed.
But from this history, you can also quickly reuse that change set. So simply selecting a new environment, new production to deploy this exact same package to, ensuring that what you've tested in UAT is exactly what is going forward to production.
Of course, if certain features didn't pass testing, you also have the flexibility to update the package, remove certain things as well, so it's not to say that it's set in stone.
But the really important part here is that this unlimited audit trail also the ability if they're to roll back that deployment. And this means that you're not just removing everything that was deployed, you really again have that fine grained control. So if you deployed five different things, four different sections to a layout, you can roll back just one. It's really again about controlling what you are removing just the same as it was about controlling what you're putting in.
So have seen from this part of the demo that there's the single process for your metadata for your Omni Studios as well. But of course, for some people, as we mentioned, they are using other record based configuration like nCino. And for that, we offer our flexible data deployment tool that will essentially allow you to create templates, which would allow you to repeat your data deployments, your data configuration with just a few clicks. It will help automatically detect relevant parent records and just making sure that you're bringing in all of the records that need to be deployed.
But at the beginning, we did talk about our crawl, walk, run approach. We've seen how just by connecting your orgs to Gearset, you can immediately benefit greater control over deployments, your automatic auditing, and your rollback capabilities.
But as your team grows larger, your development becomes more complex, Gearset can also support you and grow alongside you in your DevOps maturity. So once your team does reach a certain size, this manual org to org deployments, they become more and more time consuming and risky. You start seeing things like overwrites. You start seeing things like environments getting out of alignment. You start seeing a lack of process, a lack of peer review, and that's really where Gearset's pipelines comes in and exactly what it was designed to solve.
Because what this does, from a glance, is give you immediate visibility across your entire development pipeline. This is of course gonna be created specifically to your environment so you can edit, add environments as you need.
The important thing here is that these environments is are all underpinned by your Git provider. So whatever you use internally, GitHub, Bitbucket, ADO, GitLab, what that means though is that all of your development can be automatically tested and tracked in a way that's not possible when going org to org.
And for those of you that have maybe never used Git, you might be thinking, well this would take too long to implement and understand. But the good news is that this is actually modeled after change sets, So the process is very very similar to what we've already seen.
So if we take my example, I've got a few different work stream. I've got some SIs developers working externally, some internal developers. This is where the work is still done, same as before sandboxes.
The development is then taken from these sandboxes and saved very much in the way that we just saw, except instead of going org to org, it's saved in branches.
And then those are requested to be moved into your next environments, these green boxes, which are your shared sort of integration and testing environments. And that's simply what these numbers represent. How many features are waiting to go into each environment? And so you can immediately see that this gives unproved visibility over the process that we've already taken a look at, but it also brings across greater control.
Because for every single feature, there can be automated quality gates to ensure that the work, for example, can be deployed. So checking out, well, will this actually successfully validate and deploy to my target integration environment? Are the unit tests passing? Also starting to check for things like, will my work overwrite somebody else's?
So for those larger teams, making sure that you're not doing any risky overwrites.
But on top of checking if it can be deployed, it also crucially checks if it should be deployed. And this means automatically reviewing all of your development to Salesforce's well architected framework.
It's not just looking at Apex, that's the kind of easy fruit, but also the declarative too. Because if we talk about flows, those can be very, very powerful. So you do need to make sure that there's some automated architectural peer review, making sure that your flows are built to best practice. And so what I can immediately see is if I open up my section, my work is introducing a security vulnerability which can block me from deploying this until it's addressed.
Of course, we've said the Salesforce platform updates a lot, so does the Gearset plan of the benefits of being off platform. So as soon as Salesforce updates their platform, we update ours. And what that means is, for example, a month or so ago, we released new agent force rules, enforcing things like agents having guardrails, and really just ensuring that your team is always working from the most up to date architectural standards because that's where a lot of the risk can come through is the platform updates and you just haven't quite caught that.
But if all of these automated quality checks pass, then those users with these specific assigned roles can simply take the features and deploy them to the next environment. You can see that they're all fully independent, and once they're deployed it will automatically kick off any UI tests and request moving them to that next environment.
We'll just quick kick off any of your quality gates again. So that's really how your deployments will move up the pipeline in this way, moving from the dev sandboxes up into your final waiting to go into production, at which point you can deploy them one by one, or you can combine them into a release where all of that development will be validated and reviewed together. And if everything's passing, you can schedule the deployment. So like Gina said, minimizing the impact on the business and really minimizing that risk.
So we have seen how this second crawl walk approach ensures that all your development is automatically validated and reviewed. It follows a specific process as it's deployed from your lower environments up to production.
But what I'm sure a lot of you have also seen is you don't always have time. You don't always have the resource to follow this regulatory process. Urgent changes are sometimes necessary.
For some of you that might mean being able to make changes in production. For most of you, that means having to make them maybe in a hot fix sandbox and simply deploying those to production to urgently fix something.
But of course, as soon as you do that, that hot fix is no longer present in these lower environments and that introduces the risk that any testing or development you're doing down there simply not accurate. So instead, as soon as you do a promotion or deployment to production that's not present lower down, Gearset will automatically open back promotions to ensure that you sync down these lower environments, ensuring that all of them, even the developer sandboxes, stay up to date with production without overwriting any work in progress.
So we've seen the first two slices of crawl, walk, run approach. You might wonder what run is and what I could possibly show you in the next five minutes. Well, once you do have this automated pipeline in place, the next level is simple. It's starting to think about your entire Salesforce system.
It's not just about the deployments anymore. It's about what happens afterwards. So things like being able to proactively monitor your production org for Salesforce flow and Apex errors, being able to see how many users have been impacted by these, keeping an eye on API limits, keeping an eye even on your data and file storage, and if this is hit, being able to start thinking about how do we actually help clean up the performance of this org. That's where you can start looking at things like backup and archiving that Gearset can do to help bring your storage under control and to help ensure that if there's ever a disaster, you can reliably recover any business data.
And I would be remiss if I didn't mention our newest product as well which is org intelligence. And this kind of paradoxically comes at the very beginning. Before you do any deployments, before you even start development, it will help you plan.
So what it will do is it will plug right into any org to give you an understanding of that org structure. So if you're about to start development on a part of an app a part of the Salesforce app you haven't really dealt with much before, you want to minimize that risk. So what Gearset offers is an optional AI feature here where we can ask any question about this org. For example, what automations trigger when an accounts industry changes?
And this combines Gearset's deep knowledge of Salesforce metadata, as we've seen with how we understand the relationships and the object models, with your org specific structure. So you can take, for example, even copying tickets, ticket requirements directly from book items directly into here to help you understand how to best implement your development, ask any questions, and again everything that it says will be specific to your actual org structure.
So rather than relying on one or two architects, if you're lucky, with a siloed knowledge, everyone on the team can get answers, new joiners can get up to speed quickly, and we can minimize the risk of breaking critical processes because we can very quickly jump into this flow and understand not only how it's structured, but all of its references, what it references, what it's referenced by, any of those permissions, even have Gearset generate documentation for you to explain how this feature currently works. So again, you're building that into your process to minimize risk before you even start the development phase.
So really, we've seen quite a lot today, but if I leave you with one thing, it's just that from day one, if you connect to Gearset, you'll have better control and security. But as you want to evolve with your DevOps maturity, Gearset is here, and Gearset can help support you as you start introducing Git and then as you start considering absolutely everything in Salesforce DevOps.
So thank you. I'll stop sharing my screen now for the demo portion.
Thanks, Nicole. That stuff is amazing, and I can speak to the fact that gear is continuously evolving and continuously improving, much like we all wanna be doing with our Salesforce orgs. I've watched as as Gearset has grown over the years, and it's incredible to see some of these AI opportunities coming up. So, Erin, perhaps we can turn our attention over to you right now and understand a little bit more about your journey and how you've been evolving with Gearset.
Absolutely.
I have been in the Salesforce ecosystem for about eight years now and in banking for around twenty, as Jason mentioned in the intro. And so with that, I've had the opportunity to be on the, client side for five years at another financial institution, and then I moved two years into consulting and now have been back on a financial institution side for about a year now. And in that journey, I've been able to use Gearset here at Peoples as well as on the consulting side.
And that's been a very beneficial tool that we've had in our tool sets. Peoples Bank has been using Salesforce for about a year and a half now, and we've been live within Sino for about six months.
And I joined Peoples about a year ago, and we were moving out of project with our initial implementation partner and moving to doing more of our own development and realized pretty quickly that the tools out of the box really weren't going to be sufficient to make our process as seamless as it could be. And so we started talking to Gearset about how they could use we could use their tools to help us move our processes forward more quickly. As Nicole and Gina have talked about, there's a lot of ability to scale in those tools, and the ability to see those comparisons and visual has been really beneficial for the team.
Yeah. So so what are some of the features within Gearset that you've been taking advantage? You spoke about the comparisons, like the visualization of the flow that we just saw with Nicole. I I know looking back, I remember when we used to just see the metadata, but to be able to see it as graphical representation. How have some of those things made a difference for you folks?
Yeah. The I love that the visualization of the flow has colors too. I don't know if you caught that when Nicole was showing, but a new element's green. A changed element is yellow. So you have even that indicator within that picture of the areas that you need to pay attention to.
Where we are as an organization right now, we have a small team, and I'm primarily handling the deployment for the team. So often, I'm deploying someone else's work. And so the ability to have that visualization of where the change is and have a little bit of that tech review before we move it forward to the next environment allows me to review what my teammates are doing and making sure that we're following those best practices. Although Nicole's given me a few ideas of how we could be doing that better, with some of the other features as we continue on our journey.
I love it. That's terrific. Yeah. And so, where are you at on your journey, speaking of?
Are we crawling? Are we walking? Where are we at with GitHub? How are we feeling about that stuff?
I'd say we're still mostly in the crawl phase working to get to that walk phase. We've started to use some of the Bitbucket repository for doing that better process of checking in the changes, moving towards a better process, but still a little bit in that crawl phase.
Yeah. It's important, but it does take some time to adjust. And it's terrific that you've got you know, that you're moving down that journey as as quickly as possible.
How has this tool really made a difference for you from a record based deployment can standard standpoint?
Yeah. As I mentioned, we went live with nCino in May of this year, and so we are quick followed, added in a new template, for spreads. And if anyone has worked with n c no spreads, it's about fifteen different related objects that are all data record based configuration. And so that allowed me to deploy those changes and bring those related records into the production org without having to recreate that manually, which definitely saved us a lot of time getting that new functionality to our users. That was a fast follow from our go live, a recognition of a business unit that needed a little bit different template. And so we were able to get that created in the sandbox environment and move that data deployment to production.
Yeah. And and as, like, the the lone admin doing the deployments, having the ability to do it quickly and making sure that it's effective. Otherwise, you're you're worrying about what did I miss. And here, I feel like you've got so much to back you up if you are just that that solo admin running all around at night trying to make it all work. So that's fantastic.
So no more sleepless nights on Fridays for you, Erin?
We try not to do our deployments on Fridays. We usually target for Monday, but no sleepless Mondays.
No sleepless Mondays either. That's fantastic. So anything else that you'd like to share with us about your gear set journey that we didn't get to touch on?
Yeah. I would say the the biggest piece that is beneficial for gear set to me versus change sets is the ability to move a part of the development, what Nicole touched on of that Lightning based configuration or Lightning record page configuration or a permission set where we have multiple teammates that are doing some developments. We are very much a newer shop, as I mentioned, about a year and a half into our journey. So we use a lot of dynamic rendering on Lightning pages, and we use primarily permission sets.
We don't permission for fields or for objects on our profiles. So those shared permission sets and shared Lightning pages are a better experience for our users to have that. But oftentimes, we find a business unit that may be working really quickly with us and testing really quickly in another business unit that's dragging their feet a little bit, and it's a little bit more hands holding to get them to the UAT org and get in and get their testing done. So we don't have to hold one business unit back if the other one is not keeping pace on that when we're using those shared components.
And that has been really powerful.
Yeah. Letting letting people leapfrog over you and not having to hold back on deployments just because somebody can't get their testing in order or they hit bugs, that's amazing. It's a huge win. Huge win.
Fantastic. So I I wanna make sure we leave some time if we need to for any questions that are out there. So I think if Erin, unless you had anything else to add, then maybe we'll switch over to q and a.
I'm good. Let's go to q and a.
Great. Thank you, guys. This was wonderful. I think we've got a few questions that have been going back and forth on chat, see. That's really great. Thank you for sending those questions in. I guess maybe there was a general question I saw come through a little bit earlier.
Maybe I can kinda kick this back to you, Gina.
When you're kinda working with some of the financial institutions that you've worked with, I mean, can you give people some best advice, just the best way to manage complex financial services clouds deployments, especially when you've got dependencies or tools like Encino that you mentioned earlier?
Yeah. Sure. I mean, I I think it's everything we've been talking about right now. You know, having a tool set that gives you that ability to visualize the changes, adhering as much as you can to the proper structure of having dev sandboxes that move into an integration environment, that move into a UAT environment, and then eventually make their way to production and ensuring that your changes are truly following that left to right functionality.
It's really critical so you keep all of your sandboxes aligned. And so, you know, you're able to prevent those gotchas when you go to production and you inadvertently take something along for the ride. It's so important, particularly because of the pace of change that we need to operate at. You know, we're we're operating now so quickly.
Technology is evolving so fast. AI is moving the needle ever so quickly. So it's really important that we adhere to the discipline as much as we can even in the the newer crawling organizations that we we maintain that structure. And I think that gear sets, pipelines, and and all of those tools we've talked about do a fantastic job of keeping us aligned to those best practices with the minimal pain possible.
So Great.
Yeah. Thanks for sharing that. Nicole, I do see a question just came through from chat. Maybe you can help. This one came from Umar. Any plans for automating back deployments? How do we handle back deployments across all of our orgs?
Yeah. That's a very good question. As you could have seen from the demo, there's a part here of manually checking that the quality gates are are met. And one of the things that we've heard from our largest customers is that that can take some time when you're scaling.
So one of the things that we've are actively in development now, and I believe, Umar, it's actually in closed pilot at the moment, is something called continuous delivery, which not only for the back deployments but also for the forward deployments allows you to set the conditions upon which as soon as they're met, you do the deployment automatically. So an area where this will be very helpful is for the back deployments because as soon as you make a hotfix, it will essentially backpropagate that automatically. So right now, closed pilot. I'm not entirely certain on the release date because we're getting feedback from our from our users, but I would be surprised if it would be more than the end of this quarter.
Cool. Thanks for sharing that.
There's one more question I'd love just to maybe wrap up by asking you, Aaron. I know you alluded a little bit to this in your conversation with Gina. But, I mean, if there was one of the biggest differences that you noticed from moving away from manual deployments at People's Bank, I know some of the people that are joining us today may be still using change sets. Is there anything that maybe you could share with them that might be valuable or or be useful for for their journey?
I think the biggest two pieces that I really love about gear set over change sets is the ability to pick the pieces of the puzzle that you wanna move. That's critical to being able to move agile, move quickly to solve the shared components struggle that you have with change sets. And then the other piece is also what Nicole showed of being able to take that already put together change set and move it to the next environment. So moving up your development chain and having that already put together so you're not spending time twice assembling that package is definitely a big win.
Awesome. Thanks for sharing that too. It looks like we do have another question coming in. For nCino RBC deployments, are there out of the back out of the box templates, sorry, for those changes that come with Gearset? Or will those be be built out manually, Nicole? Can you answer that one for us?
Yeah. Absolutely. So for most of the record based configuration, we don't provide templates. And the reason is simply that it's so specific to the orgs.
So really, when we did try that out as an exercise a few years back, it just ended up causing more failures than than fixing anything. What we do offer though, is when you build out a template, and if you've ever used Gearset before, you'll have seen this, is automatic detection of relationships. So being able to bring in the parents without having to think about how they relate to each other. So it is very much a building it out to your specific org structure.
But like Erin said, once it's built, you save that, then it's repeatable.
Love it. Great. I think we're gonna wrap up on time here. So I wanna make sure that we're mindful of letting people loose.
I think this is a great conversation. Thank you, Gina. Thank you, Nicole. Thank you, Aaron.
You guys were amazing. I think you shared a lot of good information for people who are joining us today. If you'd like to learn more, you can use our QR code here to actually book a consultation with any of us. So please, by all means, take advantage.
If you'd also like to learn more about Coastal, you can visit their site. It's, sorry, coastal cloud dot u s, or visit us at gear set dot gear set dot com if you'd like to learn a little bit more about Gearset and our solutions. But just wanna say thank you again to our esteemed panel. You guys were all wonderful.
Thank you for sharing your experience with us.
Thank you everyone who joined us today. We're really grateful for the opportunity to share a little bit more about us and about Coastal. And, Erin, thank you for sharing your story. We're gonna wrap things up today, but know that if you have registered, you should be receiving a recording of this session.
You can feel free to socialize that with some of your colleagues as well. Thank you again, everyone. Have a great rest of the day. Appreciate you joining us.
Take care.
