Salesforce DX for Awesome Admins

Welcome to another X Force Data Summit presentation. Today we have Bash Dinh, who's managing director at ZoomZoom, which is a Salesforce app exchange partner, a system integrator, they make ZoomZoom financials on Salesforce.

He's gonna talk about something that's really important to anybody who's ever been a Salesforce administrator, Salesforce DX, how to migrate things from your sandbox to production. Here's Bash.

Great stuff, thank you very much, Lenit.

Well, welcome everybody. Thanks for joining and tuning in and taking your time to have a look at this presentation. So two parts to it, there's going to be a few slides just to introduce the concept of what Salesforce developer experience means to awesome admins. So I consider myself an administrator, I'm definitely a clicker, not a coder.

So when I first looked at Salesforce, developer experience a little bit daunting to think, I'm not great at coding, I realized I wasn't great at coding, left that thirty years ago, love Salesforce because it's all about point and click. But some of the benefits of this are super appealing, even as an admin. So I thought, you know, let's start experimenting, what does it mean? And then once you grasp the tools and start to use them, you realize even as an admin with point and click functionality, you can take advantage of the benefits that Salesforce developer experience brings.

And I said, what does it mean to me as a Salesforce administrator?

I've got a really broad set of functionality that I need to know about in Salesforce and I can sort categorize it. As Salesforce do here in four main categories, and you know, that first thing about, you know, in simple task of adding users, removing users, you know, the user interface, what do the screens look like?

What information do we display to those users? Which means I'm getting down to things like managing profiles and permissions.

And we'll talk about how to migrate that from, you know, when you're in your dev org, your development org or your sandbox and actually moving it to live. And clearly, you know, when I go to my data management and if I'm adding new tables, new fields, I've always got to consider who should be able to see that field or edit that field. Are there any validation rules we're to put around that to control data quality?

And again, all of this I can do as an administrator or a point and click functionality, but also I've got two balls to juggle moving from my build environment to either test or live, whether it's a simple field that will add on an existing Salesforce objects or our own custom objects, you know, even customizing those fields, the ripple effect that has on the system, just the amount of elements that I need to move from a sandbox to live starts to build up quite quickly. And you know, I'm keeping a manual list, or trying to do that from some other kind of tool that helped me to move change sets around.

So that when I do deploy it, then I respect the organization security model. We're always aware of privacy and security and as a Salesforce administrator, we've got our production org set up. So when I create a new field, I can get granular down. As we know, field level security, and quite often I'm deploying change sets and the things that are left behind are things like profiles and permissions and security because the granular detail I forgot.

I hand it to a bunch of users and realize I have to do yet another change set to keep moving components over because it lives in so many different places within Salesforce. So at the end of the day, you know, in terms of getting that information to the people that need it, reports and dashboards, making sure that the visibility and anything that I build, whether it's reports or dashboards, I can move and we can iterate and keep developing and moving those forward. Across the board, Salesforce DX is going to help administrators as well as developers. So, you know, whether I'm a solo admin, we always have that accidental admin, whether you're the CEO, the business user that bought Salesforce, adopted it, because it's so easy and simple to change, change page layouts, add fields, customize, that you can do that very quickly.

And you soon start to learn how to do this. And as the organization grows, the Salesforce environment grows. And whether you take on developers full time on your staff or have partners come in to help you and build functionality for you that you can't do through point and click, you know, maybe through code or special pages or lightning web components, you may either all be working in the same org, and that's been the bottleneck and the huge trouble that we've all experienced, especially when something changes by one admin that actually breaks test coverage or a function that a developer is working on, or you can't move changes from the sandbox to the live system because it's tied in and dependent upon other changes that you can't afford to actually move yet.

So it slows you down. You might end up then creating multiple sandbox orgs. The challenge of trying to keep everybody working on the same, you know, version, that concept of what's the latest version in Salesforce has been, you know, an obscure concept, you know, where is the version of our truth?

Which sandbox does it exist in? Or in fact, if I'm an accidental admin and I think we've all been guilty of this or a case has been reported or a request has made, I've gone ahead and made the change in production.

So actually I'm of the opinion that the production system is the right version of the truth and everything else is out of sync. But you know, when you're deploying change sets, the complexities and the issues that are caused by that, you know, slows the organization down. So whether you're working individually, even individually, that whole concept of what did I change, when did I change it, and how do I move that from, you know, my developer environment, my sandbox to production in a smooth manner and get it right first time so everybody's happy. I don't have to go and do rework, but I can continue to develop more functionality.

Now Salesforce addressed many of these requests from the customers predominantly, you know, the developer community.

Any developer outside of Salesforce, you talk about the concept of what's your version control system, where's your source code, what's the source code control system, check-in, check out, you know, basic functionality that I think we've all been pining for in the Salesforce environment, even as an administrator. You know, if I have a page layout or a database table, I'd like to know what the current version is and what the changes have been made and by who.

I'll be able to roll back and roll forward as well and move that to a live system. So the idea of moving away from being tied into an org and being able to have our source code and even considering database tables and page layouts or validation rules, workflow rules, is that's our source code and that's where it lives. And every time we make a change, we can track that and roll back as we need to.

Keep everybody up to date at the same time. So all built around collaboration, knowing that the world that we live in now, it's probably Salesforce increased the number of sandboxes everybody can have. So we can all have multiple sandboxes. Yet they've introduced the new concept of scratch orgs.

And we're going to talk about that, which means that we've all benefited from an additional forty developer orgs in Salesforce. So as an administrator, that's interesting for me. As long as you're on enterprise and above, that means we've got a new type of org that we should be taking advantage of, that's going to help us to continuously deliver new functionality. And whether you're an AppExchange partner developing packages, or using packages internally, or indeed, the internal Salesforce admin or Salesforce team that's pushing out new features and functions to the organization.

We want to do that quickly and smoothly in a constant pipeline and be able to increase our velocity of getting those features out. And then the openness of the platform that Salesforce, although we're going to talk about Visual Studio Code is the standard tool that Salesforce are showing on Trailhead and all the demos and all the videos and the one to adopt, you know, copy and paste. It's like a mobile phone, every developer is going to have their own preference. There's a number of tools that supported on the actual desktop.

As an admin, obviously, went through Trailhead and said, what are the you know, what are the most important things that I need to know and learn about?

And so Salesforce DX is not one feature. It's not a function. It's not even a tool. It's a whole overarching methodology on Salesforce. It's an umbrella term that says we're going to move from being tied to developing and building in orgs to move into a source code control system.

So in every production org that's enterprise and above, Salesforce have enabled a developer hub, which we're going to use the term Dev Hub. That's our core hub. It's your production system. And this is used to control the number of scratch orgs that you can actually create on a daily basis, a number of scratch orgs you can have active.

You can do this in Trailhead and you can do it in developer orgs, you know, test environments. The reality is we've got this in our own environment. So everybody with enterprise and above means we can create up to eighty scratch orgs a day, that means add and delete, super fast.

And we can always have up to forty scratch orgs going at any one time. They're limited in life, which means that they default to like seven days.

And if you don't do anything, they will expire at the end of the life. So they're meant to be for a very short life. The maximum you can set it is for thirty days and after thirty days, the org will be automatically deleted by Salesforce. So it's self cleansing.

It develops a really good habit. Create a scratch org. It's either a replica of your sandbox or your live system or a brand new blank template. If I want to experiment with a new feature or create a new module for our business, you know, I might just want a blank canvas, a standard Salesforce org that I can actually build in, or maybe I'm going take a replica of our sandbox so you can have templates as well that you can actually use.

But we're going to start with very vanilla at the moment. When you follow the help articles and Trailhead, you'll end up with just a vanilla sandbox. It doesn't necessarily represent your sandbox org or live org, which means there's still a place for sandboxes and live orgs. They're not going away.

This is not replacing it. This is adding to what you've actually got. So if these orgs disappear after a limited amount of time, the source code control system is going to be super important.

And, you know, the command line, the Salesforce command line interface, CLI, you know, it's obviously very appealing for developers that are comfortable in working in this world.

I looked at that and I thought I could copy and paste those terms. So I look at the manual, how to create a scratch org, the instructions there, you copy and paste to your command line. And actually when you work through some of the learning material on Trailhead, as an admin, you can follow the concepts, can start build, modify and delete your scratch orgs without being a coder.

But then obviously the Visual Studio Code, the developer tool, it's a nice graphical interface on your desktop, Windows or Mac. I looked at that and I realized that many of these commands that I have to type in or copy and paste at the command line, can actually do with keystrokes in Visual Studio Code.

Certainly eighty percent of the ones that I want to do as an administrator who loves point and click, I could take that methodology to the tools here and work out a pattern to make sure I can use that in a point and click environment. So Salesforce has developed a bunch of plugins and will continue to develop plugins for Visual Studio Code.

Versus Code as I might refer to it during the demo or the presentation, we're going to see that very popular IDE Salesforce will retire their own developer tool and said move over. And this is the one to go for. But by the way, choose your own. The command line interface will work with many tools. And when we look at the source code control system, again, choose your own version control system.

We're going to use Git and GitHub because it's super popular. It's also the one that's in the learning material as well. But again, Salesforce said you're free to choose. You might have one already.

So some people might have had to build this themselves and compensate for the fact that Salesforce didn't do this. Or if you're starting from scratch, you know, go and buy one that's suitable for your business. We're going to show Git and GitHub, And that's what you're going to see in the learning material as well. So the new way of working is that we're going to have up to forty scratch orgs that we could have.

I could have multiple scratch orgs myself or a number of people working on their own independent features.

And at some stage they'll need to be checked in and merged together in the version control system. So we'll be able to have the tracking and visibility in a very granular level about what's changed and who made that change, whether we need to roll it back, or if we're happy to merge it in, which, you know, a popular practice, this is to have a master branch and then to have a developer branch and then other branches as well. So even the branches are disposable. So if I experiment on a feature and it doesn't pass the requirements of the business, they don't want it, I can delete that branch and I've not affected the core code or the master code. This is very different from a sandbox. When I add a function to a sandbox to show a concept.

So let's say I get a request from the business to create a purchase order system. And I go to the sandbox and I show them that and they say, Nah, that doesn't do what we want. It's all right, thanks. No, thanks. I'm now left to unpick everything that I want from a sandbox.

And of course, in this concept of having an independent branch where you can build modules or experiment, if the experiment works, merge it into the master code. If it does not, delete, forget, I didn't bother anybody else or trip them up or put code in there that, you know, I'm saying functions, database table, we're going to create a purchase order module. I don't want that to leak out into the application when it's actually not been adopted. So even branches like scratch orgs are disposable, you can create and dispose of them as you want.

So even if you just took that concept of taking your production code, moving it to your source code control system, and then being able to pull a copy of that in an independent branch, develop some ideas and either check that in or dispose of it. And if you check it in and you like it, merging that into your master system, being able to deploy that to your sandboxes and production org, you know. So of course there's still a place for sandboxes, for, you know, large amounts of volume, user acceptance testing, integration testing, how's it really going to work? So, you know, it might well be that scratch org is just vanilla, we add the module, and then later on we see how it really behaves in user acceptance testing.

And again, once we're happy, or we can iron out bugs, even there we can be fixing and changing from the source code to sandboxes. So Salesforce will work with all this environment, including pushing it to your production system.

The entry level for an administrator is to work through these on a manual step by step basis, but the vision will be that much of this will become automated and using things like packages.

So already Salesforce are asking us to start thinking about our org in a more modular approach. You know, we have the base package, everything that's included in Salesforce. We've customized certain elements of that, you know, if we created new fields on the account screen, we have a account module. If we developed a sales invoice or a purchase invoice, you know, we have purchase invoice module. And now we can break those down into separate containers called packages.

So we'll start to deploy and handle and manage versions of packages. So that's quite a journey to move from having a dev org or a sandbox, making a change and moving a change set to life because that's what we're doing as admins right now.

And Salesforce have mapped that journey out for us, you know? So we're right here at the beginning, understanding that I'm building apps as an administrator to respond to the business. I'm finding spreadsheets or homegrown apps, might have been on desktop, internal databases and say, Hey, let's move that to Salesforce. So it can be micro apps or larger enterprise apps, building those apps.

So as administrators, we're actually app builders, and there's going be an increase of citizen developers, a huge amount, you know, five hundred million apps are going to be launched in the next five-ten years according to numbers, and it keeps changing. And as we said, Salesforce is super powerful. It's an easy developer environment. Even citizens, users, CEO, CFO, CIO could be building apps on Salesforce, of course, there's a you know, an introduction to understanding the design, build, test deployment of apps, follow the trail, there's the URL here, a couple of URLs, you know, one just the general getting started with Salesforce DX.

And then you're looking at that with my administrator eyes. Of course, I want to understand how to manage my apps, how to help users adopt those. We change management. There's some small basic projects to do on like GitHub, get yourself a GitHub account, fairly straightforward.

How do I actually create myself a GitHub repository where we can deposit our source code, use Trailhead and create playgrounds, experiment with it. When you feel confident, you'll go to your production org and start to turn on these features at practice, follow that. And we're going to stick at these first two entry level. You know, how do I get myself a GitHub account?

How do I get some source code and control in there? There are some advanced tools to take your existing source code and convert those from one format, the traditional metadata format that Salesforce is used to, to now a source driven. You'll see that's much further up in terms of getting yourself in a mindset of thinking about your org as modules, putting those into containers as packages and converting those and putting those into your source code. So as you start to get further up the ramp, you are going to find yourself, your skill set increasing and there are still, unfortunately, some functions that are limited to command line, typing in commands or copying and pasting.

By that time you'll be comfortable with the environment tool, you build up a library of the most regular ten commands that you're using and you're copying and pasting. This is most of our admins. Developers are still memorizing and typing it out with auto suggestion, fabulous. They do that every day.

Our admins, what we found was they build themselves a doc or it's an intranet with the ten most common commands. And they're using the ten most common commands regularly can copy and paste. Only those that I can't achieve through the point and click tools on Visual Studio Code. That this journey will get you the command line installed on your desktop.

I'm not going to show you that today. So I've already gone ahead and installed the command line interface. I've installed the GitHub client. I've installed Visual Studio Code.

I've installed the plugins. So that's fine. The first couple of badges will get you there up and running. And then we're going to take a little look at a couple of examples of how I decided to show off Salesforce DX to administrators.

So I'm going to go off to a little org here. So Dev Hub is an interesting concept. So this would be inside our production org.

You're not going to see these two tabs. What I would suggest is, you know, create a micro app called Dev Hub, add these two folders into there, sorry, these two tabs into there, you're going to see active scratch orgs and scratch org info.

This will only become available when I go to the setup in Salesforce.

And regardless of the interface that you're actually using, oh, I might have to just Sorry, somehow it's logged me out.

Oh, right there.

Sorry, just logging back in again. So this is a demo org that I've got. It's like a production org.

I log in as an admin, so it's taking me directly to setup. I'm going to search for Dev Hub.

It's one of those features that once you enable, you won't be able to disable it again. So read the disclaimer there. I've obviously gone ahead and enabled it.

So this is the org where I have to have permission and anybody else is going to be able to create scratch orgs in your environment needs to have permissions and licenses on your Dev Hub. So it's a way of controlling that. And Salesforce has been very generous and even give you extra licenses for people that don't have a full blown Salesforce license. So you know, that's just your developers, your partners, etcetera, that you want them to create orgs under your environment, you switch on the Dev Hub.

Of course, there's some optional extras that I haven't switched on right yet. At some stage in your journey, you're going to say, right, I've got this concept, I've got my source code. Yes, I'm going to create a package and start moving a package around and you'll be able to enable unlocked packages. So there's two types of packages.

Those that every customer will be able to use. And of course, Umzoom is a customer and I've been for many decades now, I think. And also we're a developer that lists an app on the AppExchange, Umsom Financials, all accounting applications. So there's two types of packages.

As a customer, we're interested in unlocked packages, Somewhere along our journey, there's a badge on Trailhead, unlock packages, test it in your Trailhead environment, do it in a dev org, then when you're comfortable, come and switch it on. And then you'll work through the badge in your real live org and you'll get your modules into their own discrete packages. But obviously, we need to be thinking about what those packages are going to be rather than just dump everything in a single package. So definitely don't do that right now.

And then as you learn about what's your base package and those that you add on, you'll able to add on unlocked packages.

So effectively then what that does is enable these two tabs, your active scratch orgs and the information about the scratch org in just our production. So here in the demo org, obviously we've got a bunch of different apps, the two tabs that you can search.

So right now I'm just going to say there's one and we're going see that when I go to the command line, unfortunately at the moment, and what I'd really like is a button here that would say create scratch org. Not quite there, but I can see this and thinking, yeah, you know, and I've asked the product management in the year, I'm an admin, can I click a button here and create a scratch org? The answer is not yet.

Nice idea. I'm wondering when that will be available to make it life easier, but I didn't want to wait as an administrator and said, Okay, I'm going to get familiar with this concept being able to add and remove scratch org. So we've gone ahead and enabled it. Obviously, we haven't got much in there. The other tool that we said that we would install, I've got Visual Studio Code installed.

And when I click it, and a lot of the material is about going to the command line. And of course, I did follow the train and went to the terminal and either typed the commands or actually copied and pasted them from the documentation or from Trailhead. And then Visual Studio Code is a nice container. There's a command line included in the container as well.

So it just put everything into a simple interface for me. I thought, yeah, that's nice. I don't have to interact with multiple apps. When I do need to switch to the command line, I'll be able to actually do that directly in Visual Studio Code.

And then when you follow the documentation more than Trailhead, what you realize you can get command shift and P and a menu will appear of a whole heap of commands that will perform Salesforce DX commands for you and also GitHub commands for you. So I don't have to actually memorize, but I recognize them. I'm doing point and click and the command line is being fed the commands. And that's because we've got a range of plugins installed.

You can see we've already installed some extra add ons, Githin plugin, the Salesforce plugins. When you install it and you set up your environment, you'll get all of those in. And these tools allow us to do things like create a project. Now, if I follow the documentation, it'll ask me to point and click. But here, sorry, it'll ask me to use the command line. Here I can actually just go ahead and create a Salesforce DX project.

It's gone ahead and activated my extensions and the dialog is asking me what kind of Salesforce DX project do you want to create? You know, a standard project Or do you want an empty shell? And if I'm an advanced developer and say I want to do my own thing, then here's an empty shell standard, we build the template for you, as you'd expect it for Salesforce, and then you can commit it to your GitHub.

Would you want to do something with analytics? Now you can build analytics packages and templates in dispatch list. I'm just going to go ahead and say, build a standard project, give it a name, let's call it purchase order.

Where do you want to store that project? I'm just going to go ahead and put it on my desktop at the moment. We don't recommend create a folder with your various projects. These are going to contain two things. Obviously, it's the link to your source code control system.

I'm just going get rid of the welcome screen on the right hand side. And as we expand on the left hand side, Salesforce has built the container. They've also included a couple files that are super important for GitHub as well. So when we go to GitHub to create our repository, we want to make sure we're to do it blank.

So for example, there's a README file, you'll see that when we try and create a repository and get say right, we want put this in the repository. Number one, I want to back up. I want to sync. If I've got work in progress and this desktop dies, I want to be able to move to another desktop and install my tools.

And away I go, cool, I need a backup and this is the easiest way. Even working with the old, as an administrator, I work with the Salesforce IDE plugins for Eclipse. The concept of backup is a manual export, a manual zip file and put it in your cloud story so restoring is going to be a pain. So just the idea of this, we want to synchronize this to GitHub.

And there are files that we don't want to synchronize to GitHub. And Salesforce very kindly automatically builds.

And then we're just looking at the text representations, automatically builds all the files that you don't need to worry about tracking.

And we can add to this as we're working along, you know, there's going to be some components that will come out of our scratch org. And I say, I'm not interested in tracking that. That's a standard field in Salesforce. I don't need to worry about that.

Whenever I build Salesforce, that's always there, just my own customizations that I actually want to actually build. And there's a structure here that we'll see that the app that we actually have, you know, whether it's the apps that we see on the screen, you know, like my Dev Hub, or whether it's all your various objects and page layouts or code or triggers or lightning web components, here's where it's going to get stored in a hierarchical structure down to the metadata files in XML format or any other format. And we're going to synchronize that. And this is very lightweight and this is what we're moving around.

So the idea of being able to visualize my object as a flat file and say that's what I've actually created and then compare those on the screen as well.

I haven't gone ahead and created any default org yet.

So at this stage, I might go off to GitHub and say, I'm just going to create myself a repository.

So I switch to my browser.

When I create a GitHub account, I'm going to mark my repositories as private.

There is a special offer from Salesforce and GitHub that will get you a business account for up to five users free of charge.

Yet if I'm any developer, any admin, I can go and create a GitHub account and have a private repository with some limited functionality free of charge. I don't want to expose it to the rest of the world. You know, it's a profile. Of course, we run our app through there as well. So it's a collaborative environment that we can all look at features and functions that we're checking in committee.

So under my repositories, and I've actually got a few repositories or repos.

See here, we've got the purchase invoice or the sales invoice repository or a demo. I'm just going to move this screen out of the way. So I can say I'm just going to go ahead and create a new repository because I'm working on a module called purchase order.

Remember to set it to be private.

And even when you're in a team and collaborate, that means it's secure, you can then prevent two factor authentication to secure your code. And you can obviously invite other users into your repositories to collaborate in a secure environment.

This here you can see I've deselected in my world. That's the one gotcha. So when we're creating a Salesforce DX repository, make sure you avoid creating the README file because the next steps will not work. You notice that when I created my project on Visual Studio Code, it got README file in.

We're to put that into this repository anyway. So I want it blank. I don't want any gitignore or anything else on there. It's a complete shell.

Create my repository.

And that's the container, and that's where I'm going to sync my project. Notice the URL.

Great thing about GitHub, it's web based and we can link to URLs. It's going to recognize this is the address of your repository. Obviously, there's more advanced tools through Secure SSH. However, I'm a point and click admin.

I'm going to remember this URL and that's how we're going to identify our different repositories in GitHub. When we clone, it will ask us, give me the URL, the web link to where the repository actually links. It's going to bring a copy down to my computer. So it's a bit like cloud storage.

There's a copy on the cloud in GitHub. There's a copy on my desktop and the two will be synchronized. I recommend doing it manually because I'm committing changes. Only when I'm happy with a change, send it to GitHub.

Only when I want changes, bring them down and I'll manage when I want to do that. Of course, you can be super advanced and have it synchronizing all the time as well. You know, choose a way that actually works for you. So when we look at this empty container at the moment, nothing in there.

A couple of other things that I would do at this stage. So we've just got an empty shell and I'm going to in a moment create a scratch org and go into that scratch org and develop a new module.

But I'm going to initialize and it's auto suggesting you read the manuals and the documentation that says, Hey, type this command on the GitHub command line to initialize your repository.

Whereas, you know, I see here I can go command shift and P, type the menu, and a menu is being suggested. So initializing a repository is basically saying create an empty repository here on my computer.

Where do I actually want to put this repository? You know, the project that we've created, purchase order that saved on my desktop, I want a repository in there. So it's asking me to choose, and I don't have to worry about typing the whole path. It's already said, Hey, is this the one that you want because it's the project that I'm working in? Yes, that's what I want.

You'll notice that it's already detected. There are fifteen changes on your desktop. You haven't added them or checked them into GitHub yet.

And you haven't actually published your repository. So everything's here locally.

So one of the last steps that I'm going to do is I'm actually going to say, well, I've already got the repo. So the order of events is ensure you create a blank repository on GitHub, and then you come to Visual Studio Code and create your repository. And we're gonna link the two together and say, actually, this one already exists.

Back to command shift and P.

I love the auto suggestion. It's using my regular commands is already coming up here. If I don't know any command and I start typing Salesforce DX, you know, it gives me a whole list of functions. And I hope Salesforce will build that out.

As I say, it's still limited. There's certain things that I realized I tried to do. I went to the manual and I couldn't find the menu option to do that. So I did copy and paste to the actual command line.

But what I actually want to do here, go back.

I want to add my remote repository.

So I've created an empty shell here called the GitHub repository. I'm actually going to synchronize it to a remote repository, and we call that remote repository purchase order.

It says, now give me the web link of where that repository already exists, which just to make sure I copied it, double check, copy, Paste.

Done. We've now linked the two together.

And here you can see that now we have a option to synchronize the repository.

Now, just a little bit about this Visual Studio Code environment. Let's just move something out of the way.

There's a bunch of tools on the left hand side as well. We're not going to go through all of them as well. Notice right at the top for the time that I need to switch to the command line, I can begin a new terminal session.

And it's just a window inside Visual Studio Code. So in fact, I like the idea that I didn't even have to leave Visual Studio Code. Said, how much could I do in this one app on the desktop that Salesforce are recommending and thousands and millions of developers are using around the world. Oh, it's got an integrated terminal.

It's the command line interface. If I type in SFDX, you'll be told, go and start a command line on your Windows or your Mac and type these terminal commands in, and I can see here there's a bunch of commands as well. And I don't know if I can go SFDX.

Excuse my typing.

Oh, I see what I did wrong there. Sorry, SFDX.

You look at the screen while I'm typing as well, and you can drill into further on SFDX help about plugins SFDX help about give me a list of all the commands. So yes, I've got the documentation pinned to the browser page, but realize that there were like ten popular ones that I'm using regularly. And I've got them in my, you know, Word document, my Google Doc. I can go back to them, add to them regularly. Of course, you start to memorize what some of these things actually are.

If I wanted to, I could even switch to which terminal do I actually want to see. I can see the command line, the Salesforce CLI, the GitHub CLI, and it's all happening here with that single environment.

Now I'm going to move this. I'm just going to close a couple of these files over here, which you can to avoid a little bit distraction.

So looking at GitHub, we've created a new project. We haven't actually done anything in Salesforce yet, and it said you've got these fifteen files that have not been checked in or committed to GitHub. Do you want to add those in?

I'm going to put myself a message so I remember what did I actually check-in. I can review individually, and this is what's going on on the right hand side. If I choose to have a look at Force Ignore, A Salesforce file that's built as a template for you to identify those things that you shouldn't be tracking and checking in because they're system files. You don't need to worry about those. Every time you set up projects up, these will be created. So in fact, ignore those, you know, so Salesforce builds that in your template, puts these in. Again, we can add other elements to it.

I won't take you through all of them, but if I want to individually review and add it, I can add it or I can reject it individually as a list. I'm just going to go ahead and add all of those fifteen in. So it's now saying it's staged. And once I'm happy, I'm going to do a local commit.

What local commit is saying, hard save these to my local repository. I'm happy with the changes. That's my anchor point. If I fail, I've always got that rollback.

Go ahead and hard commit and save it to my local repository.

So I've now got an option to send the changes up to GitHub.

I'm going to go ahead and publish it.

Now we've created the link and the relationship. I've now put a copy on there. But if the machine dies at this point, that's my rollback position.

If we come back to our GitHub repository, we can see all the files that we had has already been created, including that README file that we said don't build your own because that'll cause conflicts and stop it from creating. It's all been created. Okay, let's A good practice on my source code, I'm actually going to create a copy of this now just to demonstrate. I know I haven't put anything in here, but I'm going create a developer branch.

I'm actually going to create a feature branch as well. So this is our stable code. We're now going to have an experimental branch where we know it's not all working correctly because it's development. And then I'm going to have a real experimental branch called the feature branch, and it tends to be that free model or master or stable code we could push to production at any time.

That's always working. That's the goal.

Everything in development is approved QA, but not quite ready to merge into our source code. So we can do a couple of things. And there's a nice little gem of a tool that comes from GitHub.

Normally I would copy and paste this and tell my command line to open the repository and use command line tools to create copies.

Yet there's an even easier way.

So I've installed an additional app that you'll find on GitHub called GitHub Desktop.

Windows and Mac graphical user interface is a nice way All of these saying, and that's true, this already exists on your desktop. I'm not going to clone it. So thank you very much. Already managing the conflict for me. It says this repository exists, choose it.

So we just have to alert GitHub Desktop.

There are repositories here. And from here I found a tool that allows me to browse my GitHub repositories, but more importantly, with a point and click interface, be able to create a new branch.

I'm going to call it Develop.

I'm going to take a copy of Master. Let's go ahead and create that branch.

And similarly, a point and click tool that says, let's go and publish that. I've created a replica of our source code.

And when it's finished publishing that, and the two work in tandem.

If I make changes in Visual Studio Code and they're tracked, they're also tracked in my desktop tool. I can use either tool to manage and update and both are being synchronized. They're both talking to the same repository on my computer.

So if I now switch to the web interface, previously we had one branch.

Now I've got my master repository, call, safe, nothing wrong in there, no bugs. I built a developer branch, and we're going to use that to check-in our changes.

So therefore, I'm going to create yet another branch to start experimenting with a new feature. So let's go new branch.

So that's the advice naming convention, you know, come up with your own naming convention, you know, feature slash, that means it's work in progress. Master, everyone know that's your master, develop the unstable work in progress and feature all experiments, features, anything they're actually working on. So let's go ahead and call it, in fact, new.

I've not created it before. I want to create a new purchase order. I'm actually going to create a clone of the develop branch now.

Let me just move the meeting window out of the way and go create branch.

And we'll just go ahead and publish that as well.

Now, this is the branch that I'm going to work on. So I'm going to go away.

I can close the other project that I actually created.

This time I'm going to go back, and I was working in my repository both different ways. I can open it in Visual Studio Code or directly here I can say repository open in Visual Studio Code or your preferred IDE, your developer environment. And this is open that.

And we're going to be synchronizing it. This time though, what we'll actually do is we'll move forward now and say, I don't actually have one of these scratch orgs created.

And if I go command shift and P or control shift and P, I can see the option for create. Or if I was typing create, it's going to auto suggest the various functions. I can SFDX, whether I'm creating another kind of file, I want to create a default scratch org.

Before I do that, I'm gonna need to authorize my Dev Hub.

A request is going to go to our Dev Hub that we showed earlier on to say this is the authenticated user, are they authorized to create scratch orgs on our behalf? Yes or no? Yes. What's our daily allowance?

How many have we got? What's the template that we're going to use to build? That, I'm just going to go ahead. It's a web flow.

It's OAuth, open authentication. A browser window is going to pop up and say, please log into your Dev Hub.

Luckily, I'm already logged in, it gives me the green light. Depending on what your setup is, you're going to need to use username, password. If you're already logged in, it will show you the user will go directly to that org and say, thank you, you've authenticated. You can now close that browser window. So when I go back, it says it's run completely.

I start to hide away these messages. If I really want to, I can go show me the output.

Let me just resize these windows so we can bring that to our attention.

And what it's very nicely done for me, the whole idea of typing a command into the command line, obviously the point jump click function added it there into the command line. Relatively short one, SFDX force colon auth web, you know, you start to learn these, but when you use them regularly, obviously I'm moving to point and click saying right now I recognize it. What I want to do is create a default scratch org.

One of the parameters we would normally send to the command line is what's the template of this scratch org? What's it going to look like? I won't show you all the details in there. We're using the standard template, point and click, saying this one, it's the one that was included in our project when we created it. But you can tailor all of that.

What do you want to call this scratch awl?

You're going to have lots of them to give it a name that you're going to recognize as rather than the username. So let's call it new purchase order. How long do you want this scratch org to last? It defaults to seven days.

I could have it to one day. I can create and delete them on demand within a few minutes. We're going to see this within sixty seconds.

Create a new scratch org for us. If we ever tried to create a sandbox and you've waited for your sandbox to be created, you've waited for your sandbox to be activated, then you're moving from idea to prototyping, the time is shrunk just having an environment that you can actually spin up almost immediately.

I'm going to leave it to the seven days and say, let's use the default.

And now it's running the command line instructions for me and going to my Dev Hub, authorizing me, creating an instruction, spinning up a new org, and the new org is available, and we can see we're connected. Little icon. There is a command line instruction, I know, to open my default scratch awl, but that point and click saved me remembering all of those values, which of course I can copy and paste to my own manual and use it every time. But again, it's automated all of that for me. Can do it through a point and click interface, click a button.

And what it's going to do is log me in and anybody who's had an issue of logging into sandbox is trying to remember what the username is, password is, you created a new one from live, guess what your email address is obfuscated, it's not going to work, you can't do password reset, what was it?

And actually, you have a full environment here, I can reset passwords. But one of the benefits is just clicking the URL. I logged into this org, a Scratch org, which all intents and purposes looks like a developer org, which it is. We've created a standard developer org.

If I go back to my Dev Hub and I refresh, let me just move that out of way, we see a new one's arrived in the list.

This was the date it was created.

If I drill into it, it's showing me a summary, you know, so in terms of managing as our team grows or the environment grows.

Behind the scenes, there is a file, a scratch org request file. If you delete that, the scratch org will go away. You can also delete it from the command line. So if it was an experiment that lasts an hour, you can spin up an org, do your experiment and delete it, and it's gone. Within the limits that I can do eighty to two hundred or whatever it is within our license, this is the date it's going to expire.

And when it gets deleted, it will track who deleted it. We can also configure it with various features. That's done through the project files actually locally, but I can still see and come up with this idea of what's our classic template that we want that reflects our production org. But if we don't have one and we're experimenting with Einstein Analytics, hey, just create me a default Einstein Analytics org.

It doesn't have to be a replica of our sandbox. So actually you get an access to features that don't exist in your production org or your sandbox. You can try them out and experiment and really visualize that and show business users without spending money on any additional licenses from Salesforce. So that's extremely valuable.

You know, take advantage of that. I do have a username. It doesn't show you your password. Use your password management tools to manage your password.

So I'd gone into the browser and logged into my Scratchalk. I'm just going to go in and you will see a whole heap of objects and functions switched on. You can turn them on or off as well. If you want particular functions, you know, communities on or off, chatter on or off, quotes on or off, and you build up your profile as that will be our standard template.

But we've just gone with the vanilla one, and you're going to start to see objects that you've probably never seen in your production org or didn't realize they existed because you're getting a whole week of functionality from Salesforce. I'm just going to check if we got a purchase order.

No. So obviously I'm in my scratch org, I know because I can detect that based on my ID.

Let's just make sure there wasn't anything else. So we've got a few branches.

I think I'm just going to go ahead and say create a new object.

So the business would like to have the idea of purchase orders and requests and approvals and automation through Salesforce. Could this be something we could build? We had it in Excel, we had it in a desktop app internally, or we use bits of paper, could we digitize it? Could we migrate it? You know, whether we build from scratch or use, you know, the tools that Salesforce is helping you with, you know, spreadsheet migration, I'm just going to say, well, actually I can spin this up and get a prototype going fairly quickly. So let's go purchase order.

And just type in some default values.

I am going to manipulate a field here because I want the purchase order numbers to be automatically generated. By the way, in case I forget, I want a tab creating for this as well. So we've got a purchase orders tab to go to as well. We want it to have reports.

Do we want activities? Yeah, we might be able to email and store email and communication next to that. We'll probably want to track field history as well, know, all features that you would decide on when you're building the app. Let's go and get that number and say, let's use this simple copy and paste.

And I'm actually going to call it PO, and our starting number is going to be one thousand, so we don't have to start from zero. I'm just going to default it and go save.

I'm just going to add a random icon. I think there's one down here. Shopping cart. Let's just go ahead and add that.

Getting in the way again. Go next.

This is everything that a Salesforce admin does on every single day. So I'm just going to go through and leave that by default in terms of who can see it. I'm not going to add it to any of the apps right now. I'm going to go save.

Created our object, created our tab. We've actually granted permission to certain profiles as well. You know, a lot of things that we forget accidentally. I've updated some profiles.

We'll just go next, next. I'm just going to add one field just so we have something to check and track. When we're checking in, I'm going to do a lookup. Of course, the lookup would be to a supplier account.

Let's go account.

And through the wizard, again, I'm doing several things. I'm creating a field.

I'm adding in description to the field, settings all the way down to a granular level. We're going to see even on this field, the constraint that we've set is if we've got a purchase order linked to an account, do not let the account be deleted. Try to migrate that to a live system as well. That's the kind of thing that I'm going to forget until later on. So I've deliberately made a tiny little change so we know the source code is actually going to track it. And go next.

And as you'd expect, you know, who can actually see? We're down to a field level. Remember those four core things right over in the third one, it said field level visibility. We don't realize that we've gone over to security. Who should be able to see this?

And what I'm doing in experiment is just leaving the default.

What about a page layout? Yes, we're going to need to add a page layout.

Which account pages will we need to add this purchase order to as well? I'm just going to leave it by default and go save.

Now, if that's what we wanted, I'm wondering how many components I need to track for my change set and I write them down, the probability that I've done it after I'm too busy building, and I'll go back and try and write them down and remember what did I do. So right now that's it. I'm going to go back to my Visual Studio Code.

There are command line interfaces, but I'm going to use the menu to say pull, and I'm going to bring down changes. There's a push and pull. I can make changes here in Visual Studio Code and push them, or I can go pull them from my default scratch org. Either way, you can have multiple orgs. You can be pushing and pulling from sandboxes, scratch orgs, and have multiple orgs connected at the same time as well, but we're just going to use one. Similarly, we say, great, show me the command that you ran and the result.

So this is what the manual will say.

So we opened the org and then I ran a command that said, Get all the source code down. It says, Great, these are the components that we found that have changed.

Well, I've got my notification that the source code control system, GitHub has detected, we made a number of changes.

There's one of these that I definitely don't want to track because it's the admin profile. That's the vanilla Salesforce one. You know, when I create an org, it gives you that one. Actually, that's not a good thing to track.

I should be using permission sets or a custom profile, which are not created yet. So scanning down here, I can do two things. Number one, ignore it and add it to get ignored. Say, whenever I make changes, ignore this file.

I don't really want to think about it or completely delete it.

I'm just gonna delete that file and say, never track it for me. Don't even ignore it, but just never track. I can scan through the others and even drill into the field. Let's come down here.

And you can see everything's highlighted as green because here's the metadata about the field that we created. And I deliberately entered in values here because I wanted to, I could also change the values here.

So when I'm reviewing changes that developers are checking in an admin and I'm finding a typo, I don't have to worry about going to the sandbox and saying, Oh, that's a change I'd make right now.

That should be a capital S. And if I want to, again, it's detected a change here and notified me, I can go file, save.

I can push and pull. So I can work right here and realize, and you'll notice the same is true in GitHub. Great. I can review all of those, but I'm not going to review any more. I can check them in individually or as we did before. And again, I'm just going to move that meeting out of the way.

I'm going to add in all eight and call it New Purchase Invoice.

Added.

Commit that to my local repository.

Bear in mind though, that's still only sitting on my computer. So another indicator in Visual Studio Code, I have one change that I've not sent to the server.

If the same is true and one of my colleagues has made a change and sent it to GitHub, it will tell me, Hey, there's a change on GitHub that you need to bring down. I like to be in control and see that visually and manually before I merge it into avoid accidents. If you're hyper confident, then you can set it up to automatically keep all of that in synchronization. But I can see there's no changes to come down, but I should be sending a change to GitHub and saying, great, I've now got that synchronized.

So if I get called off to an emergency and the scratch org expires or my desktop dies, or maybe I get sent home because of lockdown and I've got to work from a different computer at home. Now the ability that I can actually do my setup and get access to this from anywhere, I can now revisit my GitHub repository. Move this out of the way. Sorry, it's going to get me the menu out of the way.

So I'm just going to refresh to show that we now have three branches.

The new experiment that we're actually working on, the new purchase order branch is telling me who committed one minute ago.

I can compare it to the dev branch and the master branch. And if I know I'm ready to check this in, that's my basic purchase order object created, and that's what the boss wanted. I've shown him and he says, I'm happy. Check that in, please.

So not only can I compare to both the master and the develop branch, I'm going to say, I want to check that into develop because it's not finished? I know you're not going be able to create a purchase order and save, there's more work that we're going to need to do, but they said this bit, thanks very much, that has delivered that user story. Go ahead and check it in. So keep checking in functions.

Don't have to wait till the whole thing. The advice is commit regularly, sync regularly. How often you do pull requests will be your own development team's decisions. And notice what it's saying is, hey, there's eight files that have been added.

They're the same files. I can review them individually, make changes here, Let's check those, do QA review. And if I'm happy, say, Yeah, so this is me as the admin or one of your colleagues ready to check-in and say, Create my pull request.

We'll now check that in. When that gets merged in, there's a whole history and an audit trail down to an individual file level. So we see that I've got that one check-in. I'm just going to go ahead and cheat and say, merge pull request, merge it.

It could be a bunch of QA, you could pull that and pull it to another scratch org. So what's happening is when you check it in, I can pull it and do another scratch org. Because what we find is that modules and functions work on the developer's desktop. Of course, all the dependencies are there. They work in their sandbox. Of course they do. Then you move it to live and it doesn't work.

Because they inherited a dependency that only on the developer environment. So I can now take this and push it to another scratch org and test it if I want to as well. So however you build your QA process.

If I wanted to go to my scratch org and let's say finally make another change.

I forgot to add a description to the object. Sorry, I'm going the long way around. I've got the window open here, haven't I? So if we go to the details of the actual object, I should put a description in.

We're just going to go ahead and make that one change.

So therefore, can push and pull changes. One of the things that I might want to do is just push my source. I made a local change on my repository, and I'm not convinced it went to my scratch So this is what we're doing here. Anything I made here in Visual Studio Code or was made at GitHub, brought it down to my local, and I'm going to push it to my scratch org so I can see it in the org.

And then do it the other way around as well. I can actually pull changes from my Scratch org to my local repository.

So I can both make changes here in GitHub or in the scratch org or any other scratch org and get them synced to our core GitHub repository. We noticed there are couple of changes made. I'm going to fast track through this and say object description.

I'm going to commit it because they were the changes that we made in our scratch org. Push.

Make sure it gets synchronized up to Git. All happening relatively quickly. Obviously, the faster you Sorry, the more you work with it, the more repetition you'll have, the more confident you'll get. I can go to my develop branch because I made yet another change in my develop branch and say, I want to do a new pull request.

And I'm going to merge it in from my purchase order to my develop great tool to compare what are the actual differences.

And I can see that two files were changed. I didn't make any deletions. You'll see deletion. So actually the object already exists, but there was one change made. A description was updated. Actually, we do have a deletion.

So I'd already put supplier in and it's reverted that again. I can edit and modify directly here. I won't. I'll take those and say I'm going to check those in.

I created a new request to merge that into develop. That's why I'm updating it. If I realized that was a mistake, I could forget it and go back and work in my scratch org without causing damage. If I'd have accidentally done that in a sandbox, I have to go back and undo work.

And I think at this stage, that's quite a lot of content to take in. I'm sure if we were, you know, live, we could take some Q and A or questions or anything.

I think thank you very much for watching.

I've got a couple of questions Bash, I know this took a while but you're right, it is a lot of content and it's super important too.

The obvious question is, can you do this with everything in Salesforce? Is there a list of limitations that makes this hard for administrator to use?

There are limitations, there are limitations indeed, indeed. So just like working with an application programmers interface API.

So yes, the Salesforce command line interface.

It's a combination, though. There's some limits through the metadata API. So what this is doing, Leonard, is using the metadata API, which doesn't support everything. When you try and execute it through the command line, you are constrained by much of the same limit. So yes, there are two documentations to check what metadata commands actually exist and certain things you couldn't do through the metadata API and the same is true with the command line.

But the meat and potatoes of Salesforce administration, creating custom objects, creating new fields and standard objects, changing, you know, permissions, profiles, things like that. That all can be done through this, right?

That can all be done. Yeah. Okay.

So that's good and just to say I push something into Salesforce and I didn't like it, is there a rollback? Can I take that app out? Now that I package it as an app, I assume I can just take that app back out, right? Or is that not the case?

Where you are on that journey, that ascent to the top spot on, Leonard, you'll have versions of packages. You'll have versions. The whole beauty of moving to versions is I've installed a version, uh-oh, a bug's leaked into production, revert to previous version. Indeed, if you just use the demo that I showed you, no, it's not easy.

Right.

You still have to use things like, you know, the destructive XML file to remove content from the actual metadata. But when you move to packages, you'll be able to switch versions say, Oh, I've updated that version, roll back to a previous version.

And if I'm an administrator just thinking about getting started with this there's free versions of everything you use, right?

Versus code, I don't have to buy the commercial version to use that. I can get a free GitHub account. I can basically, and use my developer org, I can just do this for free, right?

In fact, use it if you have a enterprise or above.

Okay.

Well, know there's professional and essentials.

Right.

But you're right, if you have enterprise and above, you can actually do it in your production org.

Right.

But if you're on professional edition, you might be missing a lot of the functionality like APIs that are in your org. You know, it's a licensing limitation.

Okay.

You'd be paid to add that on. So it's got to be an enterprise above. You don't even need to go and get a developer role. Yes, you can do this from a developer role. Of course, the go to place is Trailhead. Right.

And there you can actually create trail playgrounds that again last forever and you can do this whole thing from there as well. So yes, your developer hub could be your dev org or Trailhead playground.

I'm just thinking about the administrator who doesn't want to go and do anything in his production system to start with. You can do this all for free using Trailhead, DevOrgs, etcetera, Versus Code public, great, perfect. All right, well, it's a great presentation. It's a great capability, long overdue in Salesforce. Nice to see them developing it and I appreciate your time and effort today, Bash.

You too. Thank you very much for your time as well. And thank you everybody for watching. Take care.

‍