3

We are using Experience Cloud with B2B Commerce and are intending on going live very soon. Our marketing department will be handling metadata changes in our components (eg. we have a banner LWC which takes inputs for the text to display, and marketing will make changes to that text), and we're looking for how to sync that between our dev, preproduction and production orgs.

We attempted to retrieve and deploy metadata this way by pulling from our development org and deploying into preproduction, but it created a bit of a mess where the Experience wasn't displaying correctly, was missing our site's custom CSS and so forth even though all indications pointed to it deploying everything without issue.

I notice that in that metadata the components have IDs which on inspection did not match between the two sites (we pulled down the metadata for the sites on both orgs and compared the two prior to the push). Some IDs matched, others did not - is this indicative of a discrepancy between the component version (the component on dev has stuff added to it that hasn't been pushed to preprod yet), or are these site-specific IDs?

All this to say, is there any way we can handle these metadata syncs, and does pushing programmatic changes to a component wipe out the metadata that marketing enters in production?

5
  • is this a first time deployment (meaning other orgs have none of this setup) or just an upgrade/changes deployment? Are you deploying, along with the ExperienceBundle, anything else - ex. CustomSite, Network, LWC, etc? You said, based on what you've seen in trailblazer communities, you're not the only ones - can you share some examples? Sep 29, 2021 at 13:58
  • @KrisGoncalves This would be in reference to an upgrade/changes deployment; when we're ready for the first deployment we'll be wiping everything else out and start from that initial slate of what we push from dev, so everything will have the same setup by the time this is a relevant concern. As for that example, I asked the same question over in the Experience Builder community and someone responded here saying that similar issues: trailhead.salesforce.com/trailblazer-community/feed/… (Buyan's reply). (1/2) Sep 29, 2021 at 14:20
  • (2/2) As for what fully gets deployed, I guess that would depend on what we can do to get the metadata or the programmatic changes over on its own. Looking at changesets, if I add the Network or Experience Bundle, based on what I see in the dependencies, the LWCs are included in both and are not shown as dependencies. Sep 29, 2021 at 14:22
  • I this can help : youtu.be/Z2VHMbrtDrQ?t=128
    – altius_rup
    Oct 5, 2021 at 13:28
  • @altius_rup Unfortunately the video didn't address my concerns, but thank you regardless. Oct 6, 2021 at 11:06

1 Answer 1

0

I have returned with answers! Thank you for any patience and assistance provided. I managed to get everything pushed over via change sets so that the Experiences were on equal footing, pulled down the ExperienceBundles for each, then went from there.

First: Why didn't the IDs of the components match? Answer: This is because they, at the time, were pushed DIRECTLY into the target org from VSCode and NOT through a change set. If your components are pushed through a change set, then the IDs WILL match regardless of any programmatic changes you make to it. This completely alleviated the confusion where all the documentation said that if the source Experience doesn't have a component whose ID is specified, it will be added to the page on the target.

Next: Pushing a component through with a parameter defined in the designer (the metadata) from the source org does not appear overwrite the metadata in the corresponding component in the target org.

Last: what happened to the CSS? No clue there still, but once everything was evened-out, a push of the source org's ExperienceBundle into the target org caused no issues on that front, and I confirmed the overrides were still there. We may have just been so out of sync at that point. If I ever find out the circumstances of this issue, I'll be sure to report back.

Now that we're at a stable position, we know how to go forward. We will checkin pulled-down ExperienceBundle data into source control, and we will likely do a combination of pushing up the ExperienceBundle info from VSCode and using our source control software to manually look over the differences.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.