Sitecore Commerce and Multiple Storefronts – Pitfalls

Having multiple storefronts in a Sitecore commerce project is very common. We can create tenants and multiple storefronts. Similarly, we can create multiple catalogs and assign those catalogs to individual storefronts.


Recently working with one of the Sitecore Commerce Projects we had to do this kind of implementation. The project started getting interesting when we came across certain requirements e.g.

  1. Braintree payment merchant credentials will be different for both Storefronts.
  2. Tax rates should be different for both Storefronts
  3. etc

Now if you look at the storefront settings, we can only set these from the content explorer/commerce control panel.


So looking at the documentation of Commerce Engine, we thought Policies are the way to go.

Each deployed role can have different policies and behaviors, which can be specified using a specific Commerce Environment for that role. When a call is made to the Commerce Engine, the call’s header specifies an environment. This environment is used by the engine to control policies and behavior for that call. Specifying a particular environment allows explicit independent control (per role) of functions, such as caching, data storage, integration connections, and so on.

Started with creating multiple policies sets for each environment:

Then we decided to create two environments, each storefront has its own environment and ultimately policies. Creating an environment was quite easy, thanks to wonderful documentation from Sitecore.


But as soon we ended up creating an environment, we figured out there is no way to specify an environment for a Storefront. With a little research, we found out Commerce Engine Connect configuration has a default environment set and that environment is being used regardless of what you want. You should find this file under your Sitecore \App_Config\Include\Y.Commerce.Engine folder.


A little more effort and we came to know, Sitecore Commerce 8.2 used to have an environment field on the Storefront item under Commerce Control Panel. That got missing suspiciously 🙂 And if you want to use that field in 9.1, you can add the field to the template and start using it. The field is picked up by Sitecore but if it is not present, Default Value in CE Connect Config is used.



Well, now the environment issue is resolved. We can see the call from Storefront to CE will pass whatever the environment we set here.

Next step was to create catalogs for each environment:

And again we hit a road bump, and this one was a little more serious. We created two different catalogs selecting the related environments in BizFX. But when we tried to set those Catalogs for each Storefront, we realized that Content Editor will only show one Catalog. And again it’s Commerce Engine Connect Configuration. Content Editor in 9.1, doesn’t respect the environment field when it comes to showing up the Catalogs to attach them to storefronts.

We contacted the Sitecore team and came to know, the data provider is not context-aware and it uses the Default Environment set in CE Connect Config. Thanks to Commerce guru at Sitecore, who suggested to use the same ArtifactStoreId for both environments. So here is what we did to make this happen

  1. We copied the ArtifactStoreId from Global configuration
  2. Used the same Id for both environments
  3. Cleaned the environments
  4. Bootstrapped
  5. Initialized environments
  6. Rebuilt the indexes for master/web and Commerce Catalog

After this, you will notice in Bizfx the catalogs are shown irrespective of the environment you select from the dropdown.

Now we can see both Catalogs in Content Explorer and we can assign them to respected Storefronts.






That’s where we are at the moment. Hopefully no more blockers 🙂


Just want to highlight that we thought of a couple of other solutions as well as part of this journey.

Extend Braintree Policy Per Storefront(shop):

This was the first idea that crossed our minds. We thought to customize the Braintree plugin and based on the shop name decide which part of the policy should be used. This approach is simple and valid as well I would say but not very Robust and Maintainable. Since we might have to separate out certain other policies for example Tax for these two shops.

Make The Data Provider Context Aware: 

This could be very useful in certain other scenarios as well. If the data provider is context aware, it can show/hide the catalogs during depending on the name of the environment. We didn’t go down this path too much, mainly due to time constraints. Hopefully, Sitecore will change this and it will make the lives easier for Commerce Devs.

Leave a Reply