Description
Smooth collaboration is the new standard for successful Salesforce teams, with 76% using one unified workflow. When admins and devs collaborate effectively, teams spend less time fixing code conflicts, and can more easily scale to meet demand. So how can Salesforce teams achieve a collaborative workflow? Join DevOps expert, Rob Cowell, and get the actionable advice and game-changing strategies you need to boost collaboration within your Salesforce team.
Learn more:
Transcript
Good morning or afternoon or evening, depending on where you're joining us from today. Talking by, a lot of the, US and Canadian folks in the in the chat there. I think it's it's mostly morning for people. But, yeah, you're welcome regardless of your time zone.
So as Amy says, the session today is bridging the admin dev divide, which is focused around strategies for DevOps collaboration.
So like Amy says, I am indeed Rob Cowell. I am one of the two DevOps advocates here at Gearset, and I'm here to discuss how we can turn some of those common challenges between Salesforce admins and Salesforce developers into opportunities for collaboration and innovation.
So to get us started, I'd like you to think about the last time that you encountered a bottleneck in your workflow, perhaps because of a misunderstanding or a misalignment between your admins and your developers. It's surprisingly common.
Now imagine a world where these two roles work together in harmony, not across purposes, and that's what we're really aiming for here. And DevOps is one of the keys to making that happen.
But first, let's ground our discussion with some encouraging data from the latest state of Salesforce DevOps report, and it revealed a quite exciting trend. A staggering seventy six percent of Salesforce teams are now using a unified release process, I. E. Admins and developers adopting that same process through DevOps.
Now that's not just about using new tools either. It's about fostering a new standard that defines the most successful teams in our field.
This shift towards a a unified process is transforming how those teams collaborate across roles, and it makes it even easier for admins and developers to support each other's work.
But why is this transition happening now?
Well, as always, the Salesforce ecosystem is rapidly evolving. I think we've seen a lot of change in a short space of time, particularly around AI.
And as it grows in complexity, the need the need for streamlining those processes and having better collaboration tools becomes undeniable.
So DevOps is no longer just a a nice to have, it's become a a must have.
Now if you do want to learn more about how other Salesforce teams are performing in twenty twenty four and some of the key trends that those top performing teams are using to get better processes and better performance, then do check out this year's state of Salesforce DevOps report if you haven't already done so, of course. There's a QR code on the screen for you there, which will allow you to access that report and download it. And I'm sure the team will be able to post links either in the chat now or in the materials to catch up after this webinar.
So why are we focusing on this?
Well, because integrating DevOps into your team isn't just about speeding up deployments or reducing errors. It's about building a whole culture around communication where everyone speaks the same language and understanding and breaking down those silos. And that's where the full potential of every team member, regardless of their role, can be unlocked.
So today, I want to explore not just why these changes are gonna be beneficial, but also how you can implement them in your teams.
So we're gonna look at some of the specific challenges that arise from poor collaboration, delve into some of the key processes of a DevOps workflow, and see how they can improve how your teams operate.
I'm also going to share some practical examples and perhaps even a few stories from the trenches and my previous life as a developer myself to bring some of these concepts to life.
So now that we've set the stage with that promising trend of unified DevOps processes, let's start looking at the real challenges that many of us will face in our daily operations because understanding those challenges is the first step to overcoming them.
So imagine a scenario where your team's using multiple workflows that just don't align with each other. Maybe one team's using version control and are sort of very comfortable with that, while another team perhaps is not familiar with that and is even making changes in production, and we know that does happen sometimes.
But the result is confusion, duplication of efforts, and higher risk of errors.
And tracking those changes becomes a bit of a detective hunt, a time consuming and often frustrating process that can lead to significant setbacks.
So when those teams do use different disparate workflows, it's not just inefficient, it can cause serious integration headaches. Different parts of the organization might not even be aware of each other's changes until the point where something breaks. It's a bad time to be finding out about it.
Without a unified system for tracking those changes, understanding who changed what and and why can become an impossible task, and that lack of transparency can result in mistrust between teams and a breakdown in the cohesion of the teams.
Now consider the impact of out of sync environments.
What works in one environment fails in another because they aren't exactly mirror images, and that can derail a project faster than pretty much anything else.
And then there's those manual processes that we end up doing. Manual processes are not only slow, but they're also prone to human error.
Any repetitive tasks that could have been automated will drain energy and focus from your team if they're not, and that leads to delays and morale issues.
So let me tell you a little about a team that I worked with as a an example of of how this can happen. They faced constant delays because the environments were out of sync. Testing was always a bit of a gamble because what worked in dev would fail in production or even in QA and UAT environments, and the root cause of this was a lack of synchronized automated deployment processes.
So have a think about some of your own experiences.
Are these the sort of issues that you might have seen in your projects, and how have they affected your delivery timelines or team dynamics?
Don't be afraid to share some of the war stories in the chat, and so we can all kind of share and learn from them.
Now continuously facing these kind of obstacles can demoralize even the most dedicated teams. It feels like that classic image of pushing a boulder uphill only to watch it roll back down every time. Not only do these challenges extend your project timelines, but they can also compromise the quality of your final product, and that leads to dissatisfied clients or missed opportunities within your organization.
Now as I said earlier, knowing the challenges is half the battle. The next part of our discussion, we're gonna explore how some of the core processes of a DevOps workflow don't just address these issues, but can transform the way that your teams collaborate and ultimately succeed.
So after we've examined those common challenges that disrupt our workflow and our team dynamics, let's explore some of the core pillars of DevOps that not only offer a pathway out of this chaos, but it enhances our capabilities to get higher unprecedented levels of efficiency and hopefully harmony within our teams.
So let's start with version control as a strong technical foundation.
At its core, version control is about keeping track of changes made to code or configurations over time, and it allows multiple team members to work on the same project without stepping on each other's toes.
With version control, every change is documented, which means no more guessing who did what or why.
But it also means that you can revert to a previous version with just a few clicks if you need to undo a change that perhaps didn't work out as expected.
So imagine a scenario where a critical error is introduced during an update.
With robust version control, team can quickly revert to a previous state, and that minimizes downtime and helps maintain business continuity.
Now, ideally, you would discover that well in advance of production, but it's kinda nice to know that these options are available to us in an emergency.
Next, we look at automation, and automation in DevOps covers everything from simple code deployments to those big complex multistage workflows that have testing, staging, and production environments.
By automating some of the repetitive tasks, teams can focus on that higher level strategic work instead of getting bogged down in the detail of deployment processes.
So consider the time that that could save when these automated scripts do the heavy lifting of deploying changes across multiple environments.
Things that used to take hours can now be accomplished in mere minutes with fewer errors and greater consistency.
We also have backup and restore functionalities that are part of a mature DevOps process, and they're not just about safety. They're about resilience.
In the face of data loss or corruption, being able to restore your system quickly is crucial.
DevOps tools can provide automated backup solutions that capture snapshots of your environments, and that ensures that you always have a recent backup to turn to in times of need.
So let's say a deployment does go wrong and maybe a a script or a, you know, a piece of SOQL code, for example, is too broad in its scope and affects more data than it should have done. I've seen it happen in orgs even under my control. We're not infallible.
But instead of panicking, your team can restore from the latest backup, and that ensures, again, minimal disruption to your services and to your end users.
But the beauty of a true DevOps approach is how all these separate processes, version control, automation, and backup, can integrate together to create a seamless flow of operations.
Each of those constituent parts, those components, will work together to ensure that the changes are made safely, efficiently, and transparently.
So have a think about some of your own workflows.
Where do you think the the most immediate impact could be if you integrated, for example, more automation or adopt version control if you've not already? Again, let us know in the chat some of your experiences. It's always good to learn from folks out in the field.
But do remember, however, that adopting DevOps isn't just about implementing new tools.
It's about fostering a culture where collaboration and efficiency are at the forefront, and it encourages continuous improvement of our processes, accountability, and, again, team unity.
Now while adopting a new workflow might seem daunting at first, the benefits of DevOps are very clear. It reduces that friction between the different roles within your team, and it allows you to focus on delivering that value rather than managing chaos.
As we continue through today's session, I want you to consider how these solutions might be tailored to fit into your environment.
I always like to emphasize that it's not just about blindly following best practice. It's about finding what works best for your team and your projects.
So we've explored the individual components of that DevOps workflow and how they can solve specific challenges.
So now let's start seeing how DevOps doesn't just bridge that gap between admins and developers, but actually empowers them. It makes collaboration not just possible, but much more productive and even enjoyable.
So for many admins, that leap into DevOps can seem a little daunting, not least of which because it begins with the word dev.
But if you've only really relied on traditional Salesforce tools like change sets, it can seem like a significant change.
But it does empower admins by simplifying and automating many of their tasks, and that shift can increase your strategic involvement in project management and decision making because your time is freed up.
So let's have a quick look now at how we can do a simple deployment of some configuration using Gearset.
So I have Gearset here and we have two users set up for this example. We have Joe, the admin, and we have Tina, the developer.
Now Joe's changes are on the left here, but Joe has created a new custom object called recording.
That custom object contains a handful of fields, so the recording artist, the format, such as m p three, and the recording length.
Very simple object, but an important one, and we have some custom permissions there as well. In order to ensure that everyone is kind of on the same level playing field, it might be that, for example, Tina, the developer, needs to write some functionality around this object.
So she will need to have a copy of that object in her developer sandbox, but it's been created in Joe the admin's developer sandbox. And this is where keeping those environments in sync by deploying between those environments really comes into its own.
So I shall collapse some of this tree down a little just to make it a little more easy to read. The fields are are beneath this object, but we've simplified the view a little here.
I'm going to select those, and I'm going to go to the next screen.
Now what's happening here is it's running a little bit of analysis to make sure that there are no particular problems that may cause this deployment to fail. Now we can see there there is one little warning. Let's go and have a look at that.
So it's saying that, potentially, we need to update our profiles to take into account the new object permissions.
So, yep, let's just go away and take that recommendation and move on to our next screen.
We get a confirmation of what's changing here, and if we are happy, we can go ahead and deploy that.
Now the nice thing about this is it gives me a chance to explain what's happening. It's effectively using the Salesforce APIs to select the metadata, the the configuration that we've changed in one environment, and deploy it to another. And this all happens pretty seamlessly behind the scenes.
You can see there from my screen, the deployment was successful.
Always always a a challenge on demos, and that took a mere twenty seconds to deploy.
So we are now in a situation where Tina now has that recording object and can start building additional capabilities for the business based on that object.
So that's how simple things could be for an admin to move their changes and work together with the developers.
So on the developer side of things, developers can benefit from DevOps by having a more structured, predictable workflow that allows for faster integration and fewer disruptions.
And that doesn't just speed up the deferment cycle, but it can reduce some of the conflicts you see by not having those overlapping or conflicting changes.
So using those integration capabilities, developers can merge their changes into the main project and make sure that everything works together seamlessly and that any potential issues are caught early and could be addressed. Let's have a look at how that could work.
I shall go to the continuous integration, and what we have here is an example pipeline.
These aren't real environments as you can see from the word fake on some of those ones. It's purely me demonstrating how this works.
So we can see that Joe, the admin, has their own developer sandbox, and Tina has her developer sandbox.
This is a fairly common situation in a a lot of organizations. You know, people work and build in their own sandboxes. But, ultimately, we need to bring those changes together for two reasons. One, to make sure that we have a set of changes that work together and don't inadvertently break something else in the system, but also to make sure that all our environments are aligned as we move closer to production.
So we can see the little lines of of things flowing through.
The changes from those sandboxes, when they're ready, flow through to our QA environment where we would do that integration testing and make sure that everything is working as expected.
From there, we go on to our UAT environment, and this is where the end users would typically check that it's meeting their business needs. So in QA, we're checking the the technical functionality.
In UAT, we're checking the business functionality, and there may be a little crossover between those tasks. But, ultimately, we're making sure that everybody's happy and that our collaboration has been successful.
If all goes well, we can then flow onwards through to production.
So if you're familiar with, for example, Salesforce flow, this type of way of working is gonna be quite familiar to you. You can see literally a flow through the environments of our changes, Quite intuitive if you're familiar with working in Salesforce.
But one of the biggest significant benefits here is the ability to break down those barriers or silos that often exist within those different roles.
It encourages communication and collaboration, and that in turn gives a better understanding and respect for each role's contributions.
So in practice, this means that your admins and your developers are not working in isolation quite as much. They're part of a a much larger team with visibility into each other's workflows, challenges, and ultimately successes, and that helps them understand that broader impact of the work that they're doing.
So by adopting tools and processes that admins and developers alike can use, you've got that unified process, that unified approach to project management and delivery. And that's crucial for getting consistency and efficiency with your deliverables, particularly in those larger teams or more complex projects.
So the end result of this is easy to see. You get faster deployments. You get higher quality outputs, and and you get a more agile response to ongoing market or organizational changes. Your teams can be far more responsive and deliver and respond a lot quicker. So that doesn't just benefit your team internally, but it also enhances the competitiveness and responsiveness of your teams.
But if there's one thing that I'd like you to take away above all else today, it's this, that DevOps isn't just about the technology. It's about empowering the people. It's about giving admins and developers the tools and the processes that they need to succeed together.
So have a think about your own Salesforce work. What are the challenges that you face with collaboration?
How do you see DevOps helping bridge that gap in your teams?
Have you seen some of the issues that I've highlighted today in your projects, and how did they affect your timelines and your team dynamics?
These are the types of questions that we should be asking when we're considering the benefits of DevOps.
So with that, I'm gonna open the floor to any questions that you might have, and feel free to ask about any specific challenges you might be facing or any of the DevOps concepts that we've discussed today or even about some of the, little gear set demo that I gave. You know, we're all here to help clarify and explore some of those solutions. Some I may be able to answer live. Some the team, looking after the chat might be able to help with.
See what you've got for us.
Awesome. Thanks so much, Rob. So we do have a couple of questions that have come up in the q and a here. So, the first one, I'm gonna read out is from Martin here. And Martin asks, how would you recommend that I go about getting my admins to use version control?
Yeah.
That's a great question. And that that comes back to what I was saying earlier about, you know, kind of realizing that that DevOps isn't just for devs.
I have occasionally done a session around Git for admins.
But the the fundamental of that is that everything that you change in Salesforce is metadata, and metadata is effectively a file. So there are mechanisms around, being able to extract that metadata. It doesn't have to be code.
It can be a flow. It can be a field, a customer.
Almost anything that can be defined in Salesforce can be pulled out of Salesforce, almost. There are a few little exceptions, but they're they're very corner cases.
But from an admin's perspective, the the advantages are you have a safe place to store your changes. If anything goes wrong, you can roll back, as we touched upon earlier, so that you have that kind of safety net or you can, respond to the business changing its mind. And believe me, that happens surprisingly often as as some of us may know.
But also what it does, it enables those bigger processes so that, you know, you're working in the same consistent, unified way as your developers. So that when we do get to the point where we are looking at automation and, continuous integration, moving our changes in an automated way through our systems, it works the same way. It gets it from version control. It runs its tests.
It, you know, it does all the automations that we want it to do, and that that the lines between developer work and and admin work are kind of somewhat removed from the point of view of of deploying it. You know, we make sure that everything is available for those processes.
Awesome. Thanks, Rob. That's a fantastic answer. And, just for everyone, in the chat, I've just posted a few resources there, that we've got that can just, give folks some advice on how best to get started with version control. This is a a few different resources in there for you. So I think we've got time for quickly for one more question.
And this question is coming from Laura in the q and a. And Laura's asked, how do you suggest we divide up the responsibilities amongst admins and devs for different areas of metadata?
Yeah. That's always a an an interesting challenge, and I I like to separate things out between, ownership and who's responsible for making the changes.
Okay. So ownership, I think, should be shared. So, for example, in the in the, run through that we did there, you know, the responsibility for making the changes sat with the admin. They created that, that custom object.
You know, it's a a typically admin task historically that that they would do, but the developer needed to be able to see that to make sure that they could work on it. So there is generally this kind of openness of, you know, sharing things, but it's tempered by who's responsible for changing them. Now that's not to say that, you know, if the developer needed to perhaps, you know, tweak an aspect of a field that they couldn't do so, and that's where the collaboration and the communication comes in. It's, you know, having those open conversations and saying, oh, I I need to tweak this.
Do do you mind if I do that? Or even could you do that? You know, again, sort of depending on the the ownership model that you want to take on that. Now typically, developers would be responsible for the code and, you know, an admin may be versed in code or they may not feel comfortable doing that.
So there's the practical side of things in terms of who's best placed with the expertise to to work on things, but there's also that collaborative viewpoint of, you know, let's not ring fence. You know, you can't touch this ever. You can't see this ever because it's just not gonna work that way.
Awesome, Rob. I think that's all we got time for.
So I'm gonna let you wrap up quickly and then, No problem.
So I see I see Andy is is picking up some of the, the the questions in the chat as well. So, we are a little pushed for time on these sessions, so I will continue.
But I do thank you for for the questions that are are coming in and the the engagement that we're getting there.
Some great technical questions I can see happening around pipelines, for example, in the, in the chat. So it's great that, you know, folks are thinking about these, but also that folks are at different stages of their DevOps pipeline.
But, hopefully, in today's session, we've covered how DevOps, partly with tools like gear set, but, of course, some of the concepts can be applied no matter how you you do your DevOps.
But they can bridge that gap between the admins and the developers, and it turns that collaboration from being a bit of a challenge to actually your strength, your superpower, if I may.
So I do encourage you to keep exploring and and keep learning more about some of these DevOps practices because it's never done. Okay? There you know, I work here, and there are things about DevOps, for example, with Git source control, but I've still yet to learn or or better understand. Every day is a school day, I think, is the expression.
But every one of those steps that you do take builds up more resilience and more efficiency within your teams.
So I would encourage you to continue that journey. If you want to try out some of the things that I showed in the demo today, whether that's the simple, comparison and deployment or whether you want to start thinking about how the pipelines work, then there's a thirty day free trial of Gear Set that you can pick up. It's not feature limited, so everything that I showed you today should be available to you in that trial.
If you wanna get started with that, none of this business of giving credit card details or or, you know, signing up for a contract. It's thirty day free trial. And you can use the QR code on the screen there to scan that and get started.
And you do also have access to the same level of support from our team as a paying customer would throughout that thirty day trial. So we're really excited to help continue to support you on that journey into Salesforce DevOps.
There will be a bunch of resources, as Amy has said, that come out after this webinar with the, thank you email and a recording of of the session. But for now, that's everything.
Big thank you for listening to me today, and I hope to see you on one of my future webinars.
Thank you so much.
