Every few years, the conversation around Salesforce careers gets a reframe. First, it was whether admins were becoming obsolete, then it was whether developers would be outpaced by AI. But in 2026, the more useful question may be less about which role is under threat and more about how the two roles are actually working alongside each other as the platform changes. Salesforce is becoming more AI-assisted, more declarative, and more architecturally demanding, which has led to the old boundaries between admins and developers feeling less fixed than they once did.
However, that doesn’t mean the two roles are merging into one. If anything, both are becoming more specialized in some ways and more collaborative in others. Admins are moving further upstream into governance, data quality, and platform stewardship, while developers are being pulled toward architecture, scale, and long-term design. In practice, that creates a much more interesting dynamic than the old clicks-versus-code debate.
We recently took a look at how the Salesforce Admin and Developer roles are evolving individually. Now, we want to look at how the two co-exist in modern Salesforce teams, now that the expectations for both have shifted. To understand what that looks like in the modern ecosystem, I continued this conversation with Salesforce professionals about where the line is starting to blur, where it still matters, and what strong admin-developer collaboration now looks like in real teams.
Where the Admin-Developer Boundary Is Blurring
For much of Salesforce’s history, the boundary between admins and developers was relatively straightforward. Admins worked primarily in configuration, while developers stepped in when something required Apex, integrations, or custom components. It was not a perfect divide, but it was generally clear enough for most teams to understand where one role ended and the other began.
This clarity is starting to go through some changes in 2026, with AI-assisted development proving to be one of the biggest reasons. Tools like Agentforce and other AI copilots are lowering the barrier to generating code, meaning tasks that once required formal development experience are now technically accessible to a wider range of Salesforce professionals.
As a result, some admins are experimenting with areas that previously sat firmly inside the developer domain.
SF Ben Technical Content Writer Tim Combridge explained that this shift is already happening in real projects.
“Admins have the power today to write code that they previously wouldn’t have even attempted,” Tim explained. “I remember when I was an admin and a junior functional consultant trying to write code myself and getting stuck on the basics – things like ‘Is this a before trigger or an after trigger?’ I just didn’t know what I was doing.
“Now I can go to a tool like Agentforce Vibes and say, ‘Here’s the context, here’s what I’m trying to do – can you build me a trigger for this?’ It might save the hour you’d normally spend trying to build the same logic in Flow.”
In practical terms, that means the traditional lines of clicks versus code are no longer as rigid as they once were. An experienced admin who understands the platform deeply may now use AI to scaffold a piece of logic or quickly test a concept that would previously have required a developer’s input.
However, the shift is not simply about admins writing more code. Across the ecosystem, both roles appear to be moving closer to system-level thinking. Admins are increasingly expected to understand how the platform fits into a broader architecture. Meanwhile, developers are spending more time thinking about long-term architecture and how solutions interact with the rest of the system – likewise, rather than just focusing purely on code writing.
This convergence is something Salesforce MVP and experienced developer Paul Battisson has observed as well. While AI can help bring the two roles together, he believes the distinction between them still exists for a reason.
Paul said: “I think AI’s ability to accelerate development can bring the admin and developer roles closer together and help them meet somewhere in the middle. But they’re still distinct and important roles.
“What really matters is the approval and review at the end. An admin might use a tool like Agentforce Vibes to generate a component, but if they don’t understand what’s been written, they won’t be able to support it later.”
AI may reduce some of the technical barriers between the roles, but it definitely doesn’t eliminate the need for expertise and understanding. Generating a component or automation is one thing, but understanding how it behaves within a complex org is another thing entirely.
This is why many experienced professionals described the current moment not as a merging of roles but as a shift in how they interact. The result from this is a Salesforce environment where the boundary between admins and developers is less about the tools they can use and more about what responsibilities they ultimately own.
Where the Boundary Still Matters
Even as the line between admin and developer becomes less rigid, it’s clear from the conversations we had that the boundary still exists for a reason. AI has made it a lot easier to generate logic quickly, but speed does not remove the need for accountability.
Tim was clear about where the risk begins, where that distinction is neglected or ignored. While tools can now generate working code from a prompt, he believes the responsibility for understanding the output remains with the person deploying it.
Tim states: “My general advice with today’s AI coding tools is simple: if you can’t read the output code and explain how it works, don’t put it into production.
“There might be something in that code doing something you didn’t intend, and once it’s in production, it’s not always as simple as just turning it off. You may need to go back in and rewrite it, and if you don’t understand the code, that becomes very difficult.
“You can only rely on AI so much – it isn’t perfect. If you don’t understand what’s being built, you probably shouldn’t be responsible for deploying it.”
That principle, according to Tim, applies just as much to declarative tools as it does to code. A complex Flow can introduce performance issues or general unexpected side effects in the same way a poorly written Apex trigger can. In both cases, the problem is less about the tool and more about the gap between building something and understanding its impact on the wider system.
From Paul’s developer perspective, the same rule has always applied. He pointed out that writing something that technically works is only the first step, and the real responsibility begins when it needs to be supported.
“If you’re writing something that’s going into production, you need to know how to fix it when something goes wrong. That’s always been true,” Paul said.
“One of the things that’s caused headaches for years in development is people copying and pasting large chunks of code from places like Stack Overflow. It might work at first, but when it stops working, you have no idea what it’s actually doing.”
That expectation is one of the main reasons why the admin-developer distinction holds weight in many Salesforce teams. However, this doesn’t mean the two roles operate in isolation. In fact, many teams still rely on a shared principle that has guided Salesforce design for years – configuration first, code second.
Salesforce Solution Architect Courtney Newhall, who works closely with both admins and developers, described the principle as the foundation for most design decisions.
“All the larger design decisions should be based on whether it can be done with configuration first,” she explained. “If not, it becomes work for development.”
Seen this way, the boundary between admins and developers is less about drawing a hard line between responsibilities and more about establishing clear guardrails. It ensures that solutions are built in a way that teams can understand, maintain, and trust over the long term.
And as Salesforce continues to grow more powerful and interconnected, those guardrails may matter more than ever.
Where Tensions Actually Appear on Real Projects
If the boundary between admins and developers is becoming more flexible, it would be easy to assume that the relationship between the two roles is becoming smoother as well. In reality, the opposite can sometimes happen. As the overlap between the responsibilities grows, so does the potential for disagreement about how something should be built in the first place.
One of the most common flashpoints is the choice of tools. As many of you may know, declarative functionality in Salesforce has become significantly more powerful over the past decade, particularly with the rise of Flow. Many processes that once required Apex can now be technically handled with configuration alone. For many admins, this can feel like a natural extension of their role.
Developers, however, often see the problem from a different angle – with more concern around how things that are built behave at scale and how maintainable it actually is. Paul noted that the difference in perspective is where disagreements start to surface.
He said: “Flow is a fantastic piece of kit that can get you quite far. However, there are times when you need to go ‘we can’t do this in flow’ or ‘it’s going to be too difficult to do this in flow’ and you need to do it in Apex. The tensions often arise where someone can see that – in this case, the developer – and says it needs to be done in Apex.. and an admin might say ‘nope, I can do this in Flow.”
Despite the likelihood of the two parties disagreeing, these moments are rarely about one role being right and the other wrong. More often, it’s reflective of the different priorities each role naturally brings to the table. Admins tend to be closer to the business users and the immediate problem that needs solving, while developers are arguably looking at the bigger picture.
Courtney described how those differences can play out in practical terms, particularly when teams are working closely on the same features.
“Communication is the key to great collaboration with any team,” she explained. “If an admin creates a field that a developer needs to reference in code, it all comes down to making sure the name and field type are shared so no one has to spend time searching for the answers.
“Teams need to work together to make sure they provide the right answer for their users.”
What becomes clear across these examples is that most tension between admins and developers is not really about technology at all, but a lot more about comms and coordination.
“Tension between admins and developers is just tension between humans,” Paul explained. “It’s having good soft skills and understanding that.
“One of the things that good managers are good at is helping people build those skills together and understand them – expressing what’s good and how things work together.”
So in healthy teams, that inevitable friction is something that can be channeled and sorted productively, with both admins and developers sharing their viewpoints openly to ultimately produce better solutions than either role could arrive at alone.
The challenge, of course, is making sure those conversations actually happen early enough.
What Strong Admin-Developer Collaboration Looks Like
If the boundary between admins and developers is becoming more fluid, the most successful Salesforce teams are not the ones trying to collapse the two roles into one. Instead, they are the ones who understand how the roles complement each other and deliberately design their collaboration around that.
At a practical level, this starts with recognizing that admins and developers often sit closest to different parts of the system.
As Paul explained: “One of the best teams I worked in had a really good dynamic between the admin, the functional lead, and me as the developer. We would sit down together, look at the scope, and say, ‘This is yours, this is mine, and this is where there’s a bit of overlap.’ Then, when we reached those gray areas, we’d decide together who should take it.
“None of us had an ego about things, and we had a good enough relationship to give honest feedback. One of us could say, ‘Actually, I think this would work better if we did it this way,’ and the other person would take that on board.
“It was never about who knew best. It was about communicating well and remembering that you’re discussing the problem, not the person.”
Ultimately, this comes back to the aforementioned soft skills and appreciating what both sides can bring to the table. Admins often have the clearest understanding of the business problem being solved, while developers can help shape how that solution will behave over time.
Courtney highlighted her own experience with her team, how this kind of collaboration is actually emerging from curiosity on both sides.
“I’m lucky to work now with coworkers who all have a strong growth mindset,” she said. “We all want to understand a little bit more about what others are doing, so collaboration comes pretty easy to us.”
One area where that curiosity naturally appears is Flow design – which increasingly sits at the intersection of admin and developer thinking.
“The main area I see the boundary blur between the two roles is when building and designing Flows,” Courtney explained. “Building a great Flow requires knowledge of best practices both in Salesforce configuration and coding.”
However, Courtney also pointed out that the ecosystem still has room to improve in how it supports that kind of growth. When she began studying for her Salesforce Developer certification, she found that much of the learning material assumed an existing programming background.
“All the material was directed towards those who already knew how to develop and taught them how to develop for Salesforce,” she said. “We need more education for admins who already know Salesforce and want to learn how to develop.”
Taken together, these perspectives highlight a broader shift happening across the ecosystem. The goal is no longer for admins and developers to operate in completely separate lanes. Instead, the strongest teams are the ones where both roles understand enough about the other to collaborate effectively.
And as Salesforce continues to expand beyond a single platform into a wider ecosystem of tools, integrations, and AI-driven capabilities, that shared understanding may become one of the most important strengths a team can have.
Final Thoughts
If my two previous articles in this series explored how the Salesforce Admin and Developer roles are evolving individually, the real takeaway from this wider conversation is how closely those evolutions are now connected.
In 2026, the future of Salesforce delivery may not belong to one role or the other, but to teams that understand how the two work best together.
