Description
One of the most time-consuming frustrations you’ll face as a Salesforce admin, developer, or architect are deployments that repeatedly fail. Whether it’s a vague deployment error, missing dependencies, or API version mismatches, the Metadata API can be tricky — as anyone building on Salesforce soon finds out. That’s why at Gearset, we’ve spent the last 5 years building over 50 problem analyzers to find and fix the most common causes of failure, making Salesforce deployments successful the first time — bringing your deployment success rate from 50% to 90%.
In this webinar, Valerio Chang, Customer Support and Technician Team Lead at Gearset, covers:
- The key errors that Salesforce users encounter when they deploy using change sets
- A metadata migration demo
- What problem analyzers are
Learn more:
Transcript
Alright.
Welcome everybody. Good morning, good afternoon, and good evening to you wherever you're joining from. It's a pleasure to be hosting this webinar today.
Today, I'll be talking about fixing common metadata API errors for more successful Salesforce deployments.
My name is Valeria Chang. I'm part of the customer success team here at Gearset.
And I spent my day speaking to people like you who are Salesforce customers from Fortune five hundred companies to small start ups and everybody in between.
And together with my team, we talk to users like you to understand your problems and find ways to help you resolve them every day.
So we also get asked questions on how to adopt Salesforce, DevOps workflows and to manage user releases. So if those are any, if those are any of the topics that you want to ask us about, you're more than welcome to contact us.
Alright. So just to go over what we'll cover in the course of the webinar today.
So today, my plan is to sort of outline the problem that we have, the problem that we're trying to address.
Then I will go into explaining who we are and what Kearsight does. I'll touch on the different areas that Kearsight can help you with in terms of release management.
And one of those areas would be, metadata deployments.
So from there, we will drill into the specific unique selling point of gearset when talking about metadata deployments, and that'll be our problem analyzers.
And I'll show you how the intelligence that gearset brings to your, metadata deployments works.
And I've chosen five examples to show you specifically, to give you a flavor of how they work and execute some live here on the webinar, to give you, idea of of what you can expect.
At the end, I'll also touch on the way that Gearset specifically helps with regards to integrating, your source control, that we, so Git, for example, in your workflow.
And I'll leave some time at the end for questions, and stick around if anybody wants to have a chat.
So if that all sounds okay, here we go. What is the problem that we're trying to talk to talk about today?
And the main thing is that deploying changes from one org to another one in Salesforce is difficult.
It's it's very difficult.
So any of you that have you've been using Chain Sets, Ant, or the SFDX CLI we're likely to have encountered this firsthand.
It's so easy to miss dependencies, to add in deprecated metadata that are no longer, valid in the target, or otherwise just build deployment packages that failed the deployment.
In fact, we know that deployments made via the metadata API using tools like the force dot com migration tools, chainsets, or the DXCLI have a success rate about fifty percent, and we know this because we track this.
When we started using, when we started building Gearset, we used the same tools, as Ant and the DXCLI, to handle our deployments.
And we have the data all the way back from two thousand fourteen, two thousand fifteen when we started working on Gearset to track this deployment success rate.
And every time it failed, the deployment, every time it failed, we would have to iterate and iterate and add in things, remove things, just to get to the place we were where we wanted to, where it succeeded.
And this is problematic because it's repetitive, it's time consuming, and it requires you to become an expert in the intricacies of the dependencies of Salesforce metadata.
And, basically, this is frustrating.
We quickly saw that this is a problem, and we spend our time and effort into making the tool, into making a tool that's better than what's on the market at solving this fundamentally tricky problem, the problem of making Salesforce deployments just work.
So here is the graph that I was talking about, the, deployment success rate. Each point on the graph, it represents a month in the fast pie past five years that Gearset has been around. And we start around here at the very left hand side at about thirty seven percent, which means out of a hundred deployments, seventy, sixty percent of deployments fail.
And we try to improve this, basically. So nowadays, we have been able to consistently help users to reach a successful deployment nine out of ten times when they deploy, and this is the core of what Gearset does.
So how does Gearset treat metadata, and and what does Gearset do?
We like to position ourselves as the modern DevOps tool for Salesforce.
At the core, we help teams compare, move, and track changes between Salesforce environments faster and more easily than ever before.
We're trying to target admins, developers, and release managers to, one, rapidly compare environments to see differences, two, quickly build deployment packages in order to synchronize orgs, and three, to help you reduce the risk of errors, with rollbacks and metadata backups.
And so fundamentally, at the core, we compare your metadata and allow you to, deploy it. But we don't just compare. We we try to understand that metadata. And today, I'm going to show you what we mean by understand.
We will show this by the way that our problem analyzers are presented to you. And these problem analyzers that we're gonna talk about today have, in the past five years, run five point five billion times and help deployment succeed.
So just as a side note, we're gonna talk mainly about metadata today. But not only does Gearset do metadata deployments, we have a whole suite of tools to help with your Salesforce DevOps.
So metadata deployment's been one of the earliest features we, made available, but we can also help you with your in continuous integration, basically, to automate that process of deploying from an org to another, and potentially integrate source control into that. We also help you back up and, track the changes in metadata.
Additionally, we can help with make making data records go from one org to another. So this is sort of in the context of sandbox seeding or if you're migrating CPQ, which a lot of CPQ records are data rather than metadata.
And very recently, last year, we launched the data backup tool. So to allow you to, backup and restore, data records in the case of a disaster recovery. So I'm more than happy to walk through any of these feature with you guys. But today, I'm mainly going to focus on the metadata deployment part.
So to migrate metadata, we do three things. First, we compare, then we build a package, and then we deploy. And I'm going to show you how this works. So I'm gonna switch over to our app here for my presentation.
So our app is accessed via our website. So anybody without installing anything can go to the website, and then we'll log in to the app, and I'll just do a quick demonstration of how, Gearset deals with appointments.
So you can see now that I've logged in, basically, we'll be presented with a choice of a source and target.
So in this case, my source is my dev org, malaria dash lightning, and, my target is the staging org.
So after selecting my source and target, I run a comparison.
And this comparison, not only is it trying to retrieve the metadata from your source and target, and presenting to you as you will see, We also are trying to understand the parent child relationship, any dependencies, and any big components.
For example, custom objects, we split them out into individually deployable parts. So you'll see custom fields separate from list views, separate from validation rules.
Okay. Now we reach the comparison results screen. So that was our first step. Compare the two orgs.
What you're seeing here is a list of changes between the source and target. And if I go through them, you can see between the source and target, between the, right hand side and the left hand side, the exact differences that, your source and target have. So for example, here, I might have a custom field that have a different length, between my source and target. So I very easily know what differences I have.
And if I select those changes that I want to migrate to my target, that's my step two. I select the changes, and then I go and build a deployment package. So here, we're going to get a list of, components that we're going to be deploying to our target. So that in in summary is this three step process of migrating metadata.
And today, we're going to focus on specifically between step two and step three.
This in in this step here, we're gonna introduce the concept of problem analyzers.
And this is what builds the intelligence to help you create the package that you want.
So what's our problem analyzers?
Problem analyzers are built with a single purpose, to make your deployments more likely to succeed.
Each problem analyzer will look for a specific issue, and we'll go through five of these examples and suggest ways to help you fix that issue. So whether it's adding it or removing it, or or making changes to the metadata that you're deploying.
And it's worthwhile noting that this doesn't just apply when you run a comparison manually.
All these problem analyzers apply, when you have continuous integration set up. So every automated job will apply we will apply the same problem analyzers to them.
So let me oh, yeah. Another thing is I often get asked about how GearSat compares us to to its competition on the market and what's the unique selling point.
Well, my number one answer is always our customer focused support. So we do this via web chats. We, get on screen shares with people. But second, I would always point out that Gearset really understands your metadata and applies this intelligence that I don't think, I've seen other tools do.
So let's take a look at problem analyzers. What do they help with? So to date, we have about fifty five different analyzers, all targeting different issues.
And you can see here four major categories that we try to to help with. So whether it's a missing dependency, creating a deployment that's not valid, or detecting for various problems with the API version being different.
Or there might be some quirks, let's say, that Salesforce has in their API, and we try to help address those.
And then we have things that, address specific user references.
So, for example, every org will have specific users and they are unique. So if I has a user if I have a username valerio at gearset dot com in one org, I can't have another username in another org with that.
So we'll see how that's addressed.
So let's take a look at some examples here.
Alright. I'm going to go into back into my comparison that we ran. I'm gonna just hop back to comparison, and, we'll walk through some of these examples.
Let me unselect the ones that we did before. And so we looked at things that are different between the source and target when I did the first kind of walk through. Notice that here we have anything that's new. So things that only exist in the source but not in the target. And these will be the new items usually that you develop in your develop org.
So let's take a look at this example of a discount percentage field. I've I've got a field here, a custom field as part of the account object.
And if I take a look at the formula here, I can see that it's dependent on another field, this field called discount rate. You can see this discount rate as a separate field here.
And remember when I said that Gearset understand this metadata?
If I look and drill into my depends on field for discount percentage, I can quickly see that Gearset, the application, understands that the discount rate is a dependency of, discount percentage.
Now imagine if I select just the discount percentage and deploy and pretend I just forgot to select discount rate.
I'll ignore this step. This step is the problem analyzer telling you what to add or remove.
But if we do that, if I don't listen to gear set and the suggestion that we have there, here we have a deployment summary. I'm going to only deploy my discount percentage.
And if I go ahead and validate, I hope Salesforce here will fail the validation because one of the dependencies is missing.
And you will get this error. Field discount rate does not exist. So without Gearset, you then have to go back into your source work, find out what that means, why it's a dependency, and add that back in.
However, if you were using Gearset, what you would do is you would go back to the results and then trigger the problem analyzer.
The problem analyzer will tell you what's wrong.
So let's take a look here. It says, some items reference components that are into the that aren't in the target. And here, it gives you a solution.
Let's add those components into your compo into your package to help you succeed.
So I add those in.
Now my deployment package will contain the discount rate as well. And if you check here in the deployment summary, we actually explicitly point out to you things that you've selected versus things that are added by the problem analyzer.
So if I go ahead and validate that deployment, it should all go through.
And this is just kind of how Girofit helps you make successful deployments, really, by you just clicking through.
I'm gonna take a look at a second example here.
So if we go back and forget about missing dependencies for a minute, I do know if you have come across a situation where you're trying to change a field and you get an error message, something about their sharing model and the master detail relationship.
So I can demonstrate this now. So here, I have a new fee I have a field that's different between the source and target, the gearset employee object, and the field called happy, which is the, the the one I showed before about the different lengths.
So if I select this and try to deploy it, here has a problem analyzer pointing out that there is a master detail field as part of this object that is missing.
Again, if I do not if I do not fix this suggestion, the error message that you get is this.
So, yeah, I'll just wait for it to show up.
And reading this error message cannot cannot set sharing model to control by parents on a custom object really is just confusing.
This error message is, one that's given to us directly by Salesforce, And it doesn't really tell you what you need to do in order to make this work.
It just says it cannot do this.
It sort of hints at it, like, without a master detailed relationship field.
In contrast, using the clear set problem analyzer, we point out to you that the problem is that due to the way that the API works, we're making changes to an object with a master detail field. We need to include all the other fields.
And there it is, that easy tick box.
You go ahead and we add in by the problem analyzer all the other fields on the object, and your validation should succeed.
Ta da. Cool. So that's sort of working together with the Salesforce API's quirks in order to to kind of overcome that.
The third example I'm going to show you sort of builds on that.
Let's see.
So I've got here I'm gonna untick this example.
So I've got here a record type. My record type is called commute, and I got several pick this values on this record type. So, in fact, I can see that this record type commute depends on the custom field. And with the custom field, I can see that the cycle and train option don't exist in the target.
So if there's familiar if there's familiar if there's a few familiar with the way the metadata works within Salesforce, if we choose to deploy a record type that has values that don't exist in the target, it won't be happy. It will show you errors like this.
So, it will say that the target doesn't have these values, and asks you well, it will fail. And therefore, Gearset here is asking you to remove those values so that your deployment succeeds.
Notice that the previous, problem analyzer is still applied here because Gearset employee is part of the master detail field. So let's let's ignore that one for now because we talked about it in the second example. But here, Gearset is actively helping you create a package. In this case, the package will only contain three valid values to help your deployment work. So in this case, if I select that and accept those suggestions, Gearset will bring in that in the deployment summary.
And, hopefully, we'll just get a deployment that just works so you don't have to worry about all the other dependencies.
For the fourth example, let's take a look at some user references.
So you might have come across this with, workflows or report types or anything that references, Salesforce user.
So here is my workflow.
And I can see in my workflow, I am sending some emails. And the recipient here is different from the target.
But I also know that this recipient only exists in the source.
So if I was to deploy this email address to the target, Salesforce just won't be happy. It'll say this particular user does not exist in the target.
And, normally, what Gearset does is deploy exactly what's in the source to the target.
However, in this case, we've written a problem analyzer to pick up the fact that your user does not exist in the target. So let's see here. The change workflow alerts references a specific user and will fail if the recipient user doesn't exist in the target.
So the solution here that Gearset proposes is let's replace, use the value from the target, and replace it in the package. So the package now instead of your source user will have your target user, and then that package is valid and doesn't fail when you deploy to your target org.
So here, you're deploying just the workflow alert.
We've sort of edited that. So you're only deploying something that's been touched by the problem analyzer, and the validation will succeed.
So, again, normally, GearSat doesn't try to change the metadata of your deployment.
But in this case, it's the only sensible way to to help you deploy that successfully.
So as a final example here, I'm gonna be talking about the situation where, the API changes.
So currently, we're on version forty nine, summer twenty of the API.
However, you might have metadata from other orgs or other source control situations which are of a previous API. And just to show you a problem analyzer that takes into account those changes.
So if you recall back in version forty four, Salesforce has changed the API to change the way flows work.
In fact, let's take a look at the flows here.
I should point out that here I'm on the deleted tab. So deleted stuff is stuff that's not existing in my source, doesn't exist in my target. So I here have a flow that I can yeah. I have a let's say this field that I want to remove, from my target. Gearset can help you do that. So, normally, change sets and other tools can't make destructive changes, but Gearset normally can except for flows where the metadata API does not allow you to. So if I were to select these items for deletion, because of version four because that because we're on a version of the API after forty four, these will fail because, Salesforce has written validation rules in the target to not accept, a, the deletion of, flow definitions.
Therefore, here, Gearset is excluding them for you.
And on the other hand here, we have a flow that's active in the target, and that deployment will also not work. This will only work after you deactivate or make inactive that flow in the target org.
So here, Gearset is triggering these two different problem analyzers, in order to, remove them for your deployment package and to help your deployment be be successful. So all the other things that you've selected in the comparison, to create that package will will work. So in this case, we're only going to be deleting one of the flows that are that is not inactive.
That that is inactive already in the target.
So, yeah, that's sort of five different examples of how oh, I'm sorry. That's an error message. Well, I'll I'll okay.
That's not going to work.
But, hopefully, you can see how Gearset can help you, kind of automate that process and take out things that you don't need and add things that you do need in order to to get your deployment package successful.
So here is a compilation of all the things that we talked about in in in the five examples.
So with Gear Set, you can turn a deployment that would have looked like this with all the errors and not really telling you why these errors exist into something like this where, yep, always happy.
So with the problem analyzers, they automatically prompt you to make a better deployment package.
And just note that this process isn't static. We're actively looking at deployment failures in our logs, to pick out common reasons that our users deployments fail, to create new analyzers to improve the process. So we have around fifty five up to date, but that that will grow. So if you see anything that is failing your deployment and you think Gearset can write some logic to avoid that, we want to know, and we will improve that for you.
And that will also improve the lives of everybody else using Gearset.
Here, I would like to point out that Gearset has a very feedback driven developing strategy. So we heavily listen to what you have to say. And couple that with being able to release to the web app every twice a day, so there are two releases. So we release features all the time. We can really react to what you suggest and really quickly deliver value to your release process.
So up to now, we've been talking about org to org deployments between two different Salesforce org.
What about workflows that include Git?
So Git, as part of your version control, is something we would normally advocate and we will help you adopt.
So a typical flow would be adding version control between your two orgs. So committing your changes from your dev org into Git and then tracking those changes, detecting any merge conflicts, and then doing another deployment from Git to your staging environment.
So the problem analyzers that I talked about actually become even more valuable if you're using Git as part of the process Because suddenly, you have this Git repo in the middle, and this Git repo really doesn't validate anything. It doesn't care what you'd commit to it. It will happily say, okay. I'll take it.
But the problem becomes if you deploy something invalid into your Git repo, you only find out when you deploy that Git branch into your next environment.
So running problem analyzers when committing to Git, from the first part here, means that you catch things like missing dependencies at the time of committing.
And this is the time when it's easiest to fix them. With most other tools, you're left fixing those failed deployments further down the pipeline when you're deploying, for example, into staging or, god forbid, if you're deploying to production.
And imagine finding out a deployment error when you're deploying from Git to production or staging. You then have to go and find out to go back into Git to then find out which commit triggered it added it into your Git repository and what caused the issue.
So having Gears of problem analyzers throughout really helps with that process.
And being able to catch these issues early and fix them is so, so, so important, especially when you have multiple people merging to the same Git repo.
Gearset allows your team to work together, apply the same logic and the same problem analyzers across the deployment pipeline to maintain a code based in your Git repository that is most likely to be valid at the point when you deploy at every stage of your workflow.
So now that you know that, yes, the problem analyzers apply org to git, git to org, there's another additional clever bit of logic that gives it applies when you're deploying to git. And here's another concept that I'm going to introduce here, which is the re repository dependency cleaner.
So the Gearsight repository cleaner basically deletes from your Git repository any missing dependencies.
Because if you had a missing dependency in your Git repo, that can then not that cannot then be successfully deployed to the next Salesforce org.
So let's take a look at an example of what this looks like. Imagine here you have a board, and you have an object and some associated profile permissions with that object. So you have the object permission, and you're committing this information into your git branch.
So now you have a starting point, a git branch that resembles your org. Now imagine if you were to delete this object in your org.
As you might know, when you do this in your Salesforce org, it would just automatically deploy delete, the object permissions and the dependencies for you.
So at this point, Git hasn't deleted anything, but you've only deleted the object in your org. And if you push that change into your Git branch, you've deleted the object, but, hey, your project permission is your object permission is still in the Git branch.
And now you have a floating object permission that doesn't reference anything. And just imagine what happens when you deploy that to the next environment. The target org will just say, hey. This doesn't work. I've got a permission with no object.
However, the repo dependency cleaner takes care of that for you. Anytime you, execute a destructive change, we scan your git repository when it's a target, and we remove any floating or missing dependency.
So this doesn't just apply to object permission. This is, like, layout permissions, Apex class access.
So we're adding to that process when you're, integrating Git within your workflow to help you keep a Git repository that is valid.
So wrapping stuff up here, we sort of walked through what the problem is, I e, deploying in Salesforce is difficult.
We sort of went through a little demo of how Gearset works to help you solve that. We introduced the problem analyzers.
We showed you five examples, and then we talked about some, additional, special things we do with, the dependency cleaner.
Now some of this stuff you could script and write on your own. It's it it's you can create a solution without GearSet. And no problem analyzer that I've shown to you here on it in its own right is impossible to replicate.
Although I know some of them took us quite a long time to get right.
But if you were to maintain that, if you were to do this yourself, you need to maintain a body of code just to keep your deployments working. And remember to keep applying those logic to your continuous integration jobs.
So, yeah, we're not just talking about deployments. We're talking about your whole CI pipeline.
And this is why I think, fundamentally, if you're deploying metadata, the solution is to have data set in it.
We built up five years' worth of cumulative knowledge and experience with fixing deployments, which is why we have the fifty five plus problem analyzers currently, and they're working automatically to fix your to fix deployments.
And remember, we're adding to that all the time based on the errors we log and your product feedback.
So in summary, the takeaway for you today is this. In the past in the past in the past five years, Gearset has been able to fix five point five billion problems before they hit the target.
And this is across three million deployments, manual and automated.
So I invite you to see for yourself to see the deployments happening in real time.
We've just built a website called Gearset dot dot sorry. Trust dot Gearset dot com.
And it looks like this, which shows you, live deployments as they are happening.
And who knows? Maybe you'll be interested to give it a go and try the problem analyzers out for yourself.
Yeah. That sort of concludes my talk.
And, yeah, I'll hand back to Alice.
