Description
Catch up on this panel discussion following the release of the 2024 State of Salesforce DevOps report where Rob Cowell (DevOps Advocate at Gearset), Jolene Mair (Salesforce Application Engineer IV at Hacker One), Oscar Hemmelgarn (Salesforce Development manager at Arvest Bank) and Nimisha Prashant (Technical Architect at Salesforce) discuss four key Salesforce DevOps themes for 2024.
This year’s key themes include:
- Salesforce DevOps being democratized
- Migrating to permission sets remaining a high priority
- Compliance requirements are on the rise
- Salesforce-specialist backup solutions offering the best protection
Learn more:
Related videos:
Transcript
What we want to cover in this panel is a deeper dive on some of those themes that Jack was talking about there. So some of our key findings that we kind of saw across the report And the best way to do that in our opinion is to get some real world examples from real end users like yourselves.
So without further ado, I'm going to invite our panelists to come on to camera and, we'll start working through introducing folks So welcome, folks. So first up, we have Jolene from hacker one, Jolene is a Salesforce applications engineer over there.
So Jolene, tell us a little bit about, your world.
Hi, everyone.
Yeah, my one was a bit different from what I used to have. So I started at Hacker one as the applications engineer for Salesforce, and the majority of our team are low code, low code, We had no dev ops process prior, not a a very robust one, and that's where a gear set came in and really helped us speed that along, so it wasn't a very painful process. So it's to start to adopt that, and adopt it in a nice way as well. It wasn't particularly painful for us to do. So, yeah, so what else?
Fantastic.
And then next up, we have Oscar. So Oscar is the Salesforce product development manager at Harvest Bank over in the US.
Oscar, tell us a little bit about yourself.
Thanks, Rob. Oscar Hamilton Garn, development manager, Arvest Bank, I have the technical responsibility for the Salesforce instance, at Arvesta prior to jumping on a gear set last year, we were doing the old school change. That's very admin heavy, in that sense, not a lot of DevOps process at the time.
But we're quickly, growing that practice, especially around the sales forces. We continue to grow out the platform previously at a previous company did really the same thing, started off looked at, gearset identified, hey, this is really easy to, jump over that barrier of entry and not have to have a large team to set up the whole practice and, you know, it's good to see that grow previously, continuing to work with former coworkers and friends there as well. And I'm watching that. It's gonna have same thing happen at our best bank. So, just excited to, just take part in it.
Fantastic.
And then last but by absolutely no means least, we have Namisha, who is a technical architect at Salesforce itself.
Namisha is, very kindly joining us from Salesforce. Tell us a little bit about, some of the things you're involved in.
Absolutely. Thanks, Rob. So I kind of come with say about a decade of Salesforce experience, in Salesforce consulting.
Been with Salesforce for about two years now, but, I think I I have specialized now myself in the Finzerve sector at the moment contributing to the insurance industry and the specializing those kind of digital transformation projects, just involving myself in the in in building those, you know, policy admin systems. And I've seen the transition over this decade from, say, and based, migration tools to actually now fully automated, all all admin kind of tools for for migrating, of a deployments, etcetera. So very excited about dev ops and then how AI brings it more forward and accessible to everybody. So looking forward to this discussion as well.
Fantastic. Yes. And we're definitely gonna revisit that, that seem of accessible to everybody shortly.
So that's our panel. And I always like to to put our our wonderful guests first.
But as for myself, I am Rob Cowell. I am the other DevOps advocate alongside Jack over at gear set, and I shall be hosting this panel and hopefully coming up some some good questions that we can start sort of dissecting some of those key things that we found in the report.
So let's get started with that. And as Namisha kind of said there, you know, a big theme of the findings that we had is that accessible to wall principle, as Jack phrased it, you know, dev ops is being democratized. So it's not just for folks that, that that specialize in DevOps. It's not just for the developers, you know, there's definitely a room for everybody to have a stake in the successful delivery of Salesforce projects.
So I'm gonna start sort of exploring that with the panel. And, Jeremy, I'm gonna start with you. So If you were an organization that was looking to sort of achieve that level of democratization and making sure that DevOps is a a team wide a team sport, if you will. How would you how would you start approaching that?
I think the first thing would be speak speak to your team. Find out what what about the current process is painful? There's no point in adopting anything if it either one makes it just as hard or two just gives you a whole set of new problems to work with.
There's tools out there, gear set being my favorite. As an obvious choice, but there's tools out there that will make it easier for you. There's tools out there that everyone can get on board with. And if you speak to your teams and get them involved in the process, don't leave them till the last minute and then say, okay, this is how we're doing it, get them involved from day one on those initial calls so that they can field those questions out themselves.
Absolutely. And it's it's definitely one of the things that we always like to, remind folks of is that, you know, DevOps is eighty percent that team culture and probably twenty percent of technology and tooling. If anything, those those percentage might even be, you know, underestimating that the importance of culture there.
So Oscar, I mean, obviously, you're, in a a bank, which is typically a a more regulated industry for these types of things. So how have you seen that impact, the ability to kind of democratize and kind of roll out DevOps when everyone has kind of different roles. And sometimes there can be, a few of those silos and separations of duty in in regulated industries.
Well, it you know, with DevOps, everyone, you know, still needs to play a part even though that separation of duties isn't at clear as it once was, you know, everyone, and we try to simplify it as much as we possibly can, into that process to really help Dubai in because once people that, you know, you know, not focusing on the technology, because you could get down on a rabbit hole there, but focusing on that culture and that performance and understanding, well, this is the role we're gonna play, this is the role we need help in, you know, and let's let's get together and making sure that we're doing that outside of the technology, gives more understanding and buy into some of those other departments where, compliance or those duties and oversight may come into in the highly regulated industry like, financial services or banking.
And it, you know, once they once they understand and feel comfortable, then everyone can just jump in and as if we're necessary and move things forward as we were hoping and grow.
That's fantastic, you know, and I I love that, you know, it allows you know, disparate teams to become empowered, you know, to kind of manage their own destiny of of changes, really. It's it's great to see it in the wild.
Now, obviously, since its inception, Salesforce has kind of positioned itself, as a very strong low code, no code platform.
You know, some of this that'll be, you know, longer on the platform, remember the, you know, the no software logo, which we don't see quite as much the East days, but, it is a staple of of the Salesforce way. So with that, Lemisha, I'm gonna turn to you as a as our representative from Salesforce. You know, how was how does empowering some of those no code or low code team members really benefit the the wider team across the board?
Yeah. Sure. So, I think no core team members, and I sales force definitely promotes a low code environment. So it's it's it's empowering basically, say, for example, business analysts or administrators to actually start developing upfront. So, when doing things like prototypes, that feedback loop becomes even smaller and quicker. And all team members then become, a contributing part to the the actual success of the project and just involving everyday member just means that that kind of development life cycle much more, quicker and, basically also fosters a sense of, you know, making it available for all and everybody can contribute and having that kind of, engagement from the team.
And with even with, say, the this the insurance industry that I'm in at the moment, with things like only studio. It's just what you see is what you get. It becomes accessible to everybody who's able to configure and see it in real time as to it. It's no more dependent on actually having, a posh LWC developer to be able to actually configure a fancy looking page, etcetera.
So definitely empowering those low low or no code team members than just gives them that that kind of, it's it's almost like on all hands on and just getting, the the business value delivered much more quicker.
Absolutely. I think you've hit the nail on the head there. It's like, you know, everybody's contributing to deliver that value and, you know, by democratizing that dev ops, potentially, you know, we removing some of those barriers, you know, and when Jack talks about some of those metrics, like the, you know, the lead time to delivery, we could definitely see some improvements on that because those barriers have been dropped.
Now Speaking of barriers and, you know, it's one of the things that that has been picked off in our survey results is that a lot of people seem to have this mental block or this reticence to, get too much involved with profiles and permission sets. They're notoriously tricky.
And it is obviously something that Salesforce have have recognized, and there is definitely a a shift towards, getting people using permission sets permission set groups, you know, and those kind of related areas, and start kind of thinking about the way that we can restructure, that. So we definitely saw, you know, the need to do that as a priority.
So again, you know, this is something that is something's being pushed by Salesforce and encouraging, you know, all the trailblazers to to start moving away from putting everything security related in profiles. So I'm gonna stay with you for a moment, Demisha, because you are from Salesforce, and you you kind of have the, the inside track a little bit. I I'm appreciative, you know, that there are road map things that you might not be able to cover.
But in a nutshell, I guess, why why is this you know, why is it so important for people to start moving from those profiles to membership sets?
So I think the whole structure of profiles, so over over the years, we've, an admin that would have stayed as long as I have, been in the industry would have seen that profiles was the key approach to actually putting in any permissions, but then that easily became quite complex and, you know, and we really need to actually manage because these are XML files in the background, and this just just grows and, overriding and merge conflict became really complex to manage. And then, obviously, a profile would have a lot of permissions. And the similar cohort would have another, similar set of permissions, and then this kind of extensibility because the profile is basically tied to a user. So it's it's telling you what the user baseline is and permission sets then probably can top it up with the next level to actually give you the level of details as to what this particular user or user group can perform as as their activities.
So I think that kind of lacking granularity became an issue with pro profiles and permission sets granted exactly that And, you know, giving that kind of modular approach to permission sets basically involves the administrators or, just help allocate those specific permissions to those individual users or group of users. And just, I think it's not just in essence. It's not just about, you know, just the permissions or about the compliance of keeping up with Salesforce's directives for, if if it's towards end of life etcetera. And so it's a future proofing, say, at access control strategies and being able to be, to empower our teams, or admins to adapt and thrive in this kind of, Salesforce administration where they have the ability to design what a user's access looks like and and not falling in the pitfall of actually giving extra permissions and adhering to the principles of things like least privilege, just ensuring the right set of permissions that a particular role needs to perform their essential tasks.
Yeah. And I think that's, you know, a very good sort of architectural approach to take not just as permissions, but everything just kind of modularize everything and abstract out things into, you know, very discreet units of, you know, a phrase that we use often here at geyser is, you know, what is the job to be done? And I think that works very well for isolating both permissions and other metadata type just like have that single responsibility.
So Oscar, I'm gonna move to you next.
You know, obviously, you know, as we've seen from the survey, the people's journey in migrating from profiles to a more of a permission set model varies greatly.
So how are you looking to sort of approach this in your organization and and potentially how is is DevOps going to help with that one?
Well, we actually are going through this right now. It's a big initiative, due to the access.
Policies that we're trying to in place as an organization. So what we're looking at more than anything else is to say, what permissions or or security access is pervasive across the organization within the platform. You know, typically those would be profiles. There's your base access.
Just like Namisha said, that's where you have your base, you know, getting that person into the platform is the first e biggest step to adoption too. So the next is looking at it is that, you know, what are we gonna do with permissions, does, you know, how much of a group does need it? Let's keep it simple because it's also going to help us, cause less over, overriding or, you know, kind of stepping on toes in a way with the multiple development teams that we do have right now within the system. So we can easily quickly identify when we're stepping on those toes, you know, or even avoid them, through the process and be able to collaborate and communicate too because now we're getting into more granular permission sets and easier to, promote on there without overriding the next person that or the previous person that had just deployed something to that next environment to or that next step in that branch to be able to, you know, complete and then test.
And then, you know, hey, what happened here? Which is the biggest key to that.
No. Absolutely. And I think that's key to all of DevOps, but particularly important with, with profiles permission set, you know, it is the the security element of that.
And I guess, you know, working for an organization like hacker one, Jolene, I guess, you know, security is in is in the company's DNA. Right? It's all about making sure that, you know, things are adequately secured and protected.
So how are you seeing that applied in the Salesforce world in your organization as we kind of start focusing on profiles, permission sets, and and realigning things.
Yeah. I think like Oscar said it's a huge huge focus for us as well. We we're a smaller team, so it's a bit of a harder challenge for us to do, smaller amount of resource to do a project of this size. So One of our main focuses has been low to make sure that innocent know that we are plugging in that we are starting to adopt that no process of permission sets and not keep adding to the assure that we have of, bag, bag profiles. One of the other big challenges we've got is, like, multiple profiles facilitate API connections and integrations, and that's what it will really help us, is to give them one consolidated baseline profile and then build the permission sets up. Make it much clearer what access are these apps actually having, when they're connected into us. So it's it's it's always a huge focus here to to look at that and keep moving forward with it.
That's fantastic to hear. You know, I I suspected that a security focused organization would be fully on top of this one. So it's it's reassuring to hear that, you know, across all industries, you know, people are really taking the the permissions changes seriously.
So Oscar, I'm gonna come back around to you. We touched upon earlier, you know, the fact that you do work in a a regulated industry, you know, both financial services, but also, you know, health care is another sort of big example of this. And and also, Namisha, I know you've worked a lot in the, in the Finserve sector as well. So these are some very challenging industries when it comes to making changes.
There's a lot more regulation. There's a lot more scrutiny, as we come in to leave those changes to make sure that they meet those regulations and rules, that we have. Done a little of it myself, and I'm gonna be honest. I don't miss that level of pressure.
So with those type of organizations, you know, what are generally some of the challenges that you tend to see when you need to make those changes? How do you keep agile, should we say, and keep that pace of of delivery in a in a dev ops sense while still meetings those compliance and oversight regulations.
For me, it starts really and for our group. It really starts getting those requirements up front, understanding those regulations, its way up front at the start of that component or that functionality we wanna bring in.
And in that way, it'll help streamline that process because we all have an understanding of what we wanna track and what we wanna monitor, from a compliance standpoint and what we need to focus on.
You know, during our deployment process during, you know, the cycle and that feedback loop too as well. So start starting up front and getting us understanding about that and alert from, not just past mistakes, but from, hey, what's worked in the past to be able to be visible, more focused has been very key for us especially as we've ramped up our process and the, you know, group and the focus on Salesforce in the past year.
There's been a lot more compliance and security visibility on there, rightfully so too, because our most important thing is taking care of our customers protecting our customers, especially nowadays with a lot of the outside, outside forces trying to get in, you know, the the bad guys to speak. So keeping that folk customer focus in mind and saying, what can we do to protect their data? Because we're gonna treat it like us. We need to focus on that first from build out those requirements and then it should streamline and just cascade down to the end result.
Absolutely. I think, you know, it is a balance of you know, making sure that you're well protected, versus, you know, making sure that you can get those changes to the way they need efficiently as possible.
So, obviously, Namesh, you've you've focused in the in the fin serve sector currently.
So you've probably seen a wide range of of challenges across multiple organizations and different levels of maturity in those.
So what what are the some of the sort of key practices that those types of organizations, can adopt that will make sure that as regulation changes and evolves, which it frequently does, that they can just make sure they maintain that ongoing compliance in Salesforce. How can they stay ahead of that curve?
Yeah. Absolutely. So I think, I'm gonna break this down in terms of, like, how Salesforce looks at it from, say, the this doesn't, in fact, an interesting block that breaks it down to and everything fits in that in on the well well architected and talks about, it's called compliant and you talks about, you know, legal adherence, ethical standards, and then accessibility. So if we break everything down, it all fits in, right there, because if you talk about, say, legal adherence, so that basically involves, just insuring your regional laws and, industry regulations.
So build that kind of collaboration with your compliance teams talking, with the Salesforce teams, build up those training, And then that that kind of, like, like I mentioned before, that kind of feedback mechanism to actually, both ways communicate as to what is built, what is the data that we offering, is that data compliant? What kind of encryption rules have to be applied? What is our data retention policies? How how are we classifying data?
Are we using the best practices, of doing, say, say localization?
Are we making those I think those specific operations are available and and, so basically just making sure that our compliance team understands as to what what is it that we're capturing? What is it that we are screening? Where are we storing that kind of data? And, a sim similar understanding of, say, what the compliance team's perspective of the legal, and regional bindings are for that industry.
Then coming down to, you know, ethical standards, ethical standards is basically what what's the company's standpoint or what the company's morals and how that is implemented. So I think documenting them and then implementing them in the design standards and then putting them together in in building that kind of ethical behavior inside, all the workflows that you build up is also quite critical. And with AI coming in, it's it's going to be, a unique kind of challenge just to ensure that the data is compliant and is not biased or, is is basically kept up to date. And I think final bit that it talks about is making sure it is all accessible.
So accessible to everybody with any, any kind of different abilities and just making sure that it consistent in terms of, like, navigation and, has multilingual support and just not just for your on our sites, but rather for internal users as well as so just making sure, if these three perspectives are thought about with every build and design. I think it will just bring it all together and keep keep keep the systems basically compliant and just keep you away from those, kind of potential penalties and regulatory regulations.
Absolutely. Yeah. And I'd love that you've you've picked up on, you know, the fact that the majority of compliance related concerns tend to be around data rather than metadata. Ultimately, it's the data that we hold, on people or on organizations and the and the relationships between them.
That are kind of the the lifeblood of of any business. Right? You know, the of course, it's important to to make sure that your your deployments, your metadata process aren't inadvertently introducing security issues. But ultimately, those security issues are protecting your date, you know, the the security implementations that we make are around protecting that data, and that's kind of where the the fundamental sort of mental shift is in a dev ops scenario.
So, you know, when we think about, you know, how do we protect the data, you know, we don't just necessarily have to think about the data that is live data that, you know, we're working with, but also increasingly important, you know, we need to keep a track of of our offline data. And by offline data, I'm talking about things like, you know, backups and archives, which quite neatly brings us on to, you know, the other key theme that that I wanted to pick up on today, which is where the findings of the report are showing that, you know, more and more people are looking at very Salesforce specific backup solutions to meet their needs rather than sort of generic things.
I think the days of people just pulling an export from Salesforce and sticking there on a file server, hopefully behind us. And I think the main reason for that is the the intricate way that metadata is is tied to each other and all the relationships within that. And if you don't back it up with a suitable tool, it makes it very difficult to restore.
So I think we're definitely seeing that, you know, more and more businesses are taking those backups much more seriously and thinking about, you know, if I can back it up, can I restore it again and practicing those recovery drills and stuff? So, Julian, I'm gonna turn to you for this one. Does that does that kind of reflect what you're seeing in your organization in terms of, you know, people realizing the importance of of backup and and potentially recovery as well?
Yeah. I would say so, like, when I first started in Salesforce, it was very much that you either use the tool that the company uses as a backup solution or let you say support a report and hope for the best.
Nowadays, I would definitely say people are a bit more serious about it. And I think the education on how that data hangs together like you say is the key part if you can't put it back in there easily quickly, then what use is it to you. And I think that really shown when I came, over to hacker one, and one of the the key features stood out when a demo gear setback was was data backup, every single person that's seen it was like, yeah, that's that's what we need. Just something that can ease our minds.
We know it's there. It's doing what it wants to, and we know we can easily get things back if we ever need to. And it it's actually opened up a lot more doors for us because it means we can actually look more deeper into the data if something changed, but not really track set. You've got it there, if accidentally just delete one record.
You have it then. It's much easier just to go and pick it back out again. So I definitely see the mindset shifting to why a Salesforce solution would be of more use to you than a generic solution that's on the market for for other tools.
And and do as an organization, do you do those recovery drills and, like, you know, disaster recovery rehearsal type things he'd whether Salesforce, specifically, or or generally?
In general, as a company as we do it, it's not something that I ran for Salesforce we're maturing that something I think we're wanting to start looking at and and by having the tools, it's it's a possibility to even look at it now, when that's a path experience that never has been.
Fantastic. And I guess that, you know, with the the backups and the retention of data, there's definitely some strong overlaps with the the compliance theme that we talked about earlier.
And again, Oscar, you know, working for a bank, you're an ideal candidate for this question. You know, how how comfortable is is the organization around the ability for Salesforce backup to, you know, to kind of suitably manage the need to retain data on the one side, but obviously with the regularly re regulatory requirements that we have, around, you know, right for deletion, right for correction, you know, it's GDPR, which is obviously more of a European thing, but sometimes it, you know, there are equivalent laws in the US that that come into play here. How do you balance those two factors?
So you you have to make sure that your backup solution you know, can adhere to that, adhere to encryption policies that you're expecting Salesforce to at least, you know, or even better at that, you know, previous organization we did have the GDPR and the CCPA requirements, the equivalence, and they're starting to sprout up in each state, in the United States because it's really by state at this point.
So you had to make sure that I forget how do you obfuscate that data as necessary? How easily is it done? And it goes back to that decision between that generic, third party tool versus the Salesforce specific one. You know, as, you know, Salesforce being five years old now. You have you have a lot of the, ecosystem and the participants in there where the developers and architects, whoever, that have only known Salesforce were probably maybe five, ten years ago, that may not be the case.
So being able to switch between, hey, no, here's how we have grab this data whether it be socle or SQL or whatever, you have to flip that situation on and knowing what to query, know what to grab. You know, is more Salesforce focused and cycle focused at this point. Easily, no clicks not code because it may be a low code or no code user.
So having that detail there to be able to say, cool. This is compliant.
This is the first focus being able to recover that data quickly just in case there is, an event is a really key to that compliance piece adhering to those SLAs that you've agreed upon with that, from the bank policy as well.
So have having that tool being quicker with a more Salesforce specific one does lend well to those types of third party applications.
That makes a lot of sense. And I think, you know, it's it's it's definitely balancing all things, right, to make sure that we kinda meet the the needs of the the end user and the customers versus, you know, the needs or the, you know, the the hard asks that we get from from those regulation things.
So inevitably, our our thoughts are now turning towards AI.
You know, if If anyone's been living under a rock, it's definitely the theme of of twenty twenty four in all things technology, and Salesforce is undoubtedly leaned hard into the adoption of AI. I've recently returned from from TDX, and it was absolutely the the prevalent theme of of the conference.
So we have a question from Richard.
Forgive me for looking up. I'm I'm just kind of making sure I read his question correctly.
So Richard on the chat has asked, Salesforce is introducing a wide array of AI tools such as copilot builder, prompt builder, model builder, and a greater use of data cloud. So I'm gonna put this to the panel generally, perhaps starting with Namisha, being that Salesforce representative, do you see this having any impact on developed practices in the upcoming year, such as working practices around managing prompt engineering, what impact do you see and and how do you think, you know, it might be best to, to manage this? So I guess this is kind of thinking about, you know, how either from a dev ops sense, how can we make best use of them? But also, how can we migrate those prompts and things between instances too?
Certainly. I I actually opens up a broader, world of exciting things that can be done with DevOps. I think, there's loads of opportunity in in that space. So, it's it's a matter of making sure, we train the AI model accurately just trying to we've been been doing this for years now, and it's a it's a it's a process of actually embedding those and making the system more intelligent, just trying to offload some of the tasks that we are having to do. So if you're having to build up some some test cases.
That that can be outsourced to AI assistant as I call it. So it's basically it's just, it it it it it's a it's a huge, huge, huge world to actually floor. It is this there is a lot of opportunity.
And, the the only thing to be be clear and be sure of is our data quality is insured and the the focus in is what what comes out. So just let's let's make sure that our data is not neglected anymore. And cleanse it well and put that through. And I think it should it should bring in, I'm very excited about, what what what it can, what yeah, I can do, in the dev ops space and the wider, say it's was swirled itself.
Absolutely. And I think, you know, to kind of hear that question a little to, you know, to kind of, you know, make it very, sort of customer and end user specific.
Gonna I'm gonna ask each of you. I'll start with Jolene. What are the things in the in the dev ops space that you wish AI could do for you today?
I think for me, like, one of the big things that strikes me is to take the load off peer reviews, automate that a bit more than a bit of a manual effort that gives an interview and something, and, typically you're looking for just a key set of same things coming out of it. So It'd be awesome to see something in that space that helps us out there with just the time spent and and it's not a backlog that you usually get in a PRQ.
Yeah. And I think there's definitely, you know, even sort of without AI, there's definitely been some inroads into that with things like static coded you know, so some people on the call may be familiar with things like PMD, that will just look for those common mistakes and common bad practices and and guide folks you know, you can have that as a warning or as an error, that goes a long way to making sure that we we deliver quality.
But, yeah, it'd be it'd be great to see AI kind of take that to a a whole other level.
And Oscar, how about you? What would you like to see AI, do in the dev ops space to make your life easier?
Well, second, what Jolene said, definitely for the peer review. That seems to be taking up a lot of time in our role lately too. But, I think also to identifying those consistent trends that we have as we're deploying through the process.
You know, hey, we see this happening pretty regularly you know, really best practices this. Here's a link to that. Do you need some help there too? Because sometimes we get so laser focused that we don't see, you know, a bigger picture sometimes.
So it'll help. I think AI would be great to help prompt those. I didn't, you know, I think it's kinda like a static code analysis job where we do high identify like, oh, yeah, guys. You remember your, you know, too many too many that did the ML statements in four loops.
Let's, you know, let's start getting out of that habit, you know, but we see these continue, habits, I guess, would be the best way to put that and get those, identify those so we can start correcting those the next go around.
Yeah. I'll I like that. It you know, the the idea of kind of breaking those habits and just sort of steering the ship a little with the with the type of automation is is great.
So we have a a few more questions coming in from from folks, which is fantastic to see. Let me just pick up another one. I can get my mouse to work. Oh, there we go. Okay. So we have a a couple of questions coming in from both the chat and the Q and A panel here.
I'm going to pick up Haley first. So Kelly has asked what techniques or approaches have you seen to decouple releases versus deployments?
I'd have a a frequent, well, well running line of technical deployments, but releasing those features or functions when the timing best fits the end user. So it's a it's that delineation, I guess, between, you know, releasing changes and and technical pieces versus, actually, you know, these are are ready to roll out to whether that's a pilot group or, you know, wider, of course, the organization. So Is this a, a practice that perhaps you you pick up in your organization Oscar?
So I I am dead set on saying if it's ready to deploy and release, you let it go. Smaller increments, better, easier adoption for us. However, We just had this topic in the past two weeks, actually, Kaley, that, you know, there's gonna be sometimes, and we try to make that the exception and not the norm. Where we do have to couple deployments and releases.
So what we're trying to use is some of those custom metadata types in Salesforce, to treat it as a feature flag as very similar to the, classic workaround of the, bypass.
The bypass, custom setting.
Yep.
And, that it it runs very similar, but we can turn it on and off in mass and and revert to that too and identify those be able to continue to use those in, perpetuity if necessary when we wanna do that too. And it helps, you know, truthfully with compliance to say, okay. We turn this on and off.
In, you know, in Apex class, that's one thing, but we don't wanna do that because that requires, you know, a release or deployment So having that custom made it a type where an admin can flag it, toggle it on and off is is a big win. We can audit it a little bit better, with change too with that data, about a data backup as well. So that that's what we're starting to see. In terms of recommendation, permissions, that's another good one, with that as well, where you can have the permission set and, have it on, but only assign that permission set when it's ready for time to go with. It's a smaller subset of users too.
Yeah. Well, that's that's a good sort of comprehensive set of, approaches to that to that problem. And, Namisha, obviously, you work, as a a technical architect. So, you know, I I suspect you see a lot of disparate orgs on this. Are are you seeing the the concept of these type of sort of feature flags and sort of, you know, deploy first enable later across some of the, the customers that you engage with?
Yeah. Absolutely. So we see that quite often these days because the aspiration is to get it through, not deploy it as waterfall activities at the end. So it's it's it's a con continuous process.
If even if it is not released or not being enabled for everybody, it should go through and build up on the building blocks. So ensuring that that that it works in both both kind of scenarios turned on and turned off and that gives us that flexibility. So don't have to wait for another deployment or another deployment drop when it comes to actually, running into an issue with a a release as such. So it's it's, it's quite, understandably the case, I think, or Also, I try and break that down into CI versus CD.
So we do continuous deployment to get it to a state where it is actually ready and tested and evaluated. But, like, into into getting into con continuous integration phase up until, say, the phase of UAD, but getting it deployed in our regular cadence, which is not the same as maybe the stories. So, basically, we'd deliver user stories in one cadence and deliver features in a lot of cadence, essentially.
Absolutely. I I think, you know, it's it's definitely a a popular approach on on other platforms forms, and it's it's encouraging to see it happening on on Salesforce and people thinking more strategically about how they kind of get features in front of people.
I am just keeping a a weather eye on time. So I'm I'm gonna kinda move on to the next topic, and I I will we'll probably start with Jolene on this one. So we've had a couple of questions coming, which I think are are similar enough, that we could perhaps combine the two together.
So, Richard again has asked, do we have any recommendations from your experiences on how to, nurture the, collaborative DevOps culture that we talked about earlier, and, you know, make sure that the team is kind of ready to to take on that approach to to dev ops. But I'm gonna combine that with, a question from Gene Miller as well, which was, you know, and this is around sort of how do we make sure that everyone has a a stake in Salesforce DevOps. So Gina asked, as a BA or an admin, How can I get familiar with she sells gearset, but dev ops in general, I guess? So I think combining those two pitch know, how can we roll out the the mindset and the familiarity of dev ops, within your organization? So I'll start with you, Jolie. How did it happen in in your world?
I think like I said earlier, that we're getting like getting everyone involved as the as the key piece. You can make as many processes if you want. If people don't understand them, they'll find them hard to follow. And DevOps is one of those areas where if you don't understand you're doing it, or it may look more complicated, but actually it gets you better results at the end.
If you don't explain that to people, it makes it hard to get the adoption for them. And one of the the key things I've learned, especially, coming in, the robo hacker one where majority of my users are low code, low code is by involving the minute, it's gave them so much confidence. Like, they are now starting to want to learn more. They want to get more deep in it yet.
They're they're comfortable with the UI and they're like, okay, How does this work now in the back? What is get get done for is? What is version controlling and really open up that concept of I can learn this and I can go deeper with it? If you get them involved with it, you'll probably get the same results.
It's a massive topic, an interesting topic, and it really does require a team effort. And that's everyone from your execs all the way down to the users that are using the stuff every single day.
No. And that's that's a fantastic point is that, you know, you you have to get stakeholder buy in from top down as much as you do from the bottom up. So everyone is kind of on that same page. So Oscar, how how did you achieve that in your organization? How did you kind of present the value of dev ops but equally get everybody up to speed with what is this pivot ops thing that everyone's telling me about and how, you know, why is it going to benefit me?
Yeah. It it it's very similar to Jolene. You you show them what's behind the curtain almost and why it's so important for them to play the role. A lot of it is that Jack mentioned earlier on the report that that shortened feedback loop, shrinking it down, smaller increments making it easier to view, you know, which, you know, smaller, less information to intake to help out and then see the stakeholder from a business standpoint why you need that DevOS tool saying if we meet this step in this process, we can speed the market faster.
And it it it plays a major role in the buy in to say, you know, hey, we we don't put to play everything all at once. So here's how quickly we can get it to you, how much faster it is, fewer failures, in that sense too. And then it helps, you know, here's how we position or ask. Going forward because now we understand that as the team grows, as the team goes through the process, this size of an is going to make it through faster.
So we get simpler requests. It simplifies the process too. And, you know, DevOS sounds complicated. It's, you know, what is it?
It's you know, can be clouded. It's changing pretty regularly. The ideas on it. So how can we simplify it, so everyone can participate whether it's a business stakeholder or someone a partner IT group on that as well within, you know, how we do it to help make it faster easier for them so they can do what they wanna be doing and let us do what we wanna be doing.
I think that makes everyone happy. And then when they see that, it just helps with the engagement and the buy in from everybody.
I mean, that's absolutely it. It's it's everybody succeeds if we all work together.
So we are down to the last two minutes of the panel here. So I'm going to allow Namisha to close this out, with an answer, along that theme, you know, How can teams get started with DevOps? You know, what what is the the advice from, you know, a a technical architect that Salesforce? So someone uniquely positioned with the experience you know, what is what is the best of advice that that teams can take on board to start moving in that direction?
Think it's important to, foster that kind of culture of actually collaborating and I kind of do that quite often, so to break it down into the the the four key the three key things like people process.
And technology. So, as Jack mentioned before, as well, in in the report review, just spend time and, invest on upscilling, and just to understand it develops is a very critical, part of your development, and release cycle. And, it just becomes that that solid understanding of those diverse principles. They just apply the same to any any tool, essentially, and, this will actually enable the kind of, the the the breaking down of the silos and make making things available based, basically democratize, will help democratize, salesforce dev ops.
And then also, build a proper process because, it has to be a clear standardized process that applies to all metadata that is being deployed. And, just and I think planning and then just building that upfront just helps from from a technical architects perspective because, we spend a lot of time planning as to how we want to model our pipelines, how do we want to structure things going from, a to b and then how essentially they will look in production and build and, review. And then, obviously, the final bid being technology. So investing in technology is also important just making sure all the best in class tools and tools that can be adopted by all is accessible for all and, just being able to collaborate and build that, is my advice to establishing a good dev ops practice.
Fantastic. No. I I love that emphasis on on culture and collaboration there.
So we are at time for our panel session.
Thank you so much to our our fantastic panel.
For answering all of those questions on the fly, on the spot.
But I think, you know, it's a largely drawn out from from their experience, which is exactly what we were we're hoping for.
