Hi Anders

Technically, you can still extend Business Foundation. Although it is a little tedious and requires some boilerplate code. And remember to get caching right.

The major downside is that you don't get a UI OOTB anymore. Besides, BF does not support versioning. So you would not be able to know who made a change.

Do your sites have a site and language branch for each market? Like Company A (site) in Danish (language branch)? Then you could maybe put the market specific properties on the start page type. But this mandates that each market has its own language branch somewhere. A variation of this could be on the Catalog entities, instead of the start page type.

Part 2 😉

You could also make a list property on each start page, containing Market Id and the properties you want to customize. Then you just need to look up the Market Id, and maybe cache it in the request (I wrote about that some time ago).

I suppose such list property can be added to Commerce Catalogs as well, if it fits better there. But you need to test it out for yourself. Those Dojo widgets can be tricky.

Hi Stefan

Thank you for your suggestions.

We are in the early stages of product, so it is evolving rapidly at the moment. Right now, we have 1 language = 1 market. So we have setup some settings pages with blocks specially constructed for different settings. That would be the same as your suggesting of adding them to the Start Page type.

This setup is working, as long as 1 language = 1 market holds. And as long as the editors follow the convention with the settings. But as things evolve, we are looking to introduce English as a shared language across some of the markets, and that will cause problems for us. We are also seeing situations where our current flexibility allows editors to make things that don't quite work as expected. So we are also looking to limit their options to what we as developer require them to fill out :)

But your suggestions have made me think: We have business logic that can set the current market consistently and not based on language. This means that the Current Market Visitor Group Criterion is working correctly. So perhaps we should move our Settings Blocks in behind the Visitor Group functionality in CMS. I think that would allow each market to have settings blocks in different languages but still be Market specific if needed (enforced by Visitor Group).

Thank you for your input.

Regards

Anders

BF has been revamped and now it works considerably well in the admin UI. As Stefan said it does not support versioning, but other than that, works "well enough"

Hi Quan Mai

Thank you for your follow-up.

So it is possible to have a UI in Commerce Manager where you can maintain information stored in BF?

We don't need versioning, so that is not an issue for us.

Can you point to some documentation or blog-post where we can see how to ensure that the UI is setup?

(We haven't tested it yet, but I think we will do that, if we can get the UI to work without manually creating DOJO pages)

Commerce Manager is "dead" with Commerce 13. But you have fully functional UI in EPiServer/Commerce/managecommerce?menu=businessfoundation#/BusinessFoundation/ for most functionalities in Commerce 14 :)  

Thank you for the clarification. I guess I'm not entirely up to date with the naming standard today :)

What you are showing here, is that data modelling (where you define the data structure), or is it data manipulation (where you can create and update addresses)?

It was taken as an example. You can see in the left panel, Meta Class is where you define the data models (classes, including basic fields and relations to other classes), and Meta Class Data is where you actually manipulate data instances of such classes.