In this video, Texei’s CTO, Fabien Taillon, goes over all the tips and tricks he can share after working with Salesforce DX for more than two years. Whether you’re new to Salesforce or practically a Salesforce expert who just wants to learn a few little-known workarounds, this video will help you out.
When you watch, you’ll get good ideas on what to do with Profiles, how to deploy metadata that has usernames, how to handle certain push errors, and much more. You’ll learn how and when to clean up metadata you haven’t used in a while, and how to handle permission sets to get the best results. And if you’ve ever struggled with issues involving labels, API names, and other common problems that come up with scratch orgs when using Salesforce DX, you’ll appreciate these tips from Taillon.
Experienced Salesforce developers and new Salesforce users alike can learn a lot from this half-hour video on some common issues Taillon has discovered and solved. Even if the issue you’re having isn’t described here, you’ll get some advice on finding community support to solve your Salesforce DX problems, making this video great to watch when you’re waiting for your support request to be resolved by Salesforce.
[00:00:15] Hello, and welcome to another Xforce Data Summit presentation. Today we have Fabien Taillon, who's a Salesforce MVP, and the CTO of Texei, which is a Salesforce consultancy in France. He's going to talk about Salesforce DX. And this presentation is more tips and tricks about his learning from actually using it.
[00:00:40] and I'm very excited to watch it because I think Salesforce DX is a great, new advance in Salesforce, or relatively new. So here's Fabien. Hi everyone, and thank you for being there. So, as you said I'll be showing what I've learned with Salesforce DX during this two or three years using it. So let's let jump into it.
[00:01:04] So just quickly, to introduce myself. So as you said, my name is Fabien Taillon. I'm a Salesforce MVP for I think five years now, and I'm the CTO at Texei. I’ve been running the developer group for maybe five or six years now. And I'm also part of the French Touch Dreamin event. And you can follow me on Twitter with this quite easy to remember Twitter handle.
[00:01:30] So let's quickly review the agenda of experimentation. So it will be mainly two parts. So the first part is around general tips. So like, how you should start and what you should do and shouldn't do. And then the second part is more looking at specific issues like this specific metadata isn't working out.
[00:01:53] Could you work with it with the XL? For instance, the topic on profiles, because it's a big topic with Salesforce DX.
[00:02:05] So I wanted to start with this [00:02:07] nice quotation from a big philosopher, Yoda, which says “Do or do not, there is no try.” So it's a nice quotation for a movie, but I would say, unfortunately for Salesforce DX, it may not be the best thing to do. So really, What I would say is you don't need to overthink too much, and you really need to try it.
[00:02:33] So why do I say that? It’s when you try to look at Salesforce DX and look at the documentation, what you may find is mostly, basic examples. So yeah, you would assist for an hour to create a Scratch Org and push and pull metadata. Only documentation, basic stuff on what's working actually, so you won't have information about how to create this Scratch Org with all the metadata from the production environment or stuff like that.
[00:03:01] So documentation is pretty basic. And then on the other side, we also have lots of, CRAs mostly [00:03:11] driven by the community. So including some I've written myself, that will tell you what the theory and what you should do, work on DX. And from time to time, this kind of stuff may be quite complicated.
[00:03:28] So like how you should decompose your org in several packages. We factor a lot of stuff to make it work, and it may be a little bit frightening before, if you need to start and think about all of this kind of stuff, so just, it could be a goal to achieve at the very end of your move to DX. But, it shouldn't be a show stopper.
[00:03:49] So here's the thing, something you need to remember is when you move to DX, you may think that I want to go to this step and do everything with DX and everything should be perfect and automated and everything, which is a goal of course, but remember where you are now. So, for instance, profile may be an issue, but you have [00:04:14] lots of customers. When I ask them to say, but even now, we are not debriefing profiles. We are checking changes manually in production, which isn't good. But this means that it shouldn't be a showstopper if DX doesn't under profile as a very first iteration because the customer isn't ready to bring profiles today.
[00:04:35] So don't aim at something that’s a hundred percent perfect from the beginning but look at where you are now. Because you may be using chain set too with lots of metadata missing. You may have lots of manual steps to do already. One other question I have I am creating this crusher, but I don't have any data to play with it.
[00:04:53] Okay, but do you have any data in your developer sandbox? No, I don't have data in the developer sandbox, so actually it's the same issues, but when you talk about moving to DX, you may expect for every single working from step one. Which may not be the case, and it shouldn't be a showstopper, because it already knows the case from what you are using today.
[00:05:16] [00:05:16] So. Really, this is my first advice, which is don't overthink. Try stuff and really start more on iterate. You don't need to have 100% perfect stuff from the beginning. Start with something, start with small Scratch Org, maybe add everything in the repo or whatever. But don't aim for your 100% perfect goal from the very beginning.
[00:05:41] So, another advice would be that you shouldn't put everything in your repo. I've been working with a customer that created a quite impressive Scratch Org. It's almost like a sandbox. So, so you have 100% the same metadata as in a Zen projection which may be cool, but it takes a lot of time to create.
[00:06:07] Plus, they also have all the start layouts on everything that they don't even use. So it doesn't really make sense to have everything in a, [00:06:15] in this Scratch Org. So he's, he's a repo that I've always taught all subjects, even though they are using maybe 10 okay. So that sounds pretty makes sense. For us, if you have maybe, I don't know, 20 objections in your production environment, that doesn't mean you need to install them in your Scratch Org.
[00:06:31] You need to only install the one that you will really need in the Scratch Org. And that's it. Because you may have some, some action that will add to clean or export stuff from your production org and that doesn't make sense in the Scratch Org, which will be a development environment. So the next point is that this is a good opportunity to clean what you don't need anymore.
[00:06:52] Because when you start to create a Scratch Org, you will, for instance, talking about AppExchange, you will see maybe 10 of them that you don't need anymore, and you can just remove from production actually. So just go ahead and remove them. Also, from time to time, you will just see some objects and see that there is no connection with anything.
[00:07:13] So you go to production, you look at how many records that are in the table, it’s just empty actually. And when you start digging deeper and you just see that it was a test from, I don’t know, five years ago and it was never directed. So this is a good opportunity to see what is still in production.
[00:07:36] But shouldn't be in this Scratch Org, and moreover should be cleaned from production. Some of the stuff I've seen is like a failing Process Builder. So, you know, when you create a Scratch Org for the first time, you will take all the metadata from their production, try to push on the Scratch Org. Except if you're a very, very, very low key, you will have lots of errors because we will be missing some features that are not activated.
[00:08:01] You forgot to, include one metadata or whatever. Lots of reasons for this. And from time to time you will get some metadata. Even if everything is perfect, won’t deploy, you will get an error and you try to understand why. And then you go to production, you open the, [00:08:19] for instance, Process Builder and you click edit and save on each one, and save again.
[00:08:24] So you have already sometimes in production metadata that is not valid anymore. And what does it mean? It means that first you can remove it from your Scratch Org or maybe fix it in production, but most likely it's something that was never used and never came. So it's a good opportunity to, to clean this kind of metadata, both from your repo and from your production environment.
[00:08:47] And then, the thing to remember is that this Scratch Org, it's not a holy copy of production. It's a development environment. So you don't need to put everything inside the Scratch Org. So for instance, if you think about your list views, your reports, it could be in the Scratch Org or maybe not. You may think about, who is the owner of this kind of metadata?
[00:09:10] If someone needs to change the report or list view, should it be an admin that will change it in production? Because it's fast and there is no need to ask for, or is it something that the dev team will end [00:09:22] up. If the dev team is only in this kind of sense, it is a repo. Otherwise, it should be only in production.
[00:09:30] So what I usually do is they mainly tech leads you or reports. Except you are referencing the metadata, like fixing page or stuff like that. But otherwise, we don't use it. I don't put these reports on these use or repository in the Scratch Org because I don't want someone from the business to come to see me and say, Hey, change.
[00:09:53] one thing in the repo. They should be able to change it directly in production. So you really need to think about what should be in the repo and what should not be in the repo depending on who is the owner of this kind of metadata.
[00:10:09] And then the last thing which we'll talk about just after is you should only add what you are about to, what you are able to update and deploy from the Scratch Org. For instance, one of the issues [00:10:23] with metadata lets me to deploy with Scratch Org. So I'm just switching to the specific issues with DX.
[00:10:33] Is that some metadata are referencing some usernames, and when you create a Scratch Org, they’re really one user. You generate a user from the Scratch Org and you don't have any new user existing in your production environment. So if you want to show metadata is referencing one user, you wouldn't be able to deploy it because it will just throw an error.
[00:10:57] saying that the user isn't presenting here. So, there are a few things you can do about this. So, first is refactoring because it doesn't work for all the metadata, but for some of them you can replace or out code the username by either a Queue or a Public Group, which makes sense actually because.
[00:11:24] You will have a reference to a Queue or Public Group that will be emptying your Scratch Org, [00:11:29] and this is part of your package and your project. But then it's up to the admin and production to select a well, part of this group who should receive an email with your program or whatever, and it shouldn't be linked to a, to a version of your application because it's just.
[00:11:48] Switching one user with another one or whatever. So I think it makes sense to remove every time it's possible, the username with the Queue or Public Group, it could be the group that will be undone by an admin in production. But unfortunately, there are some stuff that doesn't work yet.
[00:12:07] Maybe because, the same with DX, but release after release it's improving. There are a few things like when you try to update, an owner of the regard. This specific one doesn't allow you to set up Queue as an owner. You want avenues or opportunities and aren't getting a username in this specific array.
[00:12:29] It could be a Process Builder or a [00:12:31] field of data work for a bit. So. Here you have two options. it's either you can trip something like saying, Hey, when I deploy this metadata to the Scratch Org, I can on the fly replace some stuff from this metadata with the username from the Scratch Org.
[00:12:50] But. Does it really make sense actually, because it's a development environment. Even if it's deployed, but you can't change it, is there is a user story that say you should replace this guy by this guy, and you can't anyway do a Scratch Org that makes sense to everything. So Scratch Org, maybe not.
[00:13:07] So you should have lots of dependencies on this specific action. Of course, I didn't try to script something to replace users on the fly. Oh, so why is he just one small field of data that you don't really need that you will, you will have to either make that metadata manually or do it manually in production.
[00:13:25] It doesn't make sense to do the repo on the Scratch Org. So, it's up to you. Is that some, some stuff's coming. [00:13:31] From Salesforce to try to, undo this kind of use case. But, I think it's supposed to start in summer but I don't think it will be there before one year or so. Again, it's stuff that’s coming, and for now, you should just under this way, either replace it or just don't put it in the report.
[00:13:51] So one very good thing with DX is that as everything is in your repo, it's not the org anymore that is the reference. The source of truth is the report. You can script whatever you want actually. So this see the issue. You can create some code to script it and try to replace it on the fly during your deployment process.
[00:14:16] For instance. What I would recommend actually is to, don't script it with, I don't know where, shell or whatever I show using as a DevOps or stuff like that. Create the customer subjects again. So if you are using same DX, you already know, Salesforce, off your shoulder [00:14:35] tool, and you can create your unplugging on the same architecture and you can install your plugin in the SFDX into Salesforce or CLA tool directly.
[00:14:49] there are several advantages with that, which is you can use it for several projects. And also it gives you lots, lots of stuff already out of the box. So if we see an official Salesforce tool, you've, you've connected to, I don't know, 10 arms for instance. Well, Oh, disconnections, already done and given to your plugin. You don't have to undo connections anymore.
[00:15:16] This is part of the framework, given by the CLA from Salesforce and you will have access to your connection, and you can just with one line, do a query. So create a query to your org, you have some, like I don’t know, a spinner or whatever. So, Hmm. Don't [00:15:37] go for a specific script in whatever shell or a proper shell or whatever, just do a customer subjects plugin.
[00:15:46] I think it's a, as a way to go for this kind of script. So next, next one is profiles. So profile is still a little bit tricky, so it's not a 100% solution, but let's see what we did. So how does it work first? If you look at the metadata, API documentation profiles are designed to retrieve and deploy access rights from components in the same package.
[00:16:17] So if I retrieve a profile with one field, I will get a field of a security for this specific field. If I retrieve it again with two as a field, the first field will be removed from the XML as it was the one that I've just retrieved. Will be in the XML file, which doesn't work very well with DX push and pull, where I [00:16:39] just partial retrieve each time.
[00:16:42] So it's not easy to have a 100% complete profile with all the access rights you want. When you look at the documentation blog post from Salesforce, what you see is as they recommend to move to permission set, and if you knew our permission set and profiles are working, you will be, you may be like really, because, because that doesn't really work for all use cases.
[00:17:08] So why? Because, so permission set is cool because if I wrote you a profile, if you gave me the access rights from also metadata and retrieving at the same time with permission set, it will give me the permission set all the time, so no issues about stuff missing or I'm sure of what I will get into this permission set. Not everything is in the permission set.
[00:17:33] And the main thing missing is Page Layout assignments. So you should deploy on the permission sets, you [00:17:39] won't deploy all the Page Layout assignment from your Scratch Org to your production org and so some stuff, like as a default application or default regard type for an object.
[00:17:51] And actually this makes sense because you have only one profile. So you can say this is a default application, but if you have 10 permission set where each permission set says, Hey, this is a default application. There is no default application anymore, so it will never be in the permission protection.
[00:18:11] So you have to find it as a way to own this kind of stuff. So what we did is, so first we are moving everything we can to a permission set. So it's already a lot of things, User permission, Fields permission, Object permission, etc. Classes permission, I got the link to a very good, blockbuster from Salesforce developed blog posts developer.
[00:18:34] That lists all the metadata. Oh, well, all the tags, it's the profile metadata and it will tell you if it's possible to [00:18:00] move it to a permission set on the, so you can see what was of my previous slide, which is a few stuff, like a layout assignment, that I'm not available permission set. So first, if this helps you to move everything you can to permission set to where you'll be, you will be sure you will never have any user issues with that kind of thing.
[00:19:03] But then what about the remaining, like Page Layout assignment? So we created the customer subjects plugin. Which is in our Texei custom plugin, which is you can use it for free. And so how does it work? So be sure that when you use it, you are not expecting to retrieve a full profile.
[00:19:28] So is the idea is you move everything you can to a permission set, but then I still need to retrieve all the other stuff, but there is no way with the metadata API to get the full profile. Except if I retrieve everything that I need at the same time. So what the company is doing is reading your [00:19:45] local report and looking for all profiles, record types, apps on layouts.
[00:19:51] You will find in your report. Behind the scenes, we can create a package of XML and retrieve everything, and that's the only saving your local files. As a profile you requested. And the access rights that are profile-specific, which are
[00:20:07] That could be bringing in the profile that you don't want because it's part of the permission set. It will be removed. So with this command, you are sure that you will get the profile you want. So it's not 100% perfect because that means that at the end of your work before committing everything, you need to think about running this command manual user where you may miss some stuff.
[00:20:37] and there are some things also that, so when you create a profile from scratch the first time, some permission and not part of the metadata, we just send them to true by [00:20:49] default. So you may have a little difference in kind of, with this command. It's open-source, so I was thinking of maybe adding some stuff to force anyway to be sure that on the checks in production it's, it's, it's open-source so you can try to use it and try to do some pull, a pull request if you think you have a, with a way to improve it.
[00:21:15] So these, we tried it on a, I think, two projects for now, and it was working. Again, not 100% perfect, but, it's still better than the other solution from Salesforce, which is not too perfect. So just one last topic on a very specific issue with, with Salesforce is, so.
[00:21:42] I find using pre or post push to avoid some Salesforce, the books. So there are some strange stuff from time to time, don't really know why or when to be honest. [00:21:57] When I deploy everything in one shot, I will get an error saying that there is no RecordTypeID field.
[00:22:06] because I think that in the same deployment, I don't know, I would just get deployed, behind the scene, but, maybe it's the RecordTypeID field for new objectives and created before some of the metadata consider whatever. So from time to time, I'm just doing a prep push would be for my world push of all my metadata.
[00:22:26] Just create a RecordTypeID and then they can push everything else. So in that system, but that will have a specific stand out that you said? So for instance, so, working with these, some orgs that are in French. And so when I go to production, if I go to a standard that you set, let's say opportunity status, so I will have a label.
[00:22:50] so Gagne means one. So you will have two things: the label and the API name. So in my production, use a label and API name as the same [00:22:59]. So it's Gagne and Gagne. But the thing is that when I create a Scratch Org, when I ask a Scratch Org to be created in French, that's not the way it gets created.
[00:23:10] It's created with Gagne as a label, but still Won as the API name. And that doesn't work well with deployment because if I deploy a Gagne on Gagne, which is the metadata for my production environment, to the Scratch Org, it won't replace the existing values in the Scratch Org. It will say there is already.
[00:23:34] Value, which is, which has the label Gagne, but the different API names. So I can't have two values with the same label, so do something with it and just as scratched. So I think it's more like the API, but still it doesn't work. So what you can do, what I'm doing, I don't say it's the best solution, but it's working.
[00:23:54] I'm doing a pre-push, like I did for the RecordTypeID. And I'm just deploying, so this is, for instance, opportunities [00:24:03] status, a dummy value. So what did we do? We will deploy this value in the Scratch Org. So Gagne one will be just a, the activity and is the value in the Scratch Org will be made, any value.
[00:24:16] And then I will be able to deploy my real metadata in some Scratch Org. So just see this kind of trick is not perfect, but it's working. It enables you to create a Scratch Org, and I've just, yet, as DX is getting better and better release after release. This is the kind of thing that I will just remove, as soon as I get the, as it gets fixed.
[00:24:38] So, one last slide, which is you should really go to the community. So if you’re interested in links I made, so you can see all metadata from Salesforce and you can see what is supported in the API. You know, look back in the source tracking if there is known issues or not, sort of useful. And you can filter per API version.
[00:25:05] [00:25:05] Next is CLI issues. And it’s a real specific report from the CLI. Where there is no cord inside. But if you see an issue on an CLI command from Salesforce, you can go there and create an issue on this specific report from Salesforce and they are looking at it and trying to fix it. Will open source at CLI at some point.
[00:25:31] But in the meantime, it's a good opportunity to be back to a Salesforce team, without going to, creating the case or the time. Well, the good thing is to, to do both, actually. Create a case and, go to the issue. And then there is a Trailblazer community where there was a group where you can ask your question because there are already lots of people like me and some others that may answer you. Also, wise people from Salesforce are looking at it and can help you maybe resolve your issues.
[00:26:03] So just a small recap of what we've seen here. First thing is don't overthink. Start doing stuff, even if [00:26:10] it's not perfect. If you aim at 100% you will never, never do it. Don't put everything in your repo. Look at what you really need on what may be clean from the production org. You need to script what you need because, that's a good opportunity to avoid some manual steps. You may have a today in your creation or deployment and then go to the community to ask a question and also share your workarounds if you find some issues. And that's it. Thank you. Okay. I have a couple questions on that duplicate label, just to get an idea of how responsive Salesforce is, the duplicate label thing, you showed the and then one that looks like just a bug, right?
[00:27:02] Yes. Have they acknowledged that as a bug and given a timeframe that it's going to be fixed or? No. So I think I created a case for almost every issue I found, and I never really got any timeframe or anything for this kind of stuff. So I don't know how far to the end of the scene. For instance, the standard value sets, which are a standout says for.
[00:27:27] They didn't get rid of the fluff recently. So there are still some startups that don't have any API. So you just, I think that like for instance, contract status, if you have some customers that use it. There is no API for the field. So you just need to either do it manually or create a script with a tier or selling you on whatever kind of tool you can create is better than nothing.
[00:27:56] But I guess they should fix this kind of stuff, but they also need to first complete the missing API spot, this kind of metadata. So maybe we'll get there, but I didn't get any answer for when. How about the, have you reported any command [00:28:14] line CLI bugs have, have you found, you know, to their GitHub?
[00:28:19] Do you find that they're fixing that more quickly? So, yeah, exactly. I think that's, they are more responsive on the CLI GitHub repo. I don't know if it's because from the stuff I'm going to support, and maybe it's slower to get to the engineering team. Whereas, when you were to get the answering quite fast, that doesn't mean that they will fix it, immediately, because from time to time, it just, depending on as a team, if it's on Salesforce service side, they just need to wait for another team to fix it and be deployed in the next release or tool.
[00:29:00] So it could be slow anyway. But, you will get some answers actually. So maybe they will just tell you that. So you will need to wait for a three months, but at least we get the service. So it's definitely a good place to work. And so there already used, one part of the CLA that is open source.
[00:29:18] So not everything but one small part [00:29:20] and you can just, I, I think I fixed one issue or mostly for fun too, to play with it. And I was able to do a pull request and fix the issue myself. So when you get support with CLI, that doesn't mean that you have to, fix it yourself. But if you need to lose five hours to create a case on new coal with the support and everything from time to time for a small bug, it would be easier to just fix it yourself with a support request.
[00:29:51] Right. Right. Great. Well, thanks so much for, the presentation. I wanted to let everybody know, anybody who's watched this presentation and haven't watched the presentation that was given by Bash in, Bash is a, is a developer or an administrator, and he gives an overview of Salesforce DX. So those two, presentations complement each other.
[00:30:15] So thanks again, Fabien, for a great presentation, great real-world knowledge about Salesforce DX. Thank you for having me.