Description
Discover best practices for smooth Digital Experience deployments. Deploying Digital Experiences can be notoriously difficult, but help is on hand! Join Gearset’s Claudia McPhail in this 30-minute webinar for insights including: how to use different metadata types to deploy changes to your Digital Experience site, how to deploy individual components of your Digital Experience, and much more.
Transcript
You, everyone, for joining us today.
I am just going to get started by introducing myself. My name is Woodem Fowel. I'm one of the SEs at Geerset I've been here somewhere around four years. I actually started in a customer success role and then transitioned into solution engineering later on.
And during my time as a social engineer, I've helped with a lot of implementations, proving out gear sets as a dev ops partner, and I've also, had the opportunity to work with a lot of teams who are standing up new or existing processes for their digital experiences.
If you've ever read it, if you guess it's documentation on digital currencies, you'll notice that I've written it, and what I want to do today is take you through the process of looking at how, we experience digital experiences within the kind of Salesforce landscape and how we can look to manage them and to deploy them effectively.
So the first thing that's worth qualifying here is that, when we talk about experiences, digital experiences experience, cloud, we often use the term interchangeably with communities.
As of spring twenty twenty one, communities were sort of generally rebranded digital experiences, but there's a little bit more complexity to that as well. And we often also find that many of the people that we work with still refer to experienced cloud or communities or digital experience as kind of intangible terms, but there are some subtle differences between them. And I am going to go into that during the presentation today.
One thing that is also worth noting as well that this is kind of a difficult topic. There's lots of moving parts and they can be difficult to deploy and maintain, without fairly extensive experience. And even if you have fairly extensive experience, even then they can be quite difficult to manage. There's branding, permissions, moderation, content rules as a myriad of components that make up a complete portal.
And when we're thinking about making art appointments, the really important thing that I always want to emphasize is it's not an all in one, kind of push. Because of the hierarchical nature of metadata and specifically this particular kind of metadata, when we're experiencing, sorry, deploying a new experience cloud site, It requires more than one step. And if the digital experience doesn't already exist in the target, we have to take that state into account.
If the digital experience already does exist in the target, then there's a slightly different process.
Geyser does support the deployment of new digital experiences as well as incremental updates to digital experiences, but what I'd like to do is to to set an example be a bit too agnostic, with what I'm talking about today, because these, issues by whether or not you're using gear set So we're going to go through today is talking about these, complex deployments, whether they are standing up a new site, or updating an existing one with partial deployments.
So just talk about what those steps are. The first step is obviously to enable experience on the APIs. Now I always say that we should, if we are using communities, digital experiences, experience card, whatever terminology you like to use, that we are using the experience bundle. And to that, we need to enable that in the organizations you're intending to create your, site in and the one you're intending to deploy it to as well. That is step one. Needs to be enabled first of all, and it's not something you can activate via deployment, so it needs to be enabled in the organizations.
Second is to deploy Apex scaffolding. Now this isn't something that we would classically think of as being a community metadata type, but it is very important. There are a lot of, Digital experience specific Apex classes, which need to be present in your organizations in order for subsequent deployments of other digital experience of metadata types to work. So that's your second step.
The third is to deploy experience bundle network and custom sites. These can be deployed together at the same time. And then the fourth step is actually continuous So this will be your kind of point, from this point onwards in your life, you know, updating this site constantly. We will need to customize it with pages, audiences, themes, things going to change, and we don't want to make big bag of points. We want to continuously incrementally update these.
Now the Apex scaffolding, I am starting to linger on for a second. Upon creating your first community in an organization, a variety of supporting Apex pages components classes are automatically generated by Salesforce. This framework concludes code pages to handle user registration, login, password resetting, and so on.
With gear set, it is quite easy to move these Apex classes from organization to organization. You just run comparison, filter Apex classes, Apex components and pages and so on. And what we want to do there is just to make sure that Apex exist in both source and target. Now when we're doing this, and this is especially true if you're not using gear set, you need to make a backup, but it's really, really important that when we're dealing with Apex, especially if this is not normally your area of specialization, that we take a backup first and that we have a way to roll these things back and that we can measure the differences that we are creating this organization before and after that deployment.
And also we need to make sure that we're selectively deploying the Apex we need. I think if anyone's ever had to make a big bank deployment to any organ of SaaS there for ages waiting for all the test run. We know that being as selective as possible is going to really help us here.
And then just on that second point as well, which I think third and my list is the specialized metadata types. So on here, we have listed out, of course, our network, custom site, and experience bundle.
Or if you're not, enabling the experience bundle API yet, you'll be using site dot com and go into that in a second.
These are the three things which are distinctly for your experience, and we will need to be deployed in order to move the site that you've built in your development environment to your testing or to your production environment, these can be deployed together. And the network will contain the community settings, custom site, likewise, and the experience bundle contains the sort of body of the site. If you look at it, it will contain all of the files that make up the pages and such like that actually, have the detail of what you've configured within Salesforce.
Now this is really important, and I just want to talk about this for a second.
Site dot com is what used to be the conventional way to deploy, kind of, communities between organizations, and now we use experience bundles.
This is a really important change, and it may be felt destructive at the time, but this is actually something that's incredibly beneficial because site dot com metastase type was a binary block, which meant that it was not human readable whereas the experience bundle is.
Let me show you here.
I'll skip to slide there. The if you can see in this comparison, this is just extracted from gear set. The binary blob here on the top half of the screen is just a string of letters and numbers. But if we look at the bottom half of the screen, we can see a human readable file, which contains information So here we can see, for example, it's branding set for my help center.
This human readable file means that we can look at these and we can understand exactly what we've done. We can pair them before we make a deployment and we can inform the choice about what we're deploying. But also, crucially, what it means is that we can take these human readable files and we can split them up. And by splitting them up, that means that we can control what we deploy. We can say that instead of taking the entirety of this site and making a huge, very long, very unwieldy deployment to the target, we can split up what we're picking and choosing to deploy, and we can control that. Now this has a couple of different benefits.
And the main one is, of course, that if we work on something collaboratively that we can deploy our own changes without having to worry about our colleagues, and also it makes troubleshooting a lot easier. And also deployments faster. Now geyser has a couple of other things as well. So if you're a geyser user, you'll be familiar with problem analyzers.
When we're choosing, to deploy these custom site, for example, missed data types, you'll often find there are hard coded values embedded in them, like, references to users that exist in one or cannot the other. Gearset has a problem analyzer, which will automatically switch out this value or replace it with the value from the target to make sure that this otherwise undepoitable component can be deployed. You're not using gear set. You just need to make sure that you're taking into account the fact that there may be references to components, which exist in your source, but not your target and you need to make sure that if you're not using if you don't have the benefit of the problem analyzers, you have another way to tackle that.
Send that though. I'm sorry, loads of information at you, but what I think would be most useful is actually to show you a demonstration of this because what I want to show you now is what it actually looks like when we are taking a change, and we are moving it from one organization to the other So with that in mind, what I'm going to do is I'm going to open up a comparison between my, two organizations my development and my testing org. And what we're going to do is we are going to take a, page from one of those organizations, and we're going to deploy it into the other. And we're going to be really specific here is that we're only going to deploy one page as opposed to multiple So if I just share my screen again, you should be able to see in a second.
Apologies, my Zoom's been a little bit temperamental recently.
You should be able to see there we go.
Giftset dot com. So what I'm going to do is I'm going to go ahead and I'm just going to log in, and I'm going to bring up this page here. So once I've logged in to gear set, what I'm going to do is I'm going to show you the organization where I have built my new page and the organization where I'd like to deploy it. If I pop over here into the settings of my developmental organization, we're gonna open up my customer support community My customer support community has a lot going on in it.
I have modified it quite a lot over the years that I've been maintaining it for want of a better word. And it has been updated at various times for his demos, with varying levels of success. So you'll notice here that we have a couple of things going on. We a few pages down here.
I've updated a few recently just to reflect some things that have been happening in the GSA community as well as some of our updates. Those of you who might be interested users for a while will notice that a couple of years ago, we changed our logo. So I've updated the logo, I've updated some new pages, and we recently completed a conference in London, Devil streaming London twenty twenty three. So I've added a page just to talk about that.
This is the page that I'd like to deploy from one organization to the other. I don't want to update all of my other stuff, not least because half of it's half finished and the other half probably needs updating with some new branding and things like that.
So I want to work through this particular use case where I want to deploy a single page and have control over that. So what I'm going to do is I'm going to choose my source This is where I've built my changes. So that's my Claudia dev two organization.
And then I'm going to choose my target, which is going to be my UOT organization.
Now technically, I could rebuild this page in the target organization, but that introduces a variety of risks. If I'm rebuilding it, it means that I'm doing things by hand, which means that I could be doing things wrong. I could be doing this in a slightly different way. So after I've already approved one version, I could be creating a totally different one.
There isn't really a record of me doing that. If I deploy it, then there's a record of me making that diploma, and I can roll it back. If I do it by hand, again, I lose that access And it also means that I need that access in the target to actively update this. And realistically, what we want to do is probably limit the amount of people who can make changes keep in the target environment.
So what I want to do is I do want to make sure that I'm deploying this via the metadata API and in this case via gear set. I'm going to do is I'm going to choose a filter, which is going to make sure that instead of comparing a million different Apex pages or lightning work components, actually just filtering it down to my experience cloud specific my data types, and we're going to compose that comparison here.
So what we do is we download the metadata from development, we download the metadata from UAT, and then we compose this comparison grid And then what we're going to do is we're going to take advantage of the fact that experience bundles are human readable and we're going to break them down. Now this is one point of difference which you'll notice if you use gear set versus anything else, which is that because the experience bundles have in recent years, of course, become human readable. That allows gay set to do something quite unique, which is to take that larger experience bundle that, sort of parent file, if you will, and break it down into sub components in the same way that we might break down an object instead of sub components like fields and validation rules.
We can now do this for experience bundles as well. So let's try this out. If I type in dev ops dreaming London twenty three. There we go.
That will allow me filled up my page, and you'll notice I actually created it earlier today.
There's my last changed on date. You personally change it. That's me, of course. And, if you look over here, I can actually see the individual files.
So here if I expand this We can see the two pieces that make up that one page. So I've got my, two JSON files, so I've got my roots and reviews. We can see here here's the page ID, the dev name, the ID, the label. So I, as a user, can read all of this, and I can say, This is exactly what I wanted to deploy.
I can make them informed choice about it so I can select those components. I can select other things as well. So for example, if I wanted to take a look at the other components, I can find them in here and we can see there no difference between source and target. And if I want to look at that parent item.
So let's say, for example, we want to look at the parent experience bundle. We can see that it's different.
And if we want to examine why it's different, we can look at the individual pages that make it up. So we can see here within these components, what exactly has changed between the source and the target.
Notably, for example, we can see that the logo has changed. There we go. The company logo hasn't been updated, which I told you before. I'm not ready to deploy this change at the moment, so I'm just going to leave it where it is, which is absolutely fine.
I'm going to take the changes that I've selected, and I'm going to deploy them. So again, just to reiterate what I've been able to do here is find the particular page that I wanted to deploy. I can see my own name next to it. I can see the date that I last updated it.
And what I'm going to do is I'm going to take it, and I'm going to deploy into my diarization after I validate it. Now, this is the other thing that's really important when we think about, deploying changes incrementally. It's not just an item of convenience. It's also something which allows us to account for something which is a bit of a gap actually in the way that, these sites can be created.
This is something that I've been working on recently, which is the fact that if you, for example, add a bit of HTML markup to a page in their digital experience and save it, if you've written that in such a way that the tag's missing or it doesn't actually the syntax doesn't make sense, sales force won't prevent you from saving it, and it won't prevent you from publishing that page. What will happen is when you attempt to deploy it, you'll get a very mysterious error message from the target organization. You're going to have to resolve it. And once you resolve that one, there's a second error, that one will come next.
They don't come all at once. It's very frustrating.
We look at it recently as how we can account for this, and actually one of the best ways to do it is once your page is done, you just validate it and then you deploy it. If there is an issue with it, then you can discover it at that point. I also would recommend if you can. I'm just checking things like the tags because once you're all aware that Salesforce will will allow you to save something, which actually can't be deployed. It does make you a little bit more alert to these things and prevents that technical debt building up my case, I've got something pretty simple here. So what I'm going to do is I'm going to say it's new ED twenty three page, and I'm going to add a deployment note So new page, these UAT test.
And then what I'm going to do is I'm going to validate it If you have any issue tracking systems, this is a great time to just link that into an existing board or to our tickets. I've used Jira or, Azure DevOps. My personal preference is Jira. It's what I like to use.
Nissan is also really good, and that's also what we integrate with. And then once you've got all those things, you can go ahead and validate it. What'll happen here is we're going to take that small change and we're going to validate against a target environment. Again, this is much, much, much more efficient.
Than otherwise, you know, trying to deploy the entirety of a community. And again, if anything goes wrong at this point, I have a small error message that I can tackle, which only relates to my piece of work, I can resolve it, and then I can move on.
So we're going to validate those components, so that'll take, hopefully, no more than a couple of seconds, then once that validation comes through, what I can do is I can deploy that change into my target organization, or I can save and deploy it later, or I can combine it with another piece of work and keep bringing those together to make a larger package. Sort of different items I can do, but being able to validate it page by page does give me that freedom. Now you'll notice that we do have some messages reported from Salesforce. These are deployment warnings rather than errors.
They are giving me important information that I'm going to want to go back and review, but it's not something that's going to prevent me from making a successful deployment. I'm going to go back and review these. So gearset will save these messages for me so I can go back and review them later. I can schedule this deployment so I can choose to schedule at a later date and time.
But in this case, I'm going to deploy it into my target.
If I need to roll this back later, I can do guess it will record a record of me doing this and I can roll back out of my organization. Again, if you're not using gear set, this is another really good reason why you should take a backup, because it will allow you to return to an earlier state of your organization if you need to.
So as we wait that to go through, it should take just about the same amount of time if not less as the original validation.
Course because we've pre validated it. We can need quick deploy for this, which is quite good. There we go. We've got our deployment success, and we can see here our deployed metadata item.
And the one thing I want to highlight to you here is it does say that the experience bundle itself has been changed. It doesn't list the interval, the individual page. Now this is because when we're deploying this, the metadata API wants us to deploy the entire community. Gearhead has artificially breaking these down into individual pages and allowing us to update them.
But ultimately what we are deploying into the target is that whole community. So what we're doing is we're stitching in that one page and then redeploying to the target.
Once I have my deployment summary, I can go back and I can, do other things with this. Like, for example, send it to my colleague I can review the report, which will have been sent to me as a PDF, but ultimately what I might want to do is actually just rerun that comparison tackle maybe some of those warnings that are sent to me, like, for example, the fact I need to update the CMS target, the content site or maybe I need to update those logos now that I've updated my page, but you can see how this allows us to slightly more fluidly move with our deployments instead of saving all of our stuff up. Waiting for it to validate and then potentially not being that successful.
I'm gonna move away from gear set now and just talk about a couple of the other things, that are available to you.
But before that, I want to talk about these call apps. The really important thing that I want to leave with you today is that when we're doing our digital experience deployments, we want to make sure that have control over what's being deployed. We want to make sure that we have control over what's being deployed because it's often very common with these experience sites because there's so many moving parts and because there are things that can go wrong when we're building it directly in Salesforce UI. If we get errors, we maybe have quite a broad, selection of, places where they might have come from. So control of what's being deployed allows you to find what's wrong, resolve it, and then move onwards without creating further technical debt.
We want to have accuracy as well. We want to where possible build once and then deploy everywhere. So we want to build it once and then deploy it multiple times If you're using hearsay, you can clone the package and reuse it over and over again, but also using this method of deploying Pay by page means that we know that we have at least one set of accurately validate and avoid metadata that we can reuse over and over again. And it also gives us the speed of validation feedback. If we establish a community or sorry, a experience, even I use the terms constantly interchangeably.
If we establish a digital experience and then we can constantly update it with partial deployments, and that allows us to get our feedback a lot more quickly.
We can get that validation back from our end users. We can make sure that we are producing what we need to. And then Overall, this gives us fluidity, accuracy, and constant, and incremental updates, which is what we want from this constantly evolving platform.
Finally, what I want to leave you with are these supporting resources. These slides will be sent to you. So don't worry about grabbing your phone and trying to scan all the QR codes all at once.
One thing I especially want to call out, the gear set technical articles FAQs feature guides. You are going to find all the to do guides you can possibly want in this section. There's also loads of amazing results and, sorry, events and, items that we're running. And I also really want to highlight the devil's launch pad, which is tall agnostic, which is a learning platform with certifications as well.
You can try all of gear set for free. And one thing that is worth qualifying as well is that you can do what I've done today by signing up a gay set, connecting two of your organizations and just running a comparison in exactly the same way that you've seen me today. You can follow the steps I've shown you in this presentation, just try it out for yourselves.
Gayset isn't a managed package, so you don't have to install anything to organizations. All you need to do is to authorize the connection to those orgs. You can run a comparison and you're good to go.
Thank you. That's everything. We have something like four minutes left. So I'm going to stop talking for a change, and I'm just gonna ask whether there are any questions from the audience.
Yes. Thank you so much, Claudia. That's fantastic. Classic. We do have a couple minutes left for questions, and we've had a question pop up in the Q and A. And this question is from Kenny, and Kenny asks If we select the parent component of experience bundle, will that include all of the add diff delete child components too?
So it works in exactly the same way as if you've ever, deployed a object with Geyset.
What you do is you find the parent parent experience bundle gone aren't talk.
And then once you have the parent experience bundle, there is a button here that allows you to select all of the sub components at once, and that's what you want. And that will click select everything that is a sub component of that community. So if you want to make a big that's what you want to use. Excellent.
That's perfect. I think we have time for one more question, and we've got another question here from, Laura, who says you've shown us a customer support community and how it works with that. Will this also work for the part portal or an LWR site? So, the customer support community is the one that I've chosen because, I think I mentioned my origins were in customer support, but it works equally well with any other community type.
So, if you want to deploy a partner portal as opposed to an LWR side, it works all the same as long as you have got the digital experience, API enabled and source some target, then GISet will see that file, break it down in the way that we've seen before. The consideration with LWR sites is you're bringing in, you know, some more Apex pages and things like that. So, rather than running a comparison of just the experience bundle, you'll want to include those metadata types as well.
Awesome. Thank you so much, Claudia. I think that's just about all we have time for today. So a big thank you to Claudia for running today's session, and thank you to Toby as well for, answering all your to the chat. And finally, a big thank you to all our lovely attendees for joining us and asking all of your questions. If you do have any questions that we didn't get around to, don't forget to pop us a message on the live chat on gearset dot com, and we can answer any questions over there too, as well as in app if you're using gearset at the minute.
So we hope you found today's webinar helpful, and we hope to see you again soon. Thank you so much everyone, and take care.
