Salesforce, Inc. (CRM) Earnings Call Transcript & Summary

Hi, everyone. Thanks for making time to join us today on our Salesforce Platform Munch n' Learn series. Good morning. Just some housekeeping mentions before we get started. [Operator Instructions] One more thing to note, we've also posted links to additional resources on the console under related content, which you can download and peruse later as well. So today's webinar is a Munch n' Learn session. As a thank you for joining us live today, you'll receive a unique voucher code in your e-mail after this session. It might take a couple of days for us to just collect the attendance data so do be patient and look out for that e-mail either in your inbox or perhaps maybe even your spam folder. But you have a month to use them, so do get munching. My name is Adeline. I am the product marketing manager for our platform business at Salesforce across APAC. And today, I'm joined by Haneesha and Mike, who is the platform lead and our platform technical architect in Australia and New Zealand as well. So we'll be hearing from them a little bit more in a bit. But just before we do that, today's agenda, so coming back to the title of today's session, innovate fast with modern development tools and processes on Salesforce. We just kick start with why is that important? Why does it matter? How it helps you connect to your customers better? And then we will go into some tooling that Salesforce has to be able to help you on this journey. So how we can leverage Sandboxes, our DevOps Center as well and how you can secure everything that's happening across your DevOps process with Data Mask. Then like I mentioned, we will jump into some Q&A towards the end of the session. So without further ado, I will hand over to Haneesha. Hany, over to you.

Awesome. Thanks. Thanks, Adeline. Let's dive right in, guys. So if you've invested in Salesforce technology, it's likely that you've seen this well. and that the Customer 360 is part of your ultimate goal. It's what a lot of our customers want, and this is an aspiration, and it's absolutely achievable, but not without platform solutions. So the long and short of it is, the platform is the how. It's how you build your Customer 360. And what we're going to discuss today is some of the tooling that will enable you on your vision to create the one unified Salesforce experience across your organization. How should you be building, testing and deploying. We'll look at how platform products can underpin your successful deployments and implementation to make it real and easy. And although these tools are largely used by IT teams it's also important to be well aware of what they are and how it will actually help you deliver faster time to value, support rapid adoption and are tailored to your business needs. So let's take a quick look at where we are today. The last couple of years, we've seen a lot of unprecedented time. And gosh, that's the word that's been overused, if I have to say so. So we can all have some appreciation, I think, for the current macroeconomic challenges that we're all facing. And what it actually means in particular for IT teams, like how uncertainty drives developer talent shortages, which hinders the focus on innovation. Our CIOs are tasked with doing more with less and accelerating time to value in their digital investments. How can they make use of resources on their IT teams to be more efficient? What tools can they be equipped with so that they take -- what tools can they equip their teams with to progress quicker so that they can actually connect disparate systems, disconnected data really quickly, allowing their business to become more customer-centric. And -- I'm sorry, I'm just waiting for the slides to change over. It's a bit slow. And so when it comes to Salesforce and when you're thinking about some of these changes, these are some of the questions top of mind, especially when you're talking about developing different features and changes. How do I manage changes across our Salesforce orgs? How do I actually automate our inefficient and manual processes? How do I train new users to drive rapid adoption in ROI? How do I deploy our Customer 360 really quickly and safely? What other items are you focused on. If I haven't captured your thoughts, please feel free to drop it into the chat box so that we have visibility of that. So let's take a look at our platform build solutions and review some of the relevant products to help you achieve that Customer 360. And in particular, those -- in particular, some of those use cases that we talked about. So this is a few and not definitely all of the tools that we have available, but these are the specific ones that we intend on going into a little bit of detail about today. So implementation, for example, always starts with building and testing changes safely and securely in an environment like a Sandbox. So no customer of ours should be building or testing in their production org with the Sandbox or copy of your production environment, businesses can lower IT spend and decrease your risk to live business work. We'll also be showing you how to stay compliant by leveraging a tool like Data Mask to actually anonymize the sensitive data in your Sandbox environment. So your customer information is always safe. And in addition to leveraging Sandboxes, it's most likely that development teams will have multiple Sandboxes for parallel development or most likely multiple developers be working on the same project at the same time. So with DevOps, which is Salesforce's newest kid on the block, teams can have better control over change and release management capabilities. Teams can automate the DevOps process by breaking down a single project into multiple tasks or work items and safely move their changes in their Sandboxes to production. Changes are automatically tracked as development has done in Sandbox synced back into GitHub and deployments are centrally managed. Admins can use the new DevOps Center user interface, while developers can continue to use their usual integrated development environment, whatever they're used to. And lastly, code builder, which is a web-based developer environment, which is another tool that Salesforce's version, which developers can have access to as no in-store required IDE and you can build straight out of the browser. Let's first of all, click into Sandboxes and talk a little bit about development. So a couple of the terms that get thrown around in industry quite a bit, things like DevOps or application life cycle management. And for some people, this probably makes sense, it's their bread and butter. But for some, it can be a bit alien. So I've got Mike. Mike, can you help us simplify this for our audience. What is DevOps? And why should our customers really care about this?

Yes, I can. And good morning, Hany, by the way, and hi, everybody. I'm Mike Burnside. I'm a technical architect in the platform team. And yes, the ALM and DevOps terms, plus many others have thrown around a lot. So let's just define simply what they mean. So application life cycle management, ALM, it's really -- it's almost a philosophy about how to bring together the people and the processes and the technology to deliver solutions in a continuous way. And in the diagram on the slide is a representation of a cycle of activity is true whether you're doing the simplest customization in Sales Cloud, you might be adding some fields or the most sophisticated workflow or Lightning Web or APEX. It's always the same. The life cycle is something along the lines of plan what you do as we go around the wheel, plan what you do, use the tools to create your solution and that's where the tooling is very different depending on what you wanting to do. For example, automating a process you would use Flow, building a Lightning Web Component, you might use Visual Studio, et cetera. Once you've created it using the correct tooling, you would then test what you've done to ensure that it, first of all, it works, which is very important. And secondly, is of the right quality through documentation and so forth. And then you would release it into the wild for users to use, and then you would typically take some sort of feedback about how it's performing, whether it's doing the job and you would find that you would be then subsequently implementing new features. And you go through the loop again. So application life cycle management describes that sort of cycle. And DevOps is another term that's used often applies to tooling, the tooling to automate some of the processes involved in getting code from its earliest stages all the way through to production, okay? So the cycle is interesting because Salesforce has tooling or products virtually in every cycle of -- at every stage of this cycle, and they're represented around Infinity being here. Everything from environments, which we'll talk about shortly, through builders, through tools related to the security of development, again, we'll be talking about that, et cetera, tools to monitor. And of course, AppExchange which is where you can achieve a lot without writing any code by simply provisioning apps from the AppExchange. So Hany, if you don't mind, I might pop in and just talk about Sandboxes, if that's -- is that going to be helpful? Yes, because I think that...

I think that will be very helpful.

Yes. Look, I think the thing about development is you need some way to develop. And the place that we would recommend that all development takes place is in what we call Sandboxes. Because nobody, nobody would be advised to make changes in a production system. It's very risky, okay? You don't want to disrupt your business. So the thing about a Sand -- for those that don't know about Sandboxes, I know many of you do, some of you don't. Sandboxes are really isolated environments that are copies of production. So it's very important as a developer to work on a stable version of a system. You want the data model to be the same. You want the validation rules to be the same. You want all of the security settings to be stable. So Sandboxes provide a copy of production as a head start for developers to work in a particular environment. Some Sandboxes contain data. So -- and we'll talk about that shortly when it comes to the types of Sandboxes. Look, in a nutshell, Hany, the recommended best practice for development and customizing in Salesforce is to use 1 or usually more Sandboxes and to connect them into what we're calling a pipeline. And I'll be doing a demo of that later. So does that make sense, Hany? Is that a reasonable explanation or...

Yes. I think that's a great explanation, Mike. So you mentioned obviously that there's different types of Sandboxes. It's not just 1 size fits all. So let's kind of take a look at what that is. So Sandboxes come in different shapes and sizes, and they're actually used at different stages of that development cycle. So that big infinity loop that you had upfront, you use different types of Sandboxes at different stages of that. And they vary based on the different data storage limit that they have, whether it's their refresh cycle in terms of how often they're refreshing from the production data and how much metadata they actually bring over from production. So you've got a full copy that brings over everything where you've got a partial that brings over a subset. So when you think about the different use cases for Sandboxes, it really depends on the stage like dev, test, integration, staging or UAT. And this will determine whether you require a full copy versus a partial copy. And based on that, decision whether you need the full production data set or a smaller sample. And you can also see from a pricing perspective based on the Sandbox, it results in different pricing as well. And that's usually calculated as a percentage of your core licensing spend due to the nature of replication. So when in doubt, check your licensing to see what you're actually entitled to. So for example, if you've got unlimited addition, you've already got a full copy Sandbox at your disposal to use as part of your development process. So Mike, what are some of the scenarios when customers actually need to use the Sandbox?

Well, I could give you a glib answer, and that would be whenever you're making customizations at all, you're not going to be doing them in production. Actually, the biggest decision to make is what sort of Sandbox, not whether you need a Sandbox, okay? So if you're doing simple customizations to fields or building validation rules or even simple Lightning Web Components, you can typically get away with 1 of the dev or dev pro Sandboxes, right? If you're principally testing logic and maybe lay out on a screen, for example, or simple validations, et cetera, you can get away with a dev or a dev pro Sandbox. If you're doing something like implementing an add-on, like some of the complicated add-ons like field service or CPQ, by their nature, they are data-driven. So you imagine an application that's making decisions about, for example, CPQ, making decisions about pricing, for example, on a body of data related to rules in pricing. That's an example where -- to fulfill a solution, you're really going to need to be testing it for real with data that represents the end system, okay? So I guess I could summarize it like this. You always need a Sandbox, but we provide enough choice for customers to choose which sort, okay? The more important, the data or the scale is another example then you would need volumes of data. Now within the data populated Sandboxes, there are partial and full. Partial provides a good sample of data, and that's great for integration, testing and so forth whereas full Sandboxes are literally a mirror image of production, including all of the data. So that would be my tip. Hany?

Awesome. Thanks, Mike. So I just take a pause there. If anyone has any questions so far, continue to drop that into the chat window, and we'll address that during our Q&A session. So look, we've talked about Sandboxes and the detail of them. In summary, you want to be leveraging Sandboxes for training and training and product support, when you're doing parallel development, app testing and automation, app dev or all customization and implementing new products. And obviously, throughout this process, you've got different people, different resources working on this at the same time. So how do we actually address the whole collaboration across the different -- across your development team and actually help you deploy the changes and manage those changes in a seamless way. And that's really where you can on the block DevOps Center really fits into that puzzle. So DevOps Center is the place to manage releases and to give low-code or pro-code development team members, a single test of configuration in code to work with by bringing that whole collaboration closer. It's basically a free tool and it's the replacement for change sets. And it enables everyone to deploy changes using a single elegant point-and-click interface. So this product will actually help modern change and release management capabilities and best practices to all of our Salesforce developers, including our declarative developers and admins. So let's talk through or highlight. I'm just going to highlight some of the features that this product has. So we've talked about the fact that it's a UI-based application. So really, this is where you can manage the overall experience. Changes are automatically tracked as development is done in a development Sandbox. You can leverage the source tracking. It can be displayed to the user interface to easily see what components have been changed and therefore, what needs to be managed and migrated over across your different environments. The changes itself seamlessly synced to GitHub using a simple UI interface in the DevOps Center. So GitHub will provide proof of -- the point of collaboration for team members, developing together to facilitate review and synchronize across the multiple development streams. Deployments are also based on source that is managed essentially in the source control system. So that ensures consistency and reliability when creating and deploying release artifacts. And on top of that, you've got low-code users can now work alongside their pro-code counterparts and vice versa, operating against the same source of truth and utilizing the same modern practices of deployment. And because the experience is built on a shared source of truth in a source control repository that leverages the Salesforce developer project format, users can actually interact with the project by using clicks through the graphical UI in DevOps Center or through a programmatic in space like a command line or an IDE, and everything still stays in sync. So it's up to you in terms of which format you want to work with. And that really allows for the hybrid infusion teams to work together on their own terms. So this overall flow is essentially it's a change set alternative. And best of all, this tool is actually free to you. So you can actually get your hands on this right now to play around with. Now I guess I've talked through a lot of different features here. And sometimes, these things -- it's easier to actually see it in action. So Mike, do you have a demo that you can take us through -- we've talked about Sandboxes. We've talked about DevOps Center, how people can actually use this practically?

I do. Thank you. So what I've done here, I've put together a pretty comprehensive demo. And then I've taken rather than try to do it live because of bandwidth issues. I've taken screen shots of various significant screen and that allows me to go through fairly rapidly. So let me get -- and I'm going to show you DevOps Center. I'm going to show Sandboxes in action and so forth. So let's get started. So my demo org is that imagine -- it's a pretty sophisticated application. Imagine that I'm selling electric bikes, I built a application. And like all -- and this is on the sophisticated end of applications, it uses a user interfaces Lightning Web Components. So that involves who people that understand JavaScript and typically also people that understand APEX. And imagine that the org is not only -- and Lightning Web has some fantastic benefits you can compose apps from reusable pieces. The business users can be composing the UI. Imagine my organization also as an AWS customer. Imagine that we have DynamoDB and Athena. So here's a picture of the console for AWS. I'm using Athena for sales order archive. I'm using Dynamo for ordering, et cetera. So my application can take advantage of those data sources through external objects. So here, I have an external object that's bringing in data from AWS live. So in this case, this account has live access to the DynamoDB backwards and so forth. So that part of the system requires an admin to understand how to set up external objects. So we have the JavaScript builders, the APEX builders, the people that understand data modeling, the people that have configured the external objects. And then to perform automation, you would turn to a tool like Flow. So business users here are assembling the Flow to automate process. So I mean they are typically developers, okay? So how do we get all of these people on the same page, collaborating to build apps that are becoming increasingly sophisticated. So it starts with somewhere to do the building. So what I'm showing here is some Sandboxes that -- let me just synchronize my screen. And here are some Sandboxes that I set up for the demo. I've got a couple of 4 Sandboxes. And as Hany mentioned, they are complete replicas of production. So my million records of sales orders or whatever it is in production is represented in the same quantity in these 4 Sandboxes. Similarly, developer pro Sandboxes are mirrors of the metadata but are empty. And that's right at the early stages of production. But it's a bit of a misunderstanding to think that 1 can't populates dev Sandboxes -- I'll show you how that's done in a second actually. So the way to build a Sandbox is to name it, choose the type. In this case, I'm going to load a CSV file just for fun, just because I asked it's a lot. I thought it might be a technique some of you may not know about. So I have a CSV file full of accounts and contacts and I'm going to take advantage of the post-copy interface on the Sandbox, plus a simple piece of APEX, it's like 29 of APEX. So you upload CSV to static resources, parse out the details and tell Salesforce that you want the APEX to run than it refreshes to Sandbox, et cetera, right? I know that's not the topic for the day, but I thought it might be interesting for some of you there. So you can actually pre-populate dev Sandboxes. But let's imagine we've got some changes to make. Let's actually get into the -- I'll just skip some of this then. Let's imagine, we've got some changes to make. Let's imagine, we've got a couple of tasks, we've been asked to maybe produce an enhanced version of a welcome flow for whatever reason. And perhaps an APEX class that does a call out to a new service. I'm just -- it's just a couple of random examples. Now as a developer, the first thing I would not be doing is trying to do this in this Sandbox. This is the UAT Sandbox. You can tell because the banner across the top tells you that what Sandbox you're in. Now, what you would do is you would start in a dev Sandbox. And in the dev Sandbox, you would be using the traditional tools to do the job at hand. So for the flow, I might use Flow Builder. And here I'm editing a little screen flow so far. Again, I'm in the dev pro Sandbox. Again, just let me catch up. And then to promote those changes to UAT, you would typically use -- well, to date, you will use what are called Change Sets. And you would indicate here that the transition state, the transition locations between UAT and dev and staging and so forth. And then you would use change sets, which are effectively a wizard to build a package. Here, I'm indicating I want to package up the flow that I've just build. And then you would upload the change set as an outbound change set imported as an inbound change set in UAT and there you are. And the result would be UAT now has your changes. Okay. So what if there was a better way and there is a better way. And Hany mentioned it, it's called DevOps Center. So let's take a look at DevOps Center. The first thing you notice about DevOps Center -- and again, let me just catch up my other screen here. Actually, the first thing you'll notice about DevOps Center, Hany already told you that it's free. That's a good thing. The second thing you'll notice about DevOps Center is that it represents the stages of your development as a pipeline, which is how you want to visualize it, I think, your mental model should be moving code from development through to production. The change sets don't give you that visualization. They just don't. It's kind of disconnected, I think. So DevOps Center is a result of a lot of demand from customers to make this process easier. So we start with a visual. And here you can see the various stages. I've got a development environment set up on the left-hand side here, progressing into UAT, progressing into staging and then ultimately production. Okay. So let's get started and actually do something. The unit of work in DevOps Center is called a work item. So it's a list of tasks that have been associated with the person. Here, I'm going to build my own -- again trying to coordinate my screen. I'm going to set myself a work item to build a fancy new interface. I'm going to assign it to myself. And I'm going to take -- let me just make a quick tangent. I'll go off with a quick tangent and then come back to this slide. The DevOps Center is integrated to GitHub. And for those that perhaps a Salesforce admins that are not familiar with GitHub. You possibly or probably heard about GitHub but may not have used it. So GitHub is a repository for source code, and it takes source code and manages all of the various aspects of sharing a single source of truth for that source code. So it supports things like fetch requests, collaboration, merging of code and the code is organized into what I called branches. So back to the screen here. I'm going to take the default DevOps option, which is to use my work item as a feature branch in GitHub. Now happily, you don't need a lot of knowledge about GitHub to use this product. I mean, it helps a little to understand the concept, I imagine. But you don't need to GitHub expert. I'm going to move now into development. So I put DevOps down for a minute and go and use my typical tooling. So I log into DevOps -- no, I don't, log in the dev pro, I do my flow, I do my -- the clarity of tools. Now if I want to do coding and I do a lot of coding, ladies and gentlemen, I do a lot of coding. I use Visual Studio because that's the go-to for most developers. We recently announced a browser-based version of an IDE that's effectively a mirror a Visual Studio. It's called code builder. So I'll give you a couple of screenshots. I used it to build what I'm doing today actually. Those that do use Visual Studio are going to recognize -- basically recognize it because it's almost identical, actually. And here, I'm writing some code in Code Builder. Again, it's web based. So it's no in store required. It's literally a browser I'm using here. And then I will right click the code to deploy just like Visual Studio, et cetera. So what I've done is deployed code in 2 ways, I just showed you 2 ways. One of them is Code Builder and the other 1 was Flow. But what I haven't done is show you what DevOps is going to do with regard to pushing code through the various stages. Again, let me just pause while I synchronize my other screen here. I back to my list of work items. Now the thing that people were concerned most about change sets was that it didn't tell you what it changed. It was left to you to remember or record what had changed. Well, DevOps Center totally changes that around. So now there's a button down the bottom neck called pool changes. Pool changes will know what has changed in your dev pro Sandbox, and it will literally pull those changes into GitHub for you. So that magic is achieved by setting something in your production system. It's -- here, it's enabled source tracking in Sandboxes, in dev Sandboxes. So with that simple checkbox every dev Sandbox you build now has source tracking enabled. And what DevOps Center is doing, it's pulling those changes in and then integrating them into feature branches into GitHub. So let's take a look at the pipeline. The pipeline now is almost ready to go. Let me just sync my screen again. That's my work item. I'm now going to select it, and I'm going to push it. Now because I've got code, I had some APEX passes, I need to indicate which tests I want to run. Then it's done. So what I've manage to see the user interface. What I managed to do is take something out of a dev -- let's reflect on what I just did. I had changes in dev pro, which traditionally, I would package up as a change set, outbound change set and got dev pro important, but I've done it entirely with the UI? For those people that are GitHub literate, each stage of the feature branch pushing is achieved through what GitHub would call pull requests. And one of the benefits, again, beyond change sets is that you can visualize on GitHub, what is the proposed change or set of changes between stages. So can we see some additions to the APEX passes that are proposing. If I've made some changes, it would highlight them in red. I don't have a lot of time to go into the nitty-gritty, but I'm hoping that the point is made. Final results, I'll go to UAT. I'm now looking at a version of the code that I would traditionally use change sets for a promote, but it's been done in an automated way. And notice how developers writing code, business users writing flow are coordinating their changes in this single UI, okay? So Hany, I hope that was a reasonable explanation. I was a little bit rushed, but I know we've got tons more to cover. Did it make sense?

That was great, Mike. Yes, absolutely. Like, I think it's rather than us kind of talking to slides, sometimes it's easier to see it in action. And that really ties together how you can obviously do what you need to do in a Sandbox by putting some data in there and how you can actually leverage the tool like DevOps Center, where you've got that really sexy, easy-to-use interface where you're actually progressing pipeline. And depending on the person that's pushing out the changes, you can obviously do that in whatever format or whichever tooling you want, whether that's Flow, whether that's Code Builder, Visual Studio or leveraging the different tool sets that you're normally used to like GitHub. So I want to double-click into something there. So obviously, I understand the benefits of replicating production data into Sandbox. That obviously allows us to test changes in a trusted and isolated environment. And I'm leveraging that whole, I guess, integrity of the production data, right? But couple of alarm bells going off in my head in the news there's been a series of data breaches, majority of them kind of stemming through the developer environment, and that's how the data is actually being accessed in terms of customer details and so on and so forth. We've got some changes to the Australian privacy law and the works with some significant fines. How do customers actually go about protecting your organizational data and ensuring that it's secure, especially on the development front?

Hany, that's an excellent question. I'm still getting over you saying that the UI on DevOps Center was sexy. I love that. I'll tell product. I love that. So look, but seriously, that the -- I spent a lot of time talking to customers and security is top of mind with everybody. And I say the follow -- I make the following comments to all of my customers about Sandboxes, okay? Number one, Sandboxes are a mirror of production. So it's very important that you -- if you're interested in security, you get production secure first. So there's an out-of-the-box health check that we recommend customers to run. By mirroring, if you have any vulnerabilities in production in terms of the sharing model, in terms of the password complexity rules, et cetera, and dozens of others. I mean they will be mirrored in Sandboxes as well. And so you're starting behind -- from a position behind therefore anyway, okay? So that's the first thing. Get production sorted out before you did mirroring. But once you have done the mirroring, the other thing about Sandboxes that makes them different from production is often the stakeholders that use Sandboxes, and they're often different as this slide depicts, okay? But everybody focuses on production controlling log-ins, but the fact is that Sandboxes are often accessed by third parties such as contractors or consultants. So you had that additional bonus -- additional requirement for security by virtue of the fact that there are different people logging in. The third thing you would say about Sandboxes is while having a copy of production data is a fantastic theme because it really helps when it comes to training and staging and volume testing, right? The dark side of that is that you've possibly exposed third-party data to those other stakeholders. So our approach to protection of the data in a Sandbox, I know that was a long way to get to it is what we call Data Mask, okay? So I'll show you this in a second, but just let me just skate over the topic. Data Mask allows an admin to identify the fields in the objects of choice that you want to apply various masks across. And we support various ones like anonymization and synonymization and pattern matching and so forth. So I've got an even better slide here, this one here. Well, I'm sorry, this one here, this is a visual of what happened. So at the top is the production data, for example. And by production, you could also say, it's the same as full Sandboxes that are unmasked, okay? So Core Taylor, John Davis, [ Marivet Harris ], et cetera, that's production data, right? But once we've mask them, those first names and surnames and e-mails and salaries have been masked. Now the thing about masking is, you don't want to just jumble things up totally because that's going to really adversely affect testing. So as a developer, I want to expect that e-mails are still e-mails. The integers are still integers, et cetera, right? The patterns are still the same patterns. Because if you just jumble them up randomly, it's going to make my job very difficult, right? So the idea is that perhaps the best thing is that I'll show you what I'm talking about. Hany, if you don't mind -- would it be okay going to just push on and show you.

Yes, absolutely.

Let me just show you. I'll give you a quick look. I think it will make more sense actually. Let me show you an unmasked list view, okay? So let's imagine we have some sensitive data. This might be Financial Services Cloud, whatever. The object doesn't really matter. You can mask every object. But let's imagine we have some sensitive view of particular customers. I think Barak Obama is in there and even Marc Benioff. So you imagine that presenting that to users of a Sandbox might be problematic from a security point of view. And as you mentioned, Hany, the fines and penalties in Australia have become astronomically high. So the risks of having data leak out of your org are very severe and you'll be punished for doing it, okay? So how do we mask this stuff? Well, Data Mask is a managed package. Like all of our sophisticated products, they're designed to be used by admins with very little training, okay? So it's essentially a wizard, which I've taken a few screenshots here. Imagine you want to build a new mask, you would start by selecting the objects you want to mask because not every object has feels that you're even interested in masking, but some do. So for example, I would choose the applicants. I would use an applicant object, for example. And then I would elect on the left-hand side here, let me just synchronize my screen. It would elect from a list of the field in that object, a, which ones you want to mask and b, how you want them mask. So you can see e-mail, the first one is masked from a library of e-mails. Last name has been masked with a library of last names. So that means e-mails remain e-mails, but they're completely fake. They have the format of an e-mail, but they're fake. And the other thing you'll notice on the screen that customers asked is, what does a little exclamation point mean? so the exclamation point is an indicator that those fields have been flagged in the -- in this case, the metadata for this object as PII data, okay? Sensitive or PII data. So it's giving you a hint that they are the fields that one should really consider masking, okay? And the end result, and I did this yesterday, and I'll just show you the end result. Actually, on the left-hand side, I mean the fond is so small, I can't read it. On the left-hand side is the masked version, on the right-hand side is the unmasked version. A little bit half a bit read, okay? But as indicated, it's taken last names and first names and made them [ posable ] but fake, okay? So now as a tester or a developer I just continue writing my Lightning Web Components, my Flows, my automations, my validation rules, none of that's affected. But what I cannot do is steal your valuable data Hany, okay? Because it's useless to me. It's been masked. So in a nutshell, again, that was a quick one, but -- yes.

Yes. No, that was great. And I think that demo just demonstrates how simple it is to use and apply that masking in your Sandbox environment. So just I guess to summarize this all, Data Mask is really helping address data privacy and confidentiality, while letting you develop with the power of the different Salesforce environments. Now meeting compliance, one of the things that it's obviously designed to do is help you meet compliance requirements by protecting your sensitive and your PII data with a 100% native approach. So your data never actually leads the platform. Now a lot of the time, what I see is certain customers using third-party or offshore resources to achieve the same thing. But remember, each time you're doing that, whether you're taking the data off the platform or even offshore you're introducing a degree of risk. The other thing is, obviously, with Data Mask, you can address regulatory controls for sensitive PII private data by still allowing your admins and developers, your business analysts to still securely build compliant apps and customize whether that's using clicks to code or flow but without exposing that regulated and confidential data. And in particular, when you have third-party individuals like vendors or like who are contractors, like partners who have access to your Sandbox, you really don't want to lose your customer data to them. And it doesn't matter whether that's a team of one or whether that's a team of 50, that's a bucket of risk that you're opening yourself up to. So with Data Mask, obviously being native, one of the benefits that you get is we've got evolving road map. So as our product like our Salesforce products evolve and we've got new features coming out. It also follows a similar roadmap. So that way, you're leveraging the proprietary preprocessing to really accelerate creation of secure Sandboxes with the flow-on effect of Data Mask, and you've got that centralized management and reporting to really quickly configure and automate all of that compliance. So you don't have to do extra steps and extra resources against it. And then, in fact, increases productivity. So that enables you to move fast. You don't have to break things while you're using the Sandboxes because you've got all that anonymization that comes with it in terms of the policies that you've set up. And like you saw how Mike demoed, it's really simple and easy to use. So what I'm hearing, Mike, is the solution here is not about 0 data, it because that obviously gets in the way of doing any sort of testing or training but it's really about balance. It's making sure that you're maintaining a really good sample set in terms of the data that you've got in your Sandbox. But you're also -- and you've got that integrity of the data there as well for your development teams. But at the same time, you're using masking, so you're covered in terms of privacy and compliance. So you're still getting the output that you desire? Is that right?

No, I think that's a good summary. I mean having 0 data in a Sandbox, of course, is safe because there's no data to be stolen, but inconvenient, and unproductive because developers then have to seed their own data, and there's a college industry out there of our third-party tools, which will allow you to create data and populate it and that's fine unless data models become complicated, okay? And then at the other end of the scale, you've got 4 Sandboxes, which conveniently mirror everything, but then, of course, that introduces that potential risk of PII. So the happy medium is perhaps a partial or Full sandbox that's been masked, okay? Developers are productive and making applications based on data without wasting time to seeding it. But the data is -- has been masked to protect and to fulfill your obligations to protect PII. So yes, Hany? That's what I would say.

And I guess all of that is sort of premised on the fact of it depends on the different use cases in regards to how you leveraging these different environment, so you might be -- yes, so you might be using a full copy in some instance, but in some instances, you might be using a partial and then doing the masking of both. So it really depends on that.

Yes. The general principle is if you move left to right, where left is the early stages of development. You can support either empty or small seed data populations. And as you move towards production, so through UAT, staging, et cetera, the more benefit you'll achieve from having a fully populated or partially populated Sandbox because that's where you need to support QA and training and integration testing at scale. Yes. So it depends where you are in the pipeline. Yes.

Yes. Going back to that Infinity loop. Awesome. That's -- we're almost at time. So I guess, where to now, you've kind of got a glimpse into some of the tooling that we've described across these 4 tools. So obviously, you can leverage the DevOps Center and Code Builder to build managed teams and changes across your feature development. Leverage Sandbox for secured development and protect your Sandbox data with Data Mask. It's a bit of a mouthful. And what you can really do now in terms of taking action is, like we've mentioned, DevOps Center, and Code Builder are free. So go out, get on to them, see how you can integrate into your teams and how you're actually approaching development at the moment. Just a quick note, DevOps is free and GA. Code Builder is free and is currently in beta testing. So just an FYI on that. And on top of that, what we really encourage you to do is actually review your development practices and see how you're approaching this at the moment. And feel free to reach out to your account team if you want to expert from our team, from the platform team to sit down and chat through some of the ways in terms of how you're leveraging the tool set and what you can do more? So with that, I think, Adeline, are you going to take our audience through some of the resources that they can get their hands on?

Thanks, Hany. Thanks, Mike. Great session. So to wrap guys, we have some resources that we are going to leave with you today. I'm not going to go through this in detail. It's basically under your related content tab. So feel free to access these links and not some of these great data sheets and resources. We do have some time, about 8 minutes to run through some questions. Hany, Mike, we've got quite a lot of great questions that have come through. So maybe I'll start off with Sandboxes. So we've covered a number of products today, but with regards to Sandboxes, in partial copy or full copy, is it possible to set what objects need sample data. So the reason for this question is some objects may be quite big, and we don't need for development, while some might be small and can fit within a smaller size. So do you have any view on that?

Yes. So Sandboxes support templates. So you can nominate which objects will be sampled, okay? Having said that, there's not a lot of fine control over the sampling, okay? You can't, for example, say there's 1,000 here and 5,000 here, but you can indicate which tables you need to be sampled, okay? They called templates. And they're available in both partial and full actually. I'll try to keep the answers brief knowing that there's 20 questions, so...

Yes. We have quite a few to go, here are the next few questions on DevOps Center. The first question being, is it now readily available and the answer is yes. And if it's so, does it need to be installed into each environment to your production, to your Sandboxes, et cetera?

No, it's -- well, a, it's available now; and b, it's installable in one environment, okay? So I installed it into a -- I had 4 Sandboxes under production org, DevOps Center was running in a different org completely. All you need to do is to set this pipeline up. It's essentially a front end to GitHub. And all you need to do is set up the credentials to access all of the Sandboxes in the pipeline. It can actually physically live in any of those orgs. I hope that makes sense. So installed in 1 org and connected to the other orgs.

Great. Because the next question was going to be about connecting to development orgs. Maybe another question on DevOps Center. How are profiles deployed through DevOps? Does it manage field level security?

It detect change, it's like every -- it detects changes to profile and changes to field level security as changes to source. So it will detect that you've made a change, and it will try to push those changes through to the next stage. I guess that's the short answer, okay? It's not specifically -- there's no specific improvements or amendments to profile handling per se, okay? It's just metadata. It detected a change, you'll pull the change and then push it. I know that's possibly an unsatisfactory answer, I don't have a lot of time.

We have quite a number of questions that have come through regarding integration on DevOps Center. People want to know can it be integrated with other VCS apart from GitHub. So for example, GitLab...