You can now invite a team member as an Integration Manager, whose only function is to help set up a Hutte project by linking to a Salesforce Org and a Git repository.

In some organizations, the user setting up Hutte might not have permissions on their Git host to run through the relevant authorization steps. Or you might just want to delegate these project setup steps to your IT department. An Integration Manager is the perfect solution for both of these cases.

Adding an Integration Manager doesn’t add any additional costs to your Hutte plan. You’ll find this option under your “Members” tab. Click on “Invite Integration Manager” to open the invitation dialogue box.

Enter the email address you’d like to send the invitation to, and specify the Hutte project you’d like to add them to.

After you click “Send Invite,” that team member will receive an invitation email with an account creation link.

Following that link will bring them to the account creation screen. Once they’ve set up their login details, they’ll be added to your Hutte project, where they’ll see the two project setup steps in the "Project Settings."

The Integration Manager will only have access to these two project setup steps, where they can link the project to a Salesforce Organization and a Git repository.

Mark your important work items with a 'favorite' star

You can now mark your most important Scratch Orgs and Sandbox features with a 'favorite' star.

This will allow you to find them quickly when filtering your list of work items.

This is particularly useful for users working in larger teams who want to easily keep track of which features they are currently working on. You can mark a work item as a 'favorite' in the list view, or in that item’s detail view. Your favorites are tied to your personal user account and appear only for you.

Custom buttons in dropdown menus will now show descriptions on hover

We’ve made a small improvement to custom buttons in Hutte. If you add a custom button to your project through your Hutte.yml, you’re able to see its description when you hover over it.

If you have more than two or three custom buttons, the 'overflow' buttons will be collected in a drop-down menu on the right-hand side. Previously, there was an issue where these 'overflow' buttons did not show their descriptions when hovering over them. This has now been fixed.

You can add custom buttons by adding a custom script to your project’s Hutte.yml file.

Explore these improvements firsthand

Episode 18: Robert Sösemann, Salesforce MVP and Technical Architect

Watch me 🎬

Listen to me🎙️

I spied on your LinkedIn and saw that your first Salesforce-related job started in 2012. Could you share with us briefly your career in the Salesforce ecosystem, how it all started, and how it evolved?

That's a long story. I studied computer science and followed the normal career steps of a programmer. I worked a lot in internet companies. At one point in my career, I worked for a Java consultancy and sat in a very boring IBM training class. It was a time when people were very hyped by business process management, drawing diagrams, and trading software, like a kind of low code. In that two-day seminar, I was Googling a platform I had worked on years ago called Salesforce. Back then, it was a CRM where you could change the color of buttons.

I found that this platform had dramatically increased with an app store and a programming language called Apex. I spoke to my boss and said, "Hey, we need to do this as a separate new business track." I called it "Pragmatic Business Software using Low Code and Salesforce." At that time, I was also thrilled with Lean, Kanban, and Scrum. And I made it. The company later became a smaller German PDO, and we were doing Salesforce. We went to German companies and convinced them to trust the American cloud.

We even created one of the most excellent free AppExchange packages. Maybe you have stumbled across it. It is called Opportunity Planning Wall, and you could use it to move opportunity cards. Salesforce later stole it for their own Kanban view.

The other thing is that internal Salesforce teams like to test their metadata with the CLI. The CLI needs to know about their metadata, which may ship in the CLI six weeks before it's available to users. In doing so, internal teams are using the same CLI. We have to do a lot of releases besides those things. The other thing you'll see a lot is workarounds for server issues, where there's some new error, and it's returnable.

Was it in Classic still?

Yes, it was still in Classic with Visualforce and jQuery, but this is how it started. I fell in love with getting things done. I was often overwhelmed in the Java world. There was so much open-source, and it was changing too fast. In Salesforce, the mindset was that there was one solution or no solution at all, and then you had to build around that.

At that point, I hadn't programmed before. I programmed during my time at university, but then I became a manager and stuff like that. I learned how to code hands-on. I always stayed in it and wanted to stay in the Salesforce ecosystem.

You're also an MVP, a frequent speaker, and you publish stuff. One thing that many people in the ecosystem associate your name with is PMD. PMD is a static code analyzer. Correct me if I'm wrong, but you ported it to Apex first. I think you also grew this into being capable of doing code analysis or static code analysis on metadata beyond code. So, no code solutions like Flow. Can you share with us how it started, how the idea came about, and the process of launching this open-source?

That was a fun story. It was around 2015. I was working for a successful ISV in the AppExchange space. We were still a startup, but the development team grew. In the beginning, it was just me and a few guys who wrote the code. We were ambitious to make the code clean, but we needed to grow the team, so we hired students. As always, I wanted to control things. I didn't want to micromanage people, but I still like enforcing my quality standards.

I thought it would be nice to have tools in Apex that I knew from Java, like code analyzers. Then I thought, "Cool, what's there?" There was only one guy who ported PMD with what's called CodeScan. I think it belongs to AutoRabbit now, but it was one guy in Australia. I asked him, "Hey, can we open-source it? And he said, "No, that's my money. Sorry, I can't do it." A few students and I looked into that and saw that adding new languages to PMD is easy or doable. But the problem was the parser. PMD depends on breaking down the file and language into AST nodes, an abstract syntax tree. Writing such a parser was too hard back then because we didn't know the language.

Did you know that over 80% of Salesforce Developers believe that contributing to open-source projects like PMD, SFDX CLI, or other Salesforce-related tools significantly enhances their problem-solving skills and career opportunities? This reflects a growing recognition of the importance of open-source in professional development within the Salesforce ecosystem.

Others had mastered it, but I said we should not do it. In an 'under the shower' kind of moment, I thought there must be a parser, and it must be open-source in a way where the Eclipse IDE, when opening a class, shows you a tree of methods and everything. I got into contact with Salesforce, and there was a closed-source parser. But we could repurpose it.

Salesforce was interested and provided documentation. We created a language model for Apex, which could do it. To make it usable, we took the Java rules and ported many of them, which apply to Apex from Java.

I was invited to Dreamforce to give a speech. All the IDE providers put PMD in there. From then on, it never stopped being a topic. I never contributed as much code as in 2016. From then on, I tried to convince companies like Gearset to contribute, or I was working for Copado and Manuel Moya, who works for you. We also contributed a bigger part to PMD. When you asked me what I did in the last few years, there were two topics.

The other topic was it only works like static. It doesn't understand the runtime behavior across files. This part was developed by Salesforce. It's called the Graph Engine. It's not part of PMD, but years ago, we looked into making that part of PMD. And it just didn't work out. I didn't do a lot of that, but I was involved. The other part was making it possible to scan XML, the more prominent part of a local platform. This took little work because PMD is already able to do that. Conference talks and articles were needed to tell people they can do it and how to do it, but code-wise in PMD.

What is the current adoption of metadata types where people use PMD rules to enforce a certain quality? Is there even a limit? Could everyone come up with new rules to enforce whatever quality standards on any type of metadata?

Yes. I think in the Hutte template repository, there are even samples of that.

Absolutely, yes. A few metadata types are covered, like common use cases we hear from people we talk with. One that always raises an eyebrow is the ability to, for example, have a simple check to only accept or reject the pull request where a field is added without a description help text. That is part of many manual review processes in teams. The idea to automate this is new to many. I think it can be a huge win for a team to adopt such a relatively simple rule

You can do it everywhere because everything that is not Apex is XML. It's always metadata XML with Apex PMD rules coded in Java. The more extensive power is creating custom rules in XPath and having them as an XPath snippet in your rule set. That not only works for Apex but for all XML. The most complicated one is Flow. But in my example, I have a repository. It's called Unhappy Soup. There is an example which detects many cases of DML in a Flow loop. It's not as good as if we would parse it with Java code, but it's good enough.

You can use it for everything. People use it for permission sets, profiles, and security settings. The restriction is what people put into version control. Salesforce is trying to get more and more states of an org into metadata. When you get that out, you can parse and test it. The imagination is the limit. I was at a conference in London called London's Calling, where Andy Utkan talked about Flow-based practices. I told him, "Hey, we should implement them as PMD rules." The question is: Do people who make a lot of Flow get them into version control? That's a different question.

That's the problem we aim to solve – to make it easy to open the world of Git-based development to non-technical or low-coder team members. Did the integration or adoption of PMD rules into what became the Salesforce Code Analyzer change anything? Do you think it helped the adoption of PMD rules in the broader Salesforce ecosystem?

Yes, it made me happy because back then, when I was working at this PDO, we struggled with Checkmarx and hated it. I told a colleague, "Maybe we will replace Checkmarx one day." When I spoke with Salesforce, they didn't say yes but also didn't say no. It seems to be expensive for Salesforce under the hood, but they replaced it, and it's perfect. What's also great is that Salesforce could have bought one of the commercial vendors, but they decided not to do it and completed PMD with missing things, like the Graph Engine, which does dynamic analysis. I think this was a smart move.

For me, there's always cognitive dissonance, as most people care about PMD because they care about security. But honestly, I do not care so much about security. Those checks were never my ambition. I wanted my Developers to write simple, clean code. All commercial providers only mostly do this security narrative because it's easy. There is no deeper aid. But when I come with clean code, a million haters say: "That's a luxury." That's always my ambition. Security is important, especially on Salesforce, but so many people care about this narrative. I don't want to be in that space.

Not everyone might be aware, but Checkmarx was the tool that you were obliged to run when doing security reviews as an ISP to publish your work on AppExchange

You don't need to do it anymore. You can use PMD.

I think it is important that this tooling is not limited to this use case of ISVs who sprint towards reaching security reviews. However, every Salesforce or small team with two Developers might benefit from going Git-based. I'm tapping this potential by having automated code reviews or assisted code reviews, or in a Flow that might fall back on them later as an org scales to enforce good practices like certain quality challenge standards

I use it in my private open-source repository. When you check my GitHub, I have a rule set in every root node and in Aquiva, the company I work for. We have an internal PMD ruleset pushed into every new repository. We do it for the open-source projects we do. It's perfect. It's not tied to an IDE. All the rules are in a file where you can check and see how they evolve. Some rules are too opinionated, and then you move them out, and it's perfect. I love it. It works everywhere with all the tools and in the IDE. It's simple and doesn't cost a lot.

I would say the biggest hurdle that I've heard in the last nearly ten years is what people do when they first run PMD and have thousands of issues. That gets complicated.

Do you have any advice? Would you advise starting with a very loose or small ruleset and then gradually building it out? Or is there any adoption? Let's think of a team that owns a Salesforce org. They work Git-based and are now automating quality checks. What would you advise as a strategy?

The general narrative is to often reduce the rules to not see it. Don't feel obliged to do anything but learn. I would say running PMD and seeing thousands of issues just mandates that you learn your development team. They should understand what you know, and there can be false positives.

In most cases, there are thousands of instances of horrible naming conventions.

Many people say, "Let's ignore that rule," but why not sit together for an hour in the team and say, "Hey, why do we do such lousy work?" It's like when you write a letter to your mom, and you mix uppercase and lowercase all the time in German. It's unprofessional work. That's my opinion.

You should first look at the security issues. PMD has a severity level that tells you whether it is critical or not. But that's the part where people think they have to learn and understand too much, but that's the critical part. Coming into a position where it feels safe to say we will do that later, but we should change something in the way we work now.

My impression is that people don't want to do it. It's always this stress story. “I have too much stuff to do. I cannot care about PMD and all the commercial providers. They do it smarter. They have fewer rules.” When you pay money, you don't want to have pain. And that's the good thing about open-source. This is the pain that makes you learn. Put the pain where the pain belongs.

I want to touch upon one more topic, AI, because you have dedicated a lot of time to this topic. I'd like to hear from you what excites you about AI in the context of Salesforce without necessarily limiting it to the new products that Salesforce has launched. Maybe you can just share a bit from maybe two years back in your journey

As an intro note, my dad was also in IT and wrote his doctorate thesis about neural networks on those big computers in the seventies. I always heard about AI, but I thought it was too complicated for a guy like me who was not good at math. So, I feared this a little bit, and my dad always told me to go into that because that's the future. However, I could ignore it as it never appeared in the Salesforce space.

But two years ago, when GPT-4 came out, and the world was on fire and in the crazy zone, I took the opportunity to look deeper. I was lucky that at Aquiva, our founders took this very seriously and said, "Let's not just join the hype but look into how we can make this useful for our work and our customers' work."

But every little character should be written by a person. That's my belief. This is also true for blog texts, books, and everything in between. The world should not see anything which is generated. It must go through a human who can act. That's my opinion. So, I like it. I especially like this combination of old-school code, deterministic Apex code, and AI.

I'm not so thrilled by those email generation things or even rag-finding things in vector databases. They're interesting, but not so much. There is a little bit of AI and a little bit of code, and the AI chooses and parametrizes the right code. That's cool. So, I love those copilots, and I think they will be a little bit in the future. I'm unsure if you asked that, but I often get asked that. I think it will change the way we build apps. Do you remember those times when all providers said they were API first before building UI for humans? We build an API because then we can connect.

You don't care so much about the UI and the use cases. You build mini tools, actions, or skills. There's a general multipurpose user interface with language or text. The app does what you'd invent. Today, the apps are like a recipe or a restaurant, where there are three meals. But in the future, it will just be a good kitchen with a good cook. You say, "What do we have? We can do everything." That would be my hope. Less app development and more creativity. That's also in the space where Salesforce is with low code. More people can come closer to computers and find out what they want.

Do you have any specific advice to founders or tech leaders on how to deal with gen AI?

Yes, I do. But first, I want to say Aqiva is not only a PDO. We're also a huge SI partner. Many of our partners are Salesforce customers and have a deep interest in how we can use Salesforce AI. Salesforce successfully created fear-based marketing by telling everyone that you can only trust them with the Trust Layer. I think that's a good story, but it's a little bit overdone. In the past, we also sent Salesforce data over secure internet protocols to APIs. Why not do it now? The benefit of doing it with Salesforce is significant because everything is declarative and per default in a safe way. But as we all know, it also comes with huge price tags.

As a partner, you don't lose much because you are still coding your actions in Apex and Flow as you would for Einstein Copilot. The only thing which sits in OpenAI is this moderation and instructions, and the definition of which tools it can call. But you could build and package such a copilot today with 90% of the code in Salesforce and have them unchanged in the future. When Salesforce Copilot comes out, you move this little part from OpenAI into Salesforce. I recommend everyone to act and experiment now. Make the things in a way where you can later change the technology.

Is there any app you have encountered on AppExchange that excites you in the direction you mentioned – not providing a menu with three items but having a more open-ended interface for users to achieve all kinds of stuff through an app?

Yes, absolutely. I should not do marketing for other companies, but this new ISV wins all the demo jams, OneSight. You have probably heard about that. They have a chat with your org, and you say, "Can you do that for me?" And it just does it. That's cool because it basically makes doing declarative Salesforce even simpler. Just imagine bringing Developer thinking into the world of Admins so that they can do their work in a professional way. But think about if they don't even have to cope with all those metadata artifacts. They just speak to an AI. Instead of turning Admins into Developers by teaching them DevOps, you skip this whole part and have the AI build it in a conversation.

I fully agree as long as the AI respects good practices and version control

That fear of hallucination ended quickly for us. We saw that the more you give the AI instructions, what Salesforce calls “grounding,” the less this hallucination is. If you use those instructions, it works. For example, I always make a demo, then go into the CRM and ask this in the chat window: "I'm a sales guy. What should I work on first today?" And sometimes, it just translates that into a socket query looking for the earliest closing opportunity. However, in some talks, it opens a list view where that data is also shown. Sometimes I thought: "My demo doesn't work." But then I thought: "Wow, it's creative." Sometimes, these hallucinations also lead to new ideas of doing things.

Do you have any vision of bringing the two topics we talked about together? Leveraging large language models in the world of code analysis PMD?

It shifted. Initially, I saw that running OpenAI and ChatGPT on code presented more issues than PMD. I was thinking that maybe this would replace such clunky, old-fashioned tools. I talked to Daniel Ballinger, who runs Apex at Salesforce, and they gave me a different twist on that. They know that more code will be generated in the future by AI. There will be even more risk that something doesn't work. They considered PMD a tool to safeguard this because only deterministic code, only old-fashioned, clunky analysis, can ensure this. So, PMD may become even more important as a fast and static way to check if code generated by Developers is feasible.

So, it will become part of a Trust Layer

Maybe that. It's always the thing you do that is very complicated, and the check is quite easy. That's my hope that I can still run this topic for some years.

I think what could also be interesting is making the results more actionable for a team, for example. You mentioned the fear of having a lot of failures on your CI once you put your PMD quality rules in place, but to break that down to a team, for example, into a prioritized action, is something where I think a large language model might be helpful

Absolutely. There should be enough information on the Internet to help people understand, combine, and make recommendations based on this list of a thousand things. The LLM could actually come up with that. That should not become part of PMD. Let's find a provider who makes some bucks by putting a small LLM wrapper on top of PMD to do that. You could do it at Hutte. I would love it.

Evolve your DevOps

Thank you for tuning into this episode of Hutte's Trails Podcast.

Who would you like our next expert to be? Let us know on our LinkedIn page!

Episode 17: Shane McLaughlin, Salesforce Platform Architect

Watch me 🎬

Listen to me🎙️

Give us a short overview of your Developer career

I had a finance MBA and worked for a big utility company in Houston. They put me in charge of this little e-commerce business, and we would use Salesforce. That was the first time I'd seen or touched it for our customer service. If you called us at the call center or emailed us, we'd be doing typical Service Cloud things with it. It turns out the people we had hired to build the rest of the e-commerce business failed spectacularly at it.

I built it on Salesforce with the help of a couple of people working for me because we had no more budget left to do anything else. That was the awakening: "I can do a lot more good for a company as a Salesforce Developer than I really could managing other people." The company said, "I didn't know you could do that with Salesforce." So, that spun off a few years of building other business processes.

I started off in sales engineering and then moved to platform product marketing, doing platform demos. That's how I started messing with the CLI and plugins to serve my demo needs and make it easier to distribute demo orgs. That's how I also got to know the CLI team and the product.

Fast-forward to 2017, when SFDX and the Salesforce CLI were publicly announced. That brought a lot of fresh air to Salesforce DevOps and how the Salesforce Developer experience is shaped. Do you have any specific memories of that time? I assume you were on that team that launched SFDX back then

No, not at all. When that first came out, I just started moving to product marketing. I was aware of it in the sense that many people were working with it. We would need to be able to talk about it, do demos, use it in demos, etc. That was my introduction to it. As I was looking at it, at the same time, I had a giant spreadsheet that I inherited when I took that job. These are the orgs at these different booths that people might need to log into. Whenever you do one of these, you must spin up and create new orgs and put the usernames in there.

As we were looking at SFDX, it is useful not to demo it but to build demos with it. You should be able to push a button and have an org. When you're done with it, you should be able to throw it away because Scratch Orgs came first with SFDX. You should be able to throw it away and not have to do all the reset steps again. I was initially interested in using it to get rid of that spreadsheet. It was a dream being able to spin up Scratch Orgs and hand them out like candy.

Another big milestone I remember from SFDX was the announcement that the command line became open-source. Do you recall when that was?

That was more of a gradual process. Some of that happened while I was on the team. Initially, there was just one giant monolith of the CLI, and then users could make plugins. We would copy all that to an open-source repo three times a year after a major Salesforce release came out. But it wasn't open-source in the way that it should have been. It was more of a static copy of a point in time.

To take that apart, we broke some of the stuff into libraries. In doing so, VS Code, the VS Code extension for Salesforce and the DevOps Center, and anybody else who wanted to build things could consume those libraries. Those all went out first open-sourced. We started breaking that giant CLI into plugins so you'd have the org commands.

We got higher-quality contributions and bug reports. People would say, "I changed this and fixed the bug." We said: "Thanks, 90% of the work is already done. We'll check it, write some tests, and publish it. Open-source is exciting for us. We use a lot of open-source and have contributed to other open-source libraries. There have been a few things that we've found, or sometimes the users have found, that don't quite work right, which we can contribute back. It's nice working in the open. I like the toolset a lot.

Would you consider your team pioneers for the open-source idea inside Salesforce?

Several teams have contributed open-source work. You see it a lot with developer relations. That was one of the first places where you needed to make it open-source so you could share it with everybody. They probably pioneered getting that stuff through security, using GitHub Actions and pull request processes and all that stuff. I would say we're probably one of the product teams. However, many teams are doing open-source work, especially some off the core platform.

Salesforce.org – the part of the company that builds tools for nonprofits – has also been doing a lot of open-source work for a very long time.

Did you know that nearly 40% of Salesforce Developers contribute to open-source projects, and approximately 45% of Salesforce implementations incorporate at least one open-source solution?

Lightning Web Components (LWC) would be another example, right?

That may have been open-source before the CLI was finished being open-source. You may have seen it, but we've mostly moved all feature requests to GitHub discussions. Once GitHub discussions came out, we decided to adopt that to help prioritize not just bugs but also feature work.

You are the author and maintainer of the awesome SFDX plugins. I think that that's how many people in the ecosystem probably know you and your GitHub. For those who don't know, I would say it's a curated list of extensions to the CLI. We also touched upon it briefly with my last podcast guest, Matthias Rolke, who has something similar now. Could you share what inspired you initially, and do you have any specific plans for that project?

What inspired me initially was a lot of the ecosystem had an inventory CSS. I've used those in a few places where finding a list of stuff is ideal. As new things came out, people put it on the list. I had some plugins from other people I was using then. I knew there would probably be a good chunk of them, and you'll see that was done on GitHub as myself and not as Salesforce. Salesforce is not recommending them.

Additionally, a guy on the internet gave us a list of things we've added since then. We've added the plugins to the CLI, which will show you a curated list in your CLI. It's nice to see the relative popularity and health of plugins.

I think I saw yours showing up first, if I'm not mistaken

There may be a lot of older usage of that. It is primarily unmaintained. Some of those commands have drifted into the actual CLI. Some of them are not as useful now. Some were very specific to stuff I was building for product marketing. You'll see commands like, "I need to set my user profile photo or activate a Lightning branding set." You might not care about these things if you're interested in CI testing, but things that you might care a lot about if you're doing workshops and demos that need to be properly branded with your ‘fake company’ for your demo.

I'd like to touch upon telemetry. I assume your team has pretty unique insights into the CLI's actual usage. Can you share any interesting, weird, or funny observations about the usage?

We collect telemetry. We don't know who you are, and we have to scrub all the identifiable information out. We like to track what commands and flags are being used, but we don't get the values. We get which flags you're using. But we're also interested in the OS and version of the CLI you are running. We also track exceptions. If you get exit errors, we'd like to see those and learn what they are. We may need to search in the code.

Regarding exciting things, I've been interested in Salesforce's transition. 70% of daily executions are now on a new 'SFv2' CLI, and about 30% of that are on some version of the old 'SFDXv7.' You'll see most of that usage is on the very last SFDX that we published. You can write an update, but there's nothing to update to. It's the end of the line there.

If you want to talk about weird stuff, if you look at the top twenty versions, number 15 is really old. It's like '7.123,' which is almost three years old at this point. We don't have a reason why there might be a clump of usage on that really old CLI. We've also been interested in some of the command migration for the new project deployment commands.

It is a set of things and people on the current or recent CLI. About 88% are on the new deploy commands. Only a few people have the current CLI but are still typing for things like “Metadata API deployment.” However, getting people to change their scripts and switch their habits may be harder, but they seem to be doing well.

Some of the stuff has just died. For example, there's an old command, do you know "force:source:status?"

I remember running it. Doesn't it give you the overview of all the connections one has? Or am I confusing it?

That might be the org list. But no, this one tells you what's changed in the org and locally and what might be in conflict. Before, you did a pull or a push, and you would run this command to see what would go in which direction. People have stopped using that command. I think it's like less than 2%. They're using the new deploy preview or retrieve preview commands.

There are people who are not publishing their plugins and keeping them for themselves. How many are on your list in your directory? Do you know?

I don't think we have that many on our public list. We had 295 different plugins that ran in the last seven days. These are all different plugins by different authors. Over 75% of those are not from us. About 230 are third-party plugins that someone's created. You'll see a lot of them have one user and a whole bunch of CI usage. This makes you think someone's done something helpful for their deployment processes or testing. A lot of them have company names. We can see if you name your plugin a company's name, and we can then have an idea of who that might be. The metrics for plugins have been interesting.

You are probably one of the fastest shipping products regarding release cycles within the Salesforce product landscape. Do you still maintain a release frequency of every two weeks?

We release every week. I'll explain how it works. Wednesday is our release day, and we have a nightly release that goes out. It'll be on the nightly channel if you ever want to play with what we merged the day before. Once a week on Wednesday, we promote nightly to become the release candidate. That set of changes will stay as a release candidate for a week. Users like to test the release candidate against their deployment pipeline. If anything is going to break, they tell us, and we can fix and patch it before it goes out. We appreciate that so much. That release candidate then becomes the official release the following Wednesday.

We must patch frequently, even if we aren't fixing and releasing new features. However, you'll see new metadata types for Salesforce in the next major release. We want to get those in so people may start testing on preview Sandboxes and use those new features. As teams finish their metadata, we tend to add those.

The other thing is that internal Salesforce teams like to test their metadata with the CLI. The CLI needs to know about their metadata, which may ship in the CLI six weeks before it's available to users. In doing so, internal teams are using the same CLI. We have to do a lot of releases besides those things. The other thing you'll see a lot is workarounds for server issues, where there's some new error, and it's returnable.

If we're polling for a deployment, and there are new connection reset errors, we would like to be able to put the workaround for that and ship it. That gives the server-side team more time to figure that out without impacting customers using the CLI. However, it may be a little while before they can release their fix, and it may be the next major Salesforce version before they can release their fix. It's nice to be able to patch those things because they break all of our tests, just like they break your deployments.

But there is a lot of beauty to a fast release cycle

It depends who you ask. If you like a certain version – like we saw earlier in the telemetry – if you think 7.200 is fantastic and it does everything you need it to do, you can keep using it.

Practice makes perfect

Thank you for tuning into this episode of Hutte's Trails Podcast.

Who would you like our next expert to be? Let us know on our LinkedIn page!

You can now “pause” both users and projects in your organization, link your own self-hosted GitLab server to a project, and more!

Link a self-hosted GitLab server to your new project

We’ve added a new option to the project setup flow in Hutte. You can now link a self-hosted GitLab server as your project repository.

All you’ll need is your GitLab access token and your GitLab project URL.

Renaming a project on the setup screen

We’ve added a small quality-of-life improvement to the "Project" setup screen. You can now rename your Project directly on the setup screen, instead of needing to navigate to "Project Settings" first.

See the subscription status of users you’ve invited (Partner plan)

For our users on the Hutte Partner plan, you can now see the current subscription status of the customers that you’ve invited to Hutte. Under your "Invitations" tab, you’ll now see a column called “Plan,” which will show you which Hutte subscription plan each of your invited customers is currently using. If the customer hasn’t accepted your invitation yet, this field will be blank.

“Pausing” a user on your Hutte account

We’ve added the capability to “pause” users on your team instead of deleting them when you want to remove a seat. On your "Org Overview" screen, you’ll be able see your number of active and inactive users at a glance.

You can deactivate (”pause”) a user from your "Members" tab.

Deactivating a user will remove that seat from your billing, and that user won’t be able to log in while their account is deactivated. But their account information will still be saved in the system, so if you ever want to reinstate their seat, you can easily re-activate their account with just a click.

Improved project usage control (Partner and Enterprise Plan)

For our users on the Partner and Enterprise plans, we’ve made a few upgrades to the way that you work with projects.

You can now pause (deactivate) a project. Just navigate to that project’s "Project Settings" screen, and you’ll see the option to deactivate the project at the bottom. This will free up a project slot in your plan, but the deactivated project will be preserved for as long as you need it, and you can re-activate it again with just a click. This is great for projects that might need to go on hold for an extended period of time, but will be picked back up again later.

We’ve also added a project counter to the project dashboard, which allows you to see your current number of active and paused projects.

Choosing which commit SHA to branch out from when creating the first commit on a Sandbox feature

When you’re pulling changes on a new Sandbox feature, Hutte automatically creates your feature branch using the branch name you specified when creating the feature; from the creation or last refresh date of the Sandbox you are using.

But if you do need this level of granular control for your feature, Hutte now allows you to specify the exact point in time in the Git repository that you want to branch out from.

Better error messages after failed Sandbox refresh attempts

We’ve improved the error messages that happen when a Sandbox refresh fails. Previously, we used to show a generic error message when this occurred.

Now, Hutte will show more detailed error messages when a Sandbox refresh fails, giving you more information on the specific cause. This should make the error-causing problem much faster to correctly identify and fix.

Timestamps for a user’s last activity

We’ve added a small improvement to the "Members" tab. There’s a new column labeled “Last activity” where you can see when each member of your organization last performed an action in Hutte.

Fixed date fields bug for certain metadata types

There is a Salesforce bug affecting some metadata types that causes the “Last modified” and “Created date” fields to show the date as January 1st, 1970. We’ve fixed this by having Hutte now detect this bug and hide the date fields when it occurs, to prevent any confusion.

Fixed visual design flaw on "Project Overview" screen

We also fixed a minor visual design flaw that could occur on the "Project Overview" screen in the “Connected Repository” box when the Git Org and default branch names were long.

Explore these improvements firsthand

We made a small upgrade to the Sandbox “History” tab. Now, next to each refresh, you’ll see a sentence that tells you which Org the Sandbox was refreshed from.

List view speed improvement

We’ve made substantial improvements to the loading speed of listviews in Scratch Orgs and Sandbox features. This is particularly beneficial for projects with a large volume of completed features and/or terminated Scratch Orgs.

Mitigated risk of overwriting when working in parallel on the same metadata

We’ve made an improvement to the Sandbox workflow in Hutte that fixes the rare overwriting issue of simultaneous changes, which could arise when two users were working on the same metadata in different Sandboxes in parallel.

Now, when you commit for the first time on a new Sandbox feature, the feature branch will branch out from the time that corresponds to the last refresh date of the Sandbox you’re using to develop the feature. This should eliminate the issue of overwriting other feature changes by accident.

Minor updates to the "Pull changes" form

We’ve upgraded the layout of the “Pull changes” form in Hutte. They’re mostly small things, such as removing the option to select a branch to branch out from after the first commit (since the branch has already been created by the first commit).

We also fixed some spacing and styling errors, and a couple of other things. You won’t notice most of these changes, but they’ll make using the “Pull changes” form just a tad smoother going forward.

Hide/show empty components when pulling changes

We’ve added a toggle to the “All components” tab that appears when you pull changes. It’s toggled “on” by default, and hides all empty component types from the list of components. Toggle it “off” if you want to see the empty component types in the list.

We’ve also added a refresh button as a permanent option inside each individual component section.

Branch name will no longer be overwritten when naming a new feature or Scratch Org

We made a minor fix to the workflow when making a new feature or Scratch Org in Hutte. Before, when a user would populate a branch name before naming a new feature or Scratch Org, the branch name would be overwritten when the user named the new feature/Scratch Org. This meant the user would have to go back and specify the correct branch a second time. We’ve now fixed this so that the branch name won’t be overwritten when this occurs.

Explore these improvements firsthand

• Working between Jira and Hutte is now easier than ever. Our Jira Cloud integration now works for Sandbox features and Scratch Orgs alike.
• We’ve added a few new features, such as the ability to “lock in” a default Org and the main active features related to the work item.
• We’ve added the ability to create a new feature in Hutte directly from the “Issue View” in Jira. This will streamline your workflow and save you some valuable time!

When you create a new Hutte feature from Jira, the name will be pre-populated with a combination of “Issue Reference” and “Issue Title” from the Jira project. Using this default name means that when you later create a pull request for the feature, the issue reference will be continuously passed through, and can be referenced and used by an integration between your Git host and Jira, such as automatically completing your issue when the pull request is merged.

Custom success messages for custom buttons

You can now add a custom success message to a custom button you’ve created in your Hutte.yml. The property is called "success_message." The text is fully customizable, allowing you to include text formatting options and hyperlinks.

You can find and configure your Hutte.yml under “Project Settings”.

Setting a "base branch" for Sandbox features

We’ve introduced the option to set a “base branch” for Sandbox features. When you pull changes on a Sandbox feature, you’ll now see a new “From Git branch” field in the commit information section.

By default, this will be set to your project’s main Git branch. But you can easily select a different branch from the dropdown menu.

Show Pool Org status on "Take from Pool” dialogue

We’ve added a small quality-of-life update to Scratch Org creation. When you’re creating a new Scratch Org via the “Take from Pool” option, you can now see the current status of the default Pool Org without needing to expand the drop-down menu. Active Scratch Orgs in your pool will now have a green check mark next to them and say “Active” at the end of the name field.

Show project data on project dashboard

We’ve added more information to the project cards in your project dashboard. For each project, you can now see the number of members in the project in the third line. The fourth line now shows you either the number of active Scratch Orgs in the project (for Scratch Org projects), or the number of active and completed features in the project (for Sandbox projects).

Speed improvements to “All Metadata Browser”

We’ve made some improvements to the way Hutte fetches metadata that should speed up the process drastically, especially when retrieving Apex Classes.

Sandbox Pool: “No refreshes between” bug

We fixed a rare edge-case bug that was causing Sandbox refreshes to occur outside of a blocked window of time instead of inside it, due to a customer’s specific time zone and set time window.

Add column "Created from” on Sandbox list view

We added a new column in the Sandbox list view, labeled “Created from.”

This column indicates which Salesforce Organization each Sandbox was refreshed from. This allows Admin users to have a better understanding of their existing Sandboxes. For example, you’ll be able to see which Org your Pool Orgs are being refreshed from at a glance.

Explore these improvements firsthand

Get in touch with us to discover how we can customize a superior user experience for you!

Hutte expert panel

Harald Mayer

Hutte CEO & Founder

About

Harald is the Co-Founder of Hutte, bringing his vision of no-code DevOps to life. His passion enables teams and individuals to focus on what matters most – bringing value to the users they build for.

Manuel Moya

Salesforce DevOps Consultant & Technical Architect

About

Manuel Moya Ferrer is a highly skilled freelancer who serves as a technical architect, developer, and DevOps engineer. He specializes in Salesforce solutions, covering all technical aspects of their development lifecycle.

As with any other metadata, it's recommended to use a Git-based strategy with the Metadata API for deployment. To make this process easier, Hutte provides an excellent UI and UX. As Salesforce offers detailed documentation to help users understand what needs to be deployed, these recipes will reference this documentation.

Due to differences in the steps required depending on whether your Experience Cloud site is Lightning Web Runtime (LWR) or Aura, we have created two step-by-step recipes. Refer to the steps that are applicable to you.

Steps for sites using the LWR framework

To provide steps for a site using the LWR framework, we use the "Build your own (LWR)" template when creating a new site. Upon creation, we customize this new site by adding a placeholder Lightning Web Component (LWC).

Prerequisites

Experience Cloud site creation

• In your Hutte Project, create a new Hutte feature, assigning the org where you will create the Experience Cloud site. It's important to create the Hutte feature before making changes so that we can track the new changes, making the commit experience more straightforward and quicker.
• Use the "Build your own (LWR)" template to create the new site.

• Deploy the "helloWorld" LWC. Navigate to the workspace builder and add the LWC mentioned above to the top of the site.

• To avoid future deployment issues, it's recommended that you add a "urlPathPrefix" to the site URL. You can do this by going to "Administration" and "Settings."

• Save the changes.

GitHub setup

Prerequisites

• A GitHub repository with a valid SFDX project.
• A target org authenticated with SFDX locally.

Enable “Digital Experiences” in the destination org

Ensure “Digital Experiences” is enabled in "Setup," "Feature Settings," "Digital Experiences," and "Settings."

Once we have completed the prerequisites, created the site, configured GitHub, and enabled “Digital Experiences” in the destination org, we can proceed with tracking the site changes in Git and deploying them. Here are the steps:

• Commit the baseline metadata and the custom LWC: Navigate to the previously created Hutte feature and click "Pull Changes." A long list of changes will be displayed, which is expected since Salesforce does a lot of behind-the-scenes work when creating a site. Only select the necessary changes as specified in the Salesforce docs by looking at the "ENHANCED LWR SITE" column of the table. Include the LWC that was previously deployed and added to the site page. All other metadata will be automatically generated in the destination org upon deployment – we won't need to deploy them.

• Replace "siteAdmin" and "siteGuestRecordDefaultOwner:" Change these fields in GitHub to use the username of the site admin in the destination environment.

• Troubleshooting error "The value for urlPathPrefix in DigitalExperienceConfig isn't validerror:" If you encounter this error during the next deployment, we recommend adding a "urlPathPrefix," which will solve the problem.
• Create a pull request through Hutte: Creating a GitHub pull request (which we can do from our UI) allows another person to review the changes. A deployment validation will automatically run as part of the GitHub Action from the "cicd-incremental-deployment" recipe. This action validates that the changes included in the pull request can be deployed to the destination org without issues, without actually deploying any changes. Finally, check the details of the GitHub Action run to see the logs of the metadata changes being validated.

• Merge the pull request and automated deployment to the destination org: Upon successful validation and code review, merge the pull request. An automated GitHub Action will deploy the changes to the destination org.

• After the GitHub Action is successful, verify the changes in the destination org.

Steps for sites using the Aura framework

To provide steps for a site using the Aura framework, we reference the Help Center template. The Help Center template uses the Aura framework, so the same guidelines in this recipe apply to any site using the Aura framework. This recipe also includes the “cicd-incremental-deployment” recipe to validate (in a pull request) and deploy the Experience Cloud sites.

Prerequisites

Experience Cloud site creation

• In your Hutte Project, create a new Hutte feature, assigning the org where you will create the Experience Cloud site. It's important to create the Hutte feature before making changes so that we can track the new changes, making the commit experience more straightforward and quicker.
• Create a Help Center site in your Development Org (Digital Experiences).
• Add the “sample image” as a background to the hero component.

• Save the changes.

GitHub setup

Prerequisites

• A GitHub repository with a valid SFDX project.
• A target org authenticated with SFDX locally.

Enable Digital Experiences in the destination org

Ensure "Digital Experiences" is enabled in "Setup," "Feature Settings," "Digital Experiences," and "Settings."

Once we have completed the prerequisites, created the site, configured GitHub, and enabled Digital Experiences in the destination org, we can proceed with tracking the site changes in Git and deploying them. Here are the steps:

• Commit the baseline metadata: Navigate to the previously created Hutte feature and click "Pull Changes." A long list of changes will be displayed, which is expected since Salesforce does a lot of behind-the-scenes work when creating a site. Only select the necessary changes as specified in the Salesforce docs.

• All other metadata will be automatically generated in the destination org upon deployment – we won't need to deploy them.

• Commit extra metadata to avoid deployment issues: For Aura communities, including the Help Center community, commit the "SiteDotCom" instead of "ExperienceBundle." Commit the "CommunitiesLanding ApexPage," its Apex controller, and the respective Apex test class to avoid deployment issues.

• Commit the customizations: Apart from the baseline site, we added a sample image to the hero component as a background. Add the "ContentAsset" that includes this change.

• Replace "siteAdmin" and "siteGuestRecordDefaultOwner:" Change these fields in GitHub to use the username of the site admin in the destination environment.

• Create a pull request through Hutte: Creating a GitHub pull request (which we can do from our UI) allows another person to review the changes. A deployment validation will automatically run as part of the GitHub Action from the "cicd-incremental-deployment" recipe. This action validates that the changes included in the pull request can be deployed to the destination org without issues, without actually deploying any changes. Lastly, check the details of the GitHub Action run to see the logs of the metadata changes being validated.

• Merge the pull request and automated deployment to the destination org: Upon successful validation and code review, merge the pull request. An automated GitHub Action will deploy the changes to the destination org. After the GitHub Action is successful, verify the changes in the destination org.

Make your site an experience

Deploying Experience Cloud sites, whether using the LWR or Aura framework, can be streamlined and efficient with the right tools and processes.

Follow these recipes to manage your Experience Cloud deployments confidently, and take advantage of Hutte's features to enhance your CI/CD workflows.

Tune in 🎬

Listen up 🎧

How did you get in touch with Salesforce first, and how did it evolve?

I didn't know about Salesforce before, but I studied computer science in Munich and worked as a student. For my bachelor's, I worked at a Linux distribution company. This is basically where my knowledge of command-line tools and open-source comes from. During my master's, I was looking for a new job. At that time, many interesting companies were far outside of the city center. I searched nearby and found a Salesforce consulting partner. This is where I landed my job and stayed there for seven years, starting as a Salesforce developer doing Apex, Visualforce, and Aura.

So, you weren't hired into a DevOps or release manager role, but it came during your job as a developer, right?

Exactly. For example, I hated how I had to do those things with the IDE. I loved the platform, but I hated using Eclipse. So, there was an excellent alternative IDE called MavensMate by Joe Ferraro. It was only for macOS, and my computer was a Windows PC at home. I was running Linux, so I just ported the MavensMate to Windows and Linux. That was also when I did my first pull request on GitHub, which was rejected. So, my first experience with open-source was horrible.

I can't blame Joe because he rewrote the whole tool to switch to Python instead of Ruby. But I liked looking into open-source tools – that was my passion from day one. I then switched to deployment release management.

Did you know that over 70% of Salesforce customers actively use or contribute to open-source tools to enhance their Salesforce implementations?

What was your stack back then for deploying or releasing? Was that your default?

No, the company default was change sets, and I explored how I could enhance that. With the end migration tool and package XML deployment, I discovered that creating outbound change sets in the UI is possible. You can then deploy them to your sandbox with a package XML referring to the outbound change set name. You were able to add the metadata components based on an XML package file. I improved my process from time to time to be faster and leverage Git for myself. Later on, I was able to bring this into the company.

Was that what you then open-sourced as the "force-dev-tool?"

That came later. In 2014, it was time to write my master's thesis. I was really in love with this topic, so I suggested it. The end result was a tool called "force-dev-tool." This is what I developed in my master's thesis. In my master's thesis, I was writing a CLI, which didn't exist back then. But there was the end migration tool. A CLI was essential to automating things because it wasn't so scriptable. The other outcome of the thesis was implementing CI/CD with Salesforce. I explored implementing CI by doing validation deployments to an empty sandbox.

Salesforce then released SFDX, which included a command line. It was probably the first one that Salesforce published or made accessible. Can you share your perception and memory about the launch of SFDX and Scratch Orgs? Also, how did it impact DevOps?

That came as a huge surprise to me. I think Salesforce DX was announced at Dreamforce 16. This was after my thesis. It came out of nowhere. Back then, the CLI was slower than my tool. The massive launch was, as you said, Scratch Orgs. This blew my mind because I explored this for CI, having a clean or empty org. I knew the benefits of having that, but not for development. Scratch Orgs allowed you to get your own empty org for development, which wasn't possible in my world before. I was thus hooked. I participated in the pilot and knew that my first dev tool was eventually going to be deprecated. I embraced Salesforce DX completely.

Can you share a bit about your open-source work on the generation of Salesforce CLI and SFDX

That comes back to my job, where I worked at the SI and later as an independent DevOps consultant. I like to see problems firsthand with the customer – the more, the better. I was able to know what things don't work currently. This was always a good point for getting ideas for open-source projects. One was an SFDX browser plugin, filling the metadata API gaps with browser automation. You could perform clicks in a scripted headless browser, which was a massive success for our project. We were able to automate the missing pieces.

You mentioned that you are an independent Salesforce DevOps Consultant, dedicating part of your time to Hutte. It's no secret that you have been vital in getting the product to where it stands today. Please share a bit about your choice to split your work

I need a variety of things that need to be fixed. Being able to build something on both ends – the client and product side. I enjoy participating on both ends. That makes me really happy to see as many problems as possible. I think I have a passion for diving into problems, reporting bugs, and making them reproducible. This is part of my job, and I enjoy it.

Sometimes, a customer or user reports a bug that we can trace back to the Salesforce CLI. I think you have already earned yourself a reputation for diligently reporting bugs to the CLI team. I think it's a very fruitful collaboration with the Salesforce team owning the CLI

The Salesforce CLI team is really open. They have a Slack channel, and they respond to GitHub issues. I only have praise for them. It's really great.

Do you have any ongoing Salesforce open-source projects?

The Salesforce plugin ecosystem is quite good. There are well-known plugins from "sfdx-hardis" and "sfdx-git-delta." I discovered most of them from Salesforce's Shane McLaughlin's list of SFDX plugins. This is a handpicked list. I think there are more beneficial plugins that are not known. I'm building a website that allows others to explore and search for the necessary plugins. This is my current project. It's already public, but I look forward to getting some users and feedback. The name is "sf-plugin-explorer."

Did you buy a domain? Is it reachable under that domain or do I have to check out your repo and run it on my machine to access it?

It's a website published with GitHub pages. My goals for this project were that it shouldn't cost anything and that it should be as simple as possible. Right now, it looks really bad on purpose because I first want to improve the data and make it pretty later on. If it turns out to be a success, I will think about buying a domain. Right now, it's hosted for free and with the least amount of effort possible.

Problem-solving made simple

Thank you for tuning into this episode of Hutte's Trails Podcast.

Listen up 🎧

Tune in 🎬

What is your history with Salesforce? How did you get in touch with Salesforce technology, and in which role? When was it, and how did your career in the ecosystem evolve from there?

First, I appreciate the work you have done with Hutte. I like the product because I was one of the first customers or beta users, so I love what has been done to it so far. I also appreciate the impact that Hutte has had in the ecosystem as far as DevOps is concerned.

But talking a little bit about my career, I think my first contact with Salesforce was in 2008 when I came to my former manager and asked to work with something different. I was slightly saturated with the technologies they had been working on, like Java. And then she said, "All right, I'm going to give you a new opportunity. We just had some engineers come from San Francisco, and they learned some new technology."

Another contact I had in the open-source community during that time was using ANT Migration Tool, but I didn't enjoy it as much. I then found another excellent repository. I think it was from Matthias (Salesforce DevOps Consultant, product supporter for Hutte, and future Trails Podcast guest). As far as I remember, he created a repository called "force-dev-tool." It's already archived, but it helped a lot.

I also spoke with him briefly on Twitter (X). I like Twitter because I contact the product teams from Salesforce when I need something. It's a faster way to do that.

Coming back to the point of my career, I moved to consulting. I worked on many large projects, but it was painful from a DevOps perspective. We used to utilize change sets, and we would spend six months developing everything in there. At some point, we just deployed UAT. Maybe one week before we went live, we would have ten engineers in a war room trying to create code coverage to deploy. It was a kind of integration test.

We didn't use that trick of adding a lot of 'i++' in the code. We would say, "Okay, let's create code coverage because the deadline is almost here, and we need to deploy to production." I was slightly frustrated because I already had some background in Java and other technologies. I saw that the Salesforce platform was very behind.

Around 2015, I traveled to Europe. It was my first project abroad. My team arrived to work for a month. In that month, we spent a lot of time building new functionality. We finally reached the last week and allocated time to plan to do the deployments and change sets.

One day before the deployment, my team went to the grocery store. We bought a lot of chocolate and coffee. Everybody was prepared to start creating and deploying the change sets, but the deployment was already done. I then introduced them to the way that they could do it. It wasn't CI/CD. It was using scripts from Force Dev Tools.

Everybody was shocked as we deployed everything in half an hour, and only minimal configurations were left to do. Management then invested the money and gave me some budget to apply CI/CD, which improved the Salesforce lifecycle and the value of the consulting firm.

Did you have a specific job title as a DevOps or release manager, or were you one of the developers on that team and took the responsibility to improve the delivery methodology?

When I moved to that consulting firm, I moved as a Salesforce Technical Architect. I was leading the development of best practices. At that time, I only knew a little because my background was more Java-based. When I learned from Salesforce, they'd mention tests. But there are many tests, like unit, integration, and end-to-end tests.

You need to understand when you will use them, how you will run them, which stage of development you can run them, etc. So, I didn't move to the Salesforce ecosystem without this knowledge. A lot of the knowledge I got was through learning what didn't work. I didn't find any documentation. I think my primary source was Jeff Douglas' blogs.

I think in 2018, SFDX became generally available. I assume you were an early adopter?

I think it was in 2013 when I remembered that the FinancialForce library was launched. But talking about Salesforce DX, I got very excited trying to find the link and install it. I remembered that they were working on one large project. Whenever I used a command to deploy the code to a scratch org, I got a non-descriptive error. Imagine you have 10K of metadata you're trying to deploy. It's very painful to work with that. But when I saw that, I thought that's the way to go.

Can you tell us how Flxbl (formerly DX@Scale) evolved?

My contact with Flxbl was interesting because, in 2018, I moved to the Netherlands to have the opportunity to work abroad. It was one of my dreams. The first project I worked on was for a company that focused on building things properly. We used a lot of Flxbl, Salesforce DX, and packaging.

We learned what to do and what not to do. For instance, when you use many namespaces and need to do some data migration, it's excruciating. So, this is a disclaimer to be careful if you are thinking of decoupling your domains using a namespace.

But going back to the point, my involvement with Flxbl revolved around working for the first customer of the outsourcing company that they used to work for. My contract then came to an end, and my former manager moved to another company.

I texted him: "Hey, I want to keep working with you because I like your leadership." I liked how he gave me flexibility and budget to work with excellent tools. I also saw the business impact of using the proper tools and techniques. I was then hired to work with him in this new company. At that time, he moved from a manager position to the CTO of the company.

My CTO hired me to lead that development, but we already had a consulting company with some developers and an architect who was already building something. They were basically using things like change sets, and one of the first questions they had was:

• "Okay, why are we going to change something that is already working?"
• I said, "It's okay, but we are thinking about the future when the company grows. How are we going to be scalable? Maybe it was working well for that size of the company, but think about the future."
• My CTO already knew about our experience and the way to go. So, it was terrific that the company's leadership understood where we should go.

My manager gave me the power to use scratch orgs, packaging, etc. As we know, one of the very painful parts of DevOps used to be scratch orgs. Scratch orgs were fantastic because you just created them from the source. It's source-based development. However, the time it took to create the scratch org was long. In the beginning, it used to take thirty-five minutes to install the package. But during the release period of Salesforce, it took two and a half hours.

I was thinking about how we could fix that, so I started thinking about scratch org pooling. I considered creating a “Node.js” microservice to pass the DevHub and some basic information. When I went on Twitter, I remember somebody posting about Hutte. I contacted Evgenii (flair's CEO) and a former developer and was introduced to this fantastic tool we could start using. Regarding pooling, developers didn't like (or know how) to use Git.

My CTO really liked CI/CD, and Hutte was perfect as it allows those who don't know or have enough knowledge about the command line to go to Hutte, click a button, and create sandboxes or access sandbox pooling. I think that's the main point for a lot of companies. When I talk about Salesforce, they say, "We need to use a lot of CLI and Git commands. And 67% of the team are administrators. How can we do that?" I think you can do that with Hutte and Flxbl.

After one year of the project with Flxbl, it ran smoothly. We released weekly as a small team. After one year of the project, another large company acquired that company. In two or three years, they acquired four or five different companies. When I moved to this new company for their new structure, my challenge was that we had one team working well and delivering fast. When they acquired all those companies with different teams and merged those orgs into one, they also had to keep the velocity.

My first challenge was to make this scale scalable, as we no longer have just one team. We have seven teams, and I needed to figure out how to keep the value stream flowing to production. That was how I had the initial contact with Flxbl.

The first thing I thought was that we had to have modularity. When you are working in the sales and service domain, for instance, sometimes you just need to create a report and deploy it to production. I started to create a draft of the solution. I went to Twitter again and asked the community which way to go, and that's how I got very involved. To make this story short, we had multiple teams releasing daily. Imagine having seven Salesforce teams deploying two or three times a day. It's unbelievable.

For instance, if you need a new report in production, you can quickly create the report and deploy. You don't need to wait hours for other domains. Decoupling the domains and having this modularity guided by a flexible framework was amazing for us. It was good that we had the observability tools as we could show leadership in the company that the budget and the time they spent on refactoring or modularizing was worth it. We had one big package split into 150 packages that allowed us to deploy many teams or different domains, decoupling and deploying every day.

You probably started taking things into your own hands, creating issues, pulling requests, and making improvements, right?

Exactly. Since I started using Flxbl, I have liked thinking outside the box and finding new ways to do things. When working on a small project, you might see only some of the pain points you will have in the future. With Flxbl, you can think about feature-based packages when you're deploying and thinking about modularity.

I submit a pull request where you can retrieve the metadata, check the status of the permission set group, and deploy the other packages just when the permission set groups get calculated. So, that was the first involvement I had with Flxbl. Nowadays, I am one of their maintainers as it's open-source. It's a struggle because I have a job and have to do it in my free time. So, I need to share this time with my family, daughter, and girlfriend, but that's life.

It’s all in the delivery

Thank you for tuning into this episode of Hutte's Trails Podcast.

Watch it 🎬

Listen to it 🎧

How did you get in touch with Salesforce? When was it? How did your career evolve from there within the Salesforce ecosystem?

I started working with networking at Cisco and Juniper. I was configuring all these systems but was not finding happiness in this. I knew that what I wanted to do was code and work as a developer. But I needed to find out specifically which technology. I was looking for a company where I could learn how to be a good developer.

I saw an offer at that time in FinancialForce, here in the city where I have always lived. It was a junior developer offer. I didn't know anything about Salesforce, but I knew that FinancialForce was a good company to work with, so I interviewed there. One of the interviewers was Alba Rivas.

I liked the people and decided to start there. I learned a lot about Salesforce's best practices, and the people working there were great mentors.

You started with a big ISV but have also done work outside the ISV space, right?

I learned a lot about the enterprise ISV side because FinancialForce was a very mature company. I also learned about:

• Development
• Coding practices
• Delivery processes
• The complete development lifecycle.

I was very interested in the DevOps side of Salesforce.

At that time, I decided to switch to Copado. I worked for a few years there as a technical lead. I went to Copado not only for DevOps but also to understand how work was done in a startup ISV. At that point in time, Copado was ending the startup phase because it was already quite a big company. It was going more into the mature company phase. I learned much about this migration and how you develop when you need more features. It's a different way of thinking.

After that, I also wanted to learn outside the ISV ecosystem, so I entered a kind of Salesforce consultancy. The primary mission was to create AppExchange packages for customers. I worked as a developer and in similar roles for some time. I learned a lot about customer interactions, but I wanted to keep learning about DevOps because I knew there was much more to learn.

I decided to switch from a contractor to a freelancer, and I started working and contributing to Hutte and other companies as a technical architect and DevOps consultant.

What excites you in your current role, working with different customers and choosing your projects and assignments?

I always try to maintain my technical side. When you evolve from a lead developer position to a higher step in the ecosystem, such as a technical lead or architect, switching to more management or solution architecture tasks is very easy. I have also realized that it does not motivate me to wake up and work many hours. I like the technical side of Salesforce. Ultimately, it's also where I am valuable because I feel much more helpful in doing something I know I am quick at, more efficient, and enjoy.

Could you point out any of the recent announcements or feature releases on the Salesforce platform that specifically excited you or something that has been announced that you're looking forward to?

Years ago, the one that amazed me was the release of custom data types. I think custom data types, especially to ISVs, made a massive contribution in extending the behavior of a package with extension packages, with second-generation packaging.

On the other hand, one of the things that I have recently worked with is Flow Orchestrator. I thought it was useful until I discovered it is a freemium product. You can use it for free, but after a certain number of requests, you must pay.

With AI and all those kinds of features that Salesforce is releasing, you don't need a skilled developer. It's also an interesting step that Salesforce is taking. On the one hand, it is very positive because it has enormous potential.

However, it is also concerning as the technical depth that can be created for the future uses these AI systems and gives you a solution, but it is not the best solution. You still need an intelligent person behind the scenes who understands how to implement the solution the AI gives you. This will create a lot of technical depth and maybe bad decisions that we will need to fight in the future.

I'm curious to hear your thoughts about Git-based development in Salesforce

I wish I could say by next year, every company in the market will use Git-based development. But I think the reality is a bit different. On one side, I think companies are incrementally switching to Git. They are not all doing it simultaneously and will probably not all be doing it this year. But I think it's slowly evolving. However, many companies may need more resources, such as having skilled developers or a DevOps engineer on board, to cover this transition.

However, some companies only realize the challenges of the old way of developing or releasing when they have a deployment issue that has a real business impact. As this thinking is late in the game, they will try to switch the complete development lifecycle quickly.

We also need to talk about all the community contributions, like DX@Scale and CumulusCI. Flxbl is not from Salesforce, nor is DX@Scale. We have made a significant community contribution, which in the DevOps world has been immense and has made the transition to it much easier. If we talk about five or eight years ago, there was little for DevOps. Either you paid a product for it, or you used change sets. There is now an extensive landscape of options to make this transition easier. The community in this aspect of Salesforce has been incredible.

How does your upcoming travel schedule look? Do you still visit many events? Did you apply for any talking slots?

I have been a speaker on four or five occasions, but I do it occasionally, only when I have a topic I am really enthusiastic about. This year has been a busy year. I wish I could have made it to dreamOlé in Granada, but it wasn't possible because of a personal commitment. But talking about the future, I want to go to TDX, which is the one that I have always been looking at. It's quite difficult to go to TDX, but if we need to create a wishlist, that will be on it.

Apart from that, another thing I have learned about events is that I have more fun at small community events, like dreamOlé, CzechDreamin, or London's Calling, than at huge events like Dreamforce or the World Tour. These are huge events, and meeting with the people you are familiar with in the ecosystem is difficult.

Until next time

Thank you for tuning into this episode of Hutte's Trails Podcast.

Now, you can pre-create a project for your customer and add a specific user from your team (automatically set to the person sending the invitation) who is instantly made a Project Admin. This allows them to assist your customer with the setup process.

Additionally, a new "Invitations" tab has been added to your Org menu. This enables you to monitor sent invitations and their acceptance status.

When creating new projects on the Partner plan, this now defaults to an invite dialogue. You can easily toggle to creating an internal project at the click of a button.

Salesforce deployment status now linked in the "Timeline"

We made a small improvement to the deployment status interface. Now, if a deployment fails, you can click on the red box in the "Timeline" to open a deep link to a detailed “Deployment Status” page, where you can investigate the reasons why the deployment failed (e.g., a lack of test coverage, etc.).

"License type" now defaults to "Developer” during Sandbox creation

We made a minor improvement to save you a click: When you’re creating a new Sandbox, the “License type” field will now default to “Developer” instead of starting empty.

Salesforce connections and Git repositories now searchable during project setup

We’ve added search functionality to the Hutte project setup flow.

This is especially valuable for Enterprise customers with dozens of Salesforce Org connections and hundreds of GitHub repositories.

No more scrolling through an endless list – just type the name of the connection or repository you want to link in the search field. Even small amounts of time saved add up fast.

Explore these improvements firsthand

Get in touch with us to discover how we can customize a superior user experience for you!

Listen up 🎧

Tune in 🎬

How did you first get in touch with the Salesforce ecosystem and technology, and how did your career evolve from there?

I have a technical background. I started telecommunications engineering here in Granada, the city where I live. My first jobs were as developers for other technologies. I knew Python, I did things with Java, and so on. Because of that, I was offered a position as a back-end developer in a partner of AppExchange that has some applications on the Salesforce marketplace.

Did you then move from working for an AppExchange ISV partner to Salesforce itself?

In the middle, I spent some months in a Salesforce training company, which offered courses about Salesforce development and Salesforce in general. Then, a position opened in the team I am currently in, which is developer advocacy for the platform. I knew many people from that team because I was very active in the Salesforce community. I was also a Salesforce MVP. When I heard about the position, I thought this was for me. I also liked teaching and training, so I applied for the position and got it.

What are some feature releases that specifically excited you in the past? Or is there anything upcoming that you are looking forward to when we look at the whole bandwidth of technology the Salesforce platform offers its users and partners?

Lightning Web Components were a complete game changer. Before they were available, we had to code with Visualforce, and Aura was somewhere in the middle. When they came out, they were an open and standardized way of building front-end with well-accepted technologies in the development ecosystem. I was so glad that I could learn JavaScript very well and better CSS, HTML, and web components. It is entirely standard, although we provide a thin layer on top of that so you can use them in Salesforce more agilely.

The second one, of course, is AI. Generative AI has come here to stay, and it's been a small revolution. I think it has a lot of potential. There are many opportunities for companies to develop themselves and customer applications and create custom workflows using AI features. I think Salesforce is doing a great job of making things easy for customers regarding AI adoption.

I was initially skeptical when we started to create our own AI products, but now that I've been playing with them for a few months and implementing things myself, I think it's super powerful. There are many use cases that people can implement and for which they can leverage the help of AI.

Do you see AI changing the life of Salesforce Developers, let's say, from local to pro already now, or do you think it will take more time?

I like saying that developers can get involved with AI in two main ways. One of the ways to do this is by using the generative AI features of the platform to create apps. By the way, you can try it out for free, because you don't need a license for that, but using them in production depends on your company.

Suppose your company purchases those licenses or add-ons and invests in AI. In that case, developers must get involved with Prompt Builder, Copilot, and Model Builder. Their life will change in some sense because they will be developing generative AI applications, on top of the applications they are used to developing.

The second tool applies to every Developer – Einstein for Developers. It is an assistant that you can use in Visual Studio Code. It is an extension that you install, and it helps you generate code and learn how to generate code. There are three ways in which you can use it.

• One way is prompt-based, which is probably helpful for beginners and those who are learning and want to ask Einstein to generate classes and methods that do certain things.
• The next is inline suggestions. If you activate Einstein for Developers in your org, while you are typing and creating your code, Einstein will give you suggestions. Many times, those suggestions are very accurate because Einstein for Developers takes into account the files you have opened in your project. If you are using a certain style guide or programming methods, the suggestions will follow that same style.
• The third way you can use it is to generate tests. You can go into a method, click the right button, and select "Generate test." This one is complex, as creating tests is hard work. It's not going to be 100% right most of the time, but at least it's going to generate some structure. It's also going to do some work for you so that you can start playing with that test and finalize it. It saves you time and makes you much more productive.

Do you have any thoughts about open-source and Salesforce and how they play together?

Salesforce was the first one to turn towards open-source because LWC is open-source. The Salesforce CLI is open-source and all its plugins – not 100% of them, but most of them. I know there's been an ongoing effort to open-source all the different plugins and technology. LWR is also open-source. So, it's something that Salesforce is adopting as part of its philosophy and pushing internally and externally.

I think that's probably one of the reasons the general open-source ecosystem around Salesforce is growing. I can tell you that it is growing because I've been looking at some of the repository statistics of open-source libraries:

• “sfdx-git-delta” from Sébastien Colladon has 60K downloads a week, which is impressive.
• SFDMU, which is the Salesforce Data Move Utility, has 6K downloads a week.
• We have DX@Scale (now Flxbl), which has 4.3K weekly downloads.

There are many more plugins, libraries, and frameworks people are open-sourcing, maintaining, and downloading. Many of them apply to DevOps, which allows our customers and partners to build their own DevOps workflows using a combination of paid and open-source features. Everything is open-source, which is terrific.

Do you think that going Git-based will become more mainstream in Salesforce teams?

I think that's definitely going to be the trend. But I also think that there is a lot of work, a lot of education, and a lot of advocacy to do. Many people just don't know what's available. When I go to conferences, give talks, have discussions, and do some networking, many people don't even know that the Salesforce CLI exists.

It's surprising for me as I'm always learning the latest technologies because I work for Salesforce, and it's my job. But it's not that surprising for other people. I have many colleagues and friends who work in different companies, and they explain to me which practices are being followed.

Sometimes, it's not a lack of knowledge, but a lack of investment from the company. A lack of investment usually means a lack of knowledge from company directives that don't see the value of investing in certain features. This could maybe be due to us (in Salesforce) not telling the whole story or telling the story in a way that conveys value.

I do, however, think that many people are helping with this. For instance, open-source advocates who have been building libraries – and yourself with this podcast – are doing a fantastic job advocating the right thing. I hope that more people adopt Git-based development and proper CI/CD best practices in their Salesforce projects and implementations over time.

What's coming up for you on your travel schedule? Is there any event that you are specifically looking forward to?

We are doing an AI + Data World Tour globally. I'm presenting at several places. For instance, I did a workshop in Granada. I enjoyed it because it was very new for everyone. People usually have many questions, and I interact with them a lot during those meetings. I think that they are finding that super helpful. It's like a session in which we explain everything around the new generative AI features and how Data Cloud supports them.

In addition, I am attending two new community conferences. One of them was Wir sind Ohana in Berlin (it took place on 24 May), and the other is Portugal Dreamin' in July in Lisbon. The passion that you see in first-time organizers is fantastic. I love that every time I go to a first-time community conference, it's like the best conference ever.

Until next time

Thank you for tuning into this episode of Hutte's Trails Podcast.

Last but not least, read on as we unveil further improvements, including our 'simple deploy' functionality and enhanced billing options.

Job abortion

We've added the ability to abort long-running operations on your Salesforce orgs. You'll find the new "Abort" button throughout Hutte – whether you're executing custom scripts from custom buttons, pulling changes, or deploying a feature to a target org.

Improved custom button interface

We've refined the positioning and alignment of main actions like "Log in" and "Pull changes," as well as project-specific actions (custom buttons), to optimize the use of available screen space.

Enhancements for browsing all metadata of an Org

We've enhanced the loading behavior when browsing "All Metadata" in your connected Scratch Org or Sandbox. This update prevents occasional timeouts that happened previously and improves the user experience. Additionally, we've introduced indicators to display the number of metadata components in each directory.

Further improvements to the 'simple deploy' functionality

While we suggest that deployments should ideally be managed by your pipeline, we understand there are situations where a quick deployment of metadata changes to a target organization is necessary.

Therefore, we continue to enhance our simple deploy functionality. The latest improvements display the type of deployment (validation or full deployment) and the target organization on the timeline. This way, you keep this information in view during and after your deployment.

Billing user and enhanced billing page

We have good news for organizations that handle Hutte billing separately from the actual user team! You can now conveniently invite a billing user who has access to our significantly improved billing page. They can also view the plan overview, which helps you select the most suitable paid plan for your needs. Billing users are free of charge, and there's no cap on the number you can create.

Additional enhancements

• We now show the pull request link on a Sandbox feature without refreshing it (when implicitly creating a pull request).
• When parallel feature development in Sandboxes is enabled, this no longer applies to Pool Orgs
• We have a new ‘combobox’ component implemented throughout the app.

Experience these transformations firsthand

Listen up 🎧

Watch it in action 🎞️

Please give us a brief overview of how you first became involved with the Salesforce ecosystem and how your career evolved from there

I started as an intern on the nonprofit side of Salesforce work. The VP asked me to learn Salesforce, so I went the Admin route. It was before Trailhead existed, so I spent a lot of time looking at help articles and trying to understand what Salesforce was.

Did you know that Salesforce's Trailhead platform launched in 2014 and has empowered over 30 million learners globally to skill up and advance their careers in the Salesforce ecosystem through interactive, gamified learning experiences?

That led me to learn about the Nonprofit Success Pack (NPSP), one of the largest managed packages created by the community and then taken in-house at Salesforce itself. With that set of packages, I became familiar with installing them and getting them up and running at the nonprofit I worked for. From there, I transitioned into a job in San Diego, where I'm now based.

I was working with another company in the nonprofit space. I was their first technical Salesforce-focused support person. They had a product on AWS (their app), but the integration was Salesforce. I focused on that managed package within that company, transitioning from technical support and working with customers to working with the dev team.

I also did a mix of testing and DevOps tasks building environments when scratch orgs were brand new. I then transitioned to Salesforce in their nonprofit division, working on NPSP. I moved to what many call "the Mothership" and worked there for a few years.

So, NPSP didn't start at the Mothership but was a community project that Salesforce took on?

Yeah, that's what I understood from people in the community. This was before I started using NPSP. I think the story goes that it was an open-source community project that was then brought into “Salesforce.org.”

They funded and supported it under the Salesforce Foundation, Salesforce's nonprofit. Later, "Salesforce.com" purchased "Salesforce.org" right when I joined. But it started in the community and is open-source.

It's probably one of the packages with the largest subscriber base. I think there were about 30K subscriber orgs in that package. So, I can imagine that it raised some challenges for DevOps processes and pushed the tooling that Salesforce also came up with to bring in proper practices around packaging and distribution

I think CumulusCI itself was born out of the need to scale many of these issues that were being done with small one-off bash scripts or some smaller processes being done manually. But once you hit that set, scale, and size, you need to figure out a better way to distribute and update the package. It's actually a set of multiple packages, dependencies, and things like that.

How did you see the big picture of the Salesforce DevOps ecosystem evolve over the past few years until now?

Much of my experience comes from the ISV side of DevOps, which is 'a niche within a niche, within a niche,' because Salesforce itself has its flavor of DevOps from, if you say, "Oh, I'm a DevOps Engineer." I always have to caveat, "No, I'm a Salesforce DevOps Engineer," which is a little more focused on the ISV side. That's even its own kind of subset. In terms of how it's changed, I feel like I've benefited from being more on the end-user side of DevOps, even though I've also been developing some of these automations.

I think we've gotten to a place where many of the tasks that were manual early on can be automated. Whether that's creating an environment with, for example, scratch orgs or even using the CLI to create sandboxes, it's about being able to create an environment in a programmatic way that used to be impossible. That was a huge achievement. And then getting deeper into metadata and data configuration while these processes were partially automated.

I'd also say that any process you want to do can be automated today. That being said, I think there's still a long way to go to actually being able to practically automate everything. Just because you can't do it doesn't mean it's easy to do. For example, there are still some things that can be done programmatically that I've personally built UI automations to do.

We've come a long way in terms of having the capabilities to simplify things and actually create a full end-to-end development flow. But there's still a long way to go to actually wanting to do that in every situation and having enough resources to do it.

With Git being somehow de facto at the core of most DevOps processes, how do you see the penetration of Git-based development in the Salesforce ecosystem?

Between the partner community of, for example, ISV and OEM development versus customers on the ISV side, a good portion of midsize to larger ISVs are doing Git-based development.

In fact, over 90% of Salesforce Developers use Git as their primary version control system for managing Salesforce metadata.

Many would say they want to have a better branching strategy. But using version control as your source of truth is pretty common (less so on the customer side). I think one of the biggest reasons for that is the importance of sandboxes and how difficult it is to replicate your production environment without wanting to resort to the relatively easy way of creating a sandbox, getting all the metadata and configuration, and making modifications on top of it.

We will not see a huge shift until we move away from that being the base process in creating and distributing your next environment. That being said, I think the mindset is there.

From my experience, many teams want to make the change. They are probably using Git extensively for their branch management and then figuring out some way of sometimes deploying that to sandboxes when they can. It could also involve creating a data set or bash script and locating that in your version control.

I feel that there is quite a positive dynamic in the Salesforce open-source landscape. Do you share that impression? Did you have touch points with any of those toolings (like DX@Scale) beyond your hands-on work on CumulusCI at Salesforce?

I see the open-source landscape for Salesforce DevOps as being extremely encouraging. Besides the tools themselves, it feels like that group is always growing. Whether it's creating things like the Salesforce DevOps Manifesto, encouraging conversations on LinkedIn, or creating tools like Flxbl (formerly known as "DX@Scale").

I like to read the documentation to get ideas. I think each one has its sweet spot. I'm thinking about some that focus on pooling and others that allow you to bring in custom bash scripts, which is easier versus having it be more prescriptive in terms of these sets of tasks or flows you already have.

There is a lot of value in seeing what each one is doing, and there are ways to use them interchangeably. I have seen a lot of progress with using GitHub Actions as existing scripts, and I have even seen people who've created their own GitHub Actions. GitHub Actions are small actions or steps that could be large. You can incorporate them in your deployment to run something like modifying an environment or creating a Salesforce environment.

Once I started to look for more actions and plugins, I found quite a few out there, some of which are not even non-Salesforce specific. For example, a Slack notification that lets you know a job is done elevates your builds. When you pair it with a tool like CumulusCI, you can find ways to integrate them all together. You can have a pretty powerful setup, and you can get a lot closer to that ideal of having everything automated in a practical way.

Can you tell us about your git-together training activities and also what drives you behind being open to sharing your knowledge and helping others on their journey?

One funny story is about a consultant at the nonprofit where I worked who was supporting me. About four years later, I realized that I'd been working with them for the last year in my next company. It never clicked that it was the same person, but I said, "Wait, you taught me what objects and tables were." It just never clicked until one day when we were working together.

Through seeing how people give their time so readily towards training, I realized I wanted to do the same. My class or course was a one-time thing for now. I might rerun it in the future, but there's something between me and a few other Salesforce friends that I've gained over the years through different meetups.

The focus is on the idea that many of them had Salesforce knowledge but were somewhat new to GitHub or how DevOps tools worked. Meetups are an easy way to onboard people to their first experience with Salesforce DevOps.

I wanted to test it out with friends distributed across a group of companies and see if I could empower them to do a little task at their company and grow that into something bigger.

I will say it's not completely selfless. Like with anything in the industry, it's always nice for those people to think of you down the line and hire you for a contract role. Overall, my request is always that people pass along what they've learned from me to somebody else down the line. If I'm helping you, pass it along. Give them some free information, whether it's the same information or something else, like some skill you're bringing to the table.

Sharing is caring

Thank you for tuning into this episode of Hutte's Trails Podcast.

From resetting revision numbers in sandboxes to specifying Apex classes to run post-refresh, our latest updates aim to streamline your development process. Read on to explore these enhancements and get a glimpse of what Hutte can offer you.

Easily select test classes to run during your deployment

You might have found Salesforce's change set UI frustrating, as it requires you to type class names for tests during deployments. However, with Hutte's deployment functionality, this is no longer an issue. You can conveniently select the test classes to run from a list in your deployment target organization.

Reset revision number of a sandbox feature

The revision number signifies the point from which this feature starts tracking changes. By default, it matches the most recent revision of metadata in the connected organization when the feature was initiated.

There are two scenarios when you might want to change the revision number of your feature:

• Updating it to the latest if you made changes in your sandbox after creating your feature, which you prefer not to track (default).
• Adjusting it to an earlier one if changes were made in your sandbox before you started your feature and want to include them. All revisions of the sandbox are listed with the revision number and revision date.

Specify Apex class to run after sandbox creation or refresh

We've added the ability to select a post-copy sandbox class to run after the creation or refresh process is complete. Typically, we recommend using our Sandbox Pool and refreshing Pool Orgs from your Developer Integration sandbox (often referred to as SIT). Ideally, this should contain all the necessary configuration and data for your fresh development sandboxes.

By Salesforce's design, the chosen class must implement the "System.SandboxPostCopy" interface, which is why we only offer those for selection.

Additional enhancements

• Speed improvements to the sandbox feature and scratch org detail view.
• Fixed bug that occasionally – on the “Take Scratch Org from Pool –” did not select a default Pool Org to take.
• Minor UX improvements to the new “Pull Changes” UI when used on projects with multiple package directories.
• Navigation context remains when visiting “Profile Settings.”

Explore these transformations firsthand

Get in touch with us to discover how we can customize a superior user experience for you!