Description
Salesforce Industries is a set of intricate tooling to help specific verticals in the Salesforce ecosystem. Join Neil Sanghrajka, Practice Director and Vasile Fana, Technical Architect, both at Salesforce, as they talk through these tools and how they can help your deployments.
Topics discussed:
- An introduction to Salesforce Industries
- DevOps process considerations
- Tooling for managing deployments
Learn more:
Transcript
So Salesforce Industries. Let me introduce ourselves first. So my name is Neil Sanguarchka. I am one of the practice directors in, in the UK and Ireland.
I lead a practice of architects. We focus on a couple of industry verticals, energy, utilities, financial services, insurance, health, and public sector. And we focus predominantly on Salesforce industries. So these are the new, industry specific solutions that Salesforce has built.
That's me. So Vasilafana, technical architect at Salesforce. Been with Salesforce for eighteen months. So I'm working in insurance at the moment, but I'm also, should you call it, an expert in, energy and utilities and sales service cloud, experience cloud, the core stuff.
So we're gonna talk about a couple of things. We'll give you a quick introduction into industries.
We'll talk about why DevOps is so important for the industry clouds, talk about some process considerations when using DevOps with our solutions. I'll talk about our components. We'll talk about a couple of tools, that you might be interested in, best practices, and if we have time, q and a. If we don't have time, please feel free to grab us afterwards. We're more than happy to answer any questions.
So Salesforce Industries. So a couple of you might might be aware, Velocity, pretty much the originators of Salesforce Industries, purchased by Salesforce a couple of years ago, and their products have now come into our core product sets.
And we really address different industry clouds. So, the idea is that if, for for example, energy customer comes along, we'll have a solution that covers probably about eighty or ninety percent of their of their requirements. So instead of having a, let's say, a two year program of work, we kind of accelerate it so deployments can typically take a couple of months instead. And so we have a couple of industry specific products. We have a cloud for telecoms, media, health, insurance, financial services, energy utilities, and a couple of others as well. As well as having these industry verticals, we also have a product called OmniStudio.
Now, Omni Studio is essentially a workflow tool. It's not quite the same as Flow. Omni Studio enables you to do things behind the scenes as well, call APIs, retrieve data, enforce a flow for, let's say, a call center. It's really quite powerful. Has anyone here used Omni Studio? Learning.
Learning it. Okay.
Excellent. Brilliant. If you'd like to know more, just find us afterwards. We'll give you a quick demo, but it's really, it's becoming a more prevalent tool.
I'd say right now, we must have about, let's say, ten live implementations in the UK right now across energy, insurance, and a few others.
All of them use OmniStudio.
And as a consequence, we found that there is minimal Apex, hardly any customization. It's really, really interesting. It's quite powerful. And that comes onto our premise.
We wanna maximize configuration, minimize customization. It just becomes a lot easier to maintain these solutions if you really reduce the amount of customization in the product. And managed packages, so industry products are currently managed packages. Over time, that's gonna change, but it's just something to be aware of especially in the DevOps world because you do need to treat these things slightly differently.
Alright, process considerations.
So, why would you wanna use DevOps for industry solutions? Well, firstly, you can actually deploy across our core products, for example, Service Cloud, Sales Cloud, etcetera, with our industry solutions at the same time. And so, you actually maintain the cadence of regular releases. You don't need to deploy things at different times.
It's really, really important if you can do that. You can align deployments to release strategies because we all know whether you want to deploy monthly or daily or if not that, it's really important that you actually have the tooling to support what you wanna do as a business. Quality control, really important. You can build in code scans.
You can automate testing. You can enforce people to do peer reviews as part of these DevOps processes. Of course, you avoid all the fun manual tasks, that everyone likes to do. So instead of spending five hours to do a deployment, you press a button and it goes through.
It's actually a lot a lot easier, faster, seamless.
And we've got increased time to market. Of course, you can deploy configuration, customization a lot faster, but in the industry's world, let's say you have some products that you want to deploy faster. You can do that, new new price models, really, really important. And then, of course, you can use DevOps tooling to, backup, recover configuration and customization.
And I'll tell you a lot of new tools nowadays will do this. It's really quite, quite important.
When we deploy industry solutions, there are multiple managed packages because Omni Studio comes in a single managed package, although that's also moving to our core products.
Insurance Cloud, for example, comes in a managed package, and so you need to make sure that you do it in the right order with the right dependencies. Salesforce Industries, so our industry clouds are deployed as partially deployed as data packs, not entirely metadata. And so, again, not all tools actually support that. That's That's why we're working with people like Gear Sets to actually enable the tools to focus on the on different pieces of our solution.
Of course, all of our components are versions. You wanna make sure that you deploy the right version and the active version as well. And some parts of Salesforce, so for example, change sets, metadata API, only support some aspects of the industry solution. And so, we've got other tools will come onto it like such as IDX, which you can use to deploy industry solutions.
And the other thing is that with industry's products, you need to deploy in the right order and you also need to make sure you're aware of what needs to be activated and not activated. It's really important. It could easily go wrong if you don't do things correctly.
And, yeah, maybe just to to add on, on the idea that you have to manage multiple packages or install multiple multiple packages is, yeah, it it does take a little bit of time and, consider that when you before before you start your project or before you start the installation, and also consider that, that the development strategy you're gonna go ahead with because if you do decide to go with, Scratch Works as your development strategy, then, each Scratch Works would have to push those or create or install those, packages, which take a long time to do. And if you do that multiple times in a week, it kind of adds up. So, I think that that's the consideration. An advised way to do it is do it in a sandbox, and then just or have many sandboxes, sandbox development strategy.
Just maybe touching on just of the, the components that we have. So we know all these components here on the left are part of Salesforce core. So it's Apex classes, Lightning Web Components, flows, fields, profiles, layouts, and everything. So we all know these components and we know how to deploy them.
So I guess we're all used to this idea. But as we move on, we have the OmniSudio components, which are now part of Salesforce core, but you still have to install a package for them. But they will be deployed separately or part of them will be deployed separately. So that adds a little bit of complexity.
So you have to be aware but these are the main components of Omni Studio. So you have OmniScript, like your guided flow, like you'd have your screen flows, inside Salesforce. You can build interactive flows, and they're much more powerful than the flows. Don't say this.
Someone might quote me on this, but I've been using them for a bit now, and they're actually really powerful. So we have flex cards who, which are just a way of visualizing, data on the screen, and you can do it the same way you would, do a lightning web component, so they're really powerful and you can design them however you like. And we have the data rafters and integration procedures. These are two elements that work together to get the data out of the database, and then you feed that to the screen.
We have DocGen, which is, a new feature that Salesforce has for generating documents. So that, again, uses data wrappers to pull data from different sources and then it will generate documents for you. The thing there is you also have to be aware of how you deploy that and how you deploy your document templates and how do you keep that working across your environment. Expression sets again, they're more powerful way of pricing orders inside Salesforce when you use insurance or a package, but also they add a complexity when you deploy them.
And last but not least, these are all the, the velocity stuff that you require to to have your things running, so like your products, price books, attributes, catalogs, and others, like, these are actually data.
But to have everything working correctly, then you still need to deploy this and you'd probably need to deploy them first before you deploy other stuff, just to keep things running.
But that's about it in a nutshell for the Salesforce and Salesforce Industries components, and we'll look at how do we install these managed packages, as we're talking about them, what does it actually take, how to do it right, because sometimes it's a nightmare if you don't plan and these are based on experience. So to install the package, you would have to review the configuration stuff.
Consideration, so, like, if you need some sort of settings enabled, like advanced, currency or other stuff in your system, you'd want to see if you'd need those, if that would work for a business before you actually, go ahead with the installation and deciding to to use the package.
You'd have to have a plan and make sure that, you execute it before you can actually start build. And then you also have pre installation steps, so you have to make sure you you execute all those steps appropriately, otherwise things might not work. Then you install the package and there then there are post installation steps which also need to be executed accurately so things work afterwards.
After we have, installed the packages, we also need to maintain them. This is not, they are not automatically upgraded at the moment. That is coming with the next release, so you could opt in for your packages to be upgraded automatically.
Should we yeah.
So a couple of things there. So you'd have to look for the notes to make sure that that upgrades or updates actually brings the features that you need. And if you do wanna get those, then you will have to, enable or upgrade that package.
Don't do it directly in, in your main development environment, so do it in a sandbox, just saves everyone the hassle if something doesn't work or breaks and then you could, once you've tested, verified all your stuff, then you can, you can do that in your environments.
And that is, how do we store and manage our components. And talking about the tooling, well, how do we do this, deployment when you have, the Salesforce Industries components installed, as well as Salesforce Core, as well as Omni Studio?
Well, you can do it manually. It's very painful, is you have to work with a lot of tools. So, you have IDX Workbench, which is one tool that is, it's got a UI and it helps you to pull all the components that you actually need to deploy, and it will also respect the dependencies, and it will do, the deployment. Then you could have a version control system for backup. You could use change sets, but change sets don't support all the components.
Then you have Workbench if you want to do a bit more hands on XML stuff, and then you have Versus Code and SFDX which you could use with the CLI to actually pull changes from one system, push them into another, all that kind of stuff.
On the automated side, well, we have DevOps Center, pretty new, a dozen support Salesforce industries or all Salesforce industries components, I think, at the moment.
But, it's really nice to have an automation, or automated deployment tool as part of Salesforce. We also have partnered tools, right, like Gearset and Capato.
They have a much better UI and interact and can integrate with many third party tools as well. We have version control system, which we must put our changes into so they then get deployed.
IDX build tool is also known as Velocity build tool. So this is the tool that you would need to move Velocity stuff. So if you go ahead the custom way to build your DevOps solution, then you would have to use IDX build tool, which basically takes files from one word and then moves them into another work and then activates them. The activation generates, lining web components for those files.
Well, that's very important. So that's the tool that you would need to use. And then, last but not least, automation server. Otherwise, you'd have a version control system and you would not be able to automatically deploy things into other systems.
You'd not run, automation tests and all that kind of stuff. So, we have quite a bit of tools to help us, to do DevOps and do it well, which is, is very nice to have when you when you do. Alright. So we're just gonna have a quick look at so this is the IDX workbench in a nutshell.
So some of you might have seen it. If not, then you would have a repository or a source work. It could be any work. It could be a demo work, and you could get this demo works with a lot of these components preinstalled.
So So if you wanna play around with Omni Studio or any cloud, in fact, you could get a demo work. And then the way if you if you want to then move some of those changes into your actual work or customer work, then you would just choose a source and a target. And your project is basically where you select what metadata do you wanna deploy and whether you wanna include dependencies or not. So then those changes are migrated nicely into your target work.
You also can, configure a repository. So in case you want to commit your changes and then push them with an automation server, you can do that as well and this would give you a nice UI. There are a couple of other features like, process profiler, which allows you to verify the performance of your components, like, you would, let's say, you'd investigate why certain things take a long time in specific processes, then that's a great way of actually viewing how many seconds, milliseconds each of your process parts take. So that's nice.
Then you have some comparison thing, like, there are other tools that you can compare files, but that's a good one. And then Test Console, which just allows you to run tests for all the Omni Studio stuff. Okay. And, there's another, the other tool that I mentioned, IDX Build Tool, so also known as Velocity Build Tool.
So this tool has been built to allow you to move data packs from one system to another. It's a command line driven tool, so, your automation server can use to move those, JSON files from one system to another. So bear that in mind if you do go custom way to build your DevOps solution, then you will need to use this. To see this in, working solution, so this is a very simple graph.
You can make it a lot more complex than this, of course, but just for the purpose of the conversation.
You could have a dev sandbox there where you could have many. And then, this is if you go with a custom solution for your DevOps.
Then you could have IDX Workbench, in the from so to help you move changes from your dev sandbox into a branch.
And that branch is your feature branch. And then those changes will make it into, let's say, after you review them, and hopefully you do that, to all the changes, then they will make it into the main or, develop branch, and then they will be automatically deployed using Salesforce CLI and IDX build tool into your target environments.
So that's how you would use these components if you don't have a third party solution, which would save you all this stuff, but you also have to maintain, which is not the most fun thing, to be honest.
If we look at, more considerations Yeah.
So, now, of course, the Salesforce, we do provide some pretty good tools. Most of them will cover of course, they all cover the the core products. Not all of them cover the full features of industries yet. And so, of course, they are free.
They do come with the products, and they do enable deployments to a certain point. But of course, if we're looking at third party tools, at the moment, they can actually do a lot of extra things. User interface, as you've seen on the industry side, we do have command line interface and various various other things. So we found that products like Gearset and Capado have an easy to use user interface.
They do support Salesforce and Salesforce Industries components. So as an example, we've been working with Gearset recently to actually enable that, which is really, really key. We touched upon automation server, of course, integration with different version control systems.
And one of the things that we we do like about some of their third party tools, they will integrate with other solutions. For example, Jira, saw one that integrated Lucidchart the other day. And so having those additional tools really does help to automate the entire end to end process.
Best practices. Right.
So what we found, certainly from all the projects that we've delivered over the past many, many years, number one, plan your DevOps strategy early, and we've seen quite a few customers recently where they haven't given due consideration for it, and it's really important we get this right at the beginning. Of course, you can change it and introduce new tools throughout the process if you need, but having a strategy early is really key to all of this. Clear development guidelines, naming conventions, of course, always important. Certainly within in within industries, we encourage people to use a standard data model as much as possible.
That just avoids unnecessary customization. It avoids complications when performing upgrades, anything like that. So it's just a lot easier if we try and stick to an out of the box solution, committing only the changes you make and not not everything. I know, for silly, you had a couple of views on this one.
Absolutely. It just makes everyone's life easier, I guess, when you just commit the changes you've made because then the the peer review process, it's much easier. If anyone has a question and they could come and ask you why you've committed specific things and then you have an answer where if you just commit things for the sake of, let's say, you've thought is a good dependency to commit, then, yeah, you won't be able to explain that one and it might not be needed in the target system. So, yeah.
Absolutely. Selecting the correct tools, of course, really, really important and these can change over time. As long as you've got the the basic tools in place to enable what you want to happen, that's quite important. And then the final one, we found this certainly within our team and and all the customers we worked with, ensure everyone has the right skill set or that they're suitably skilled. And so there was an investment in training. There's an investment in making sure that even if you train people on day one that you regularly revisit to make sure that they're up to date with new features that are coming out, best practices, lessons learned from other programs as well. I'll say this is this is certainly quite key and one of our top priorities at the moment.
Absolutely. Yeah. Get getting your DevOps strategy early, will definitely speed up the process. And I guess in this strategy, always think about the skills that you have in house or the skills that you you need to to grow or add or upskill people because it could take a steep learning curve, to be honest, for some people who never use DevOps.
So you would want to do that early. And if you do it at the start of the project and have a proper DevOps process, then you don't end up in situations where you are in UAT. And you don't know what you've built or what needs to move to production because there's no clear track of those changes and then you spend a lot more time to actually move things around. So really good stuff.
And then, oh, yeah, another another point maybe on naming conventions.
So what I like to to say about that is make sure you keep your, work clean and you have clear guidelines and you use exactly what's out of the box. You don't customize it too much, but at least you have, a clear way of building things and keeping things aligned because the last thing you want to do is, and and this is a good example, when you change companies as well and you you think that you will always think that you'll find a nice environment to just pop in and do changes, everything works great. But if that team hasn't done their housekeeping work, didn't have, clear guidelines, then it will be a complete mess. So it's really important to have that for your benefit and everyone's else benefit and the business.
Yeah. That that's about it, I think.
Cool. Well, thank you very much for listening to us. Any questions, please find us afterwards. We're more than happy to, to answer anything.
