Choosing between a multistore architecture or an additional environment
8 min read
The VTEX platform allows creating different store architectures starting from a main account, also known as an account name. You can evolve your main account by adding other account options, such as multistores or additional environments.
This article describes the differences between the multistore and additional environment architectures to help you choose the best one for different scenarios.
For marketplace architectures, you can also Choose between a standard account, franchise account, and Seller Portal or use the Multilevel Omnichannel Inventory configuration.
Multistore arquitecture (store name)
- The VTEX Admin will be the same but will have different store names, which, in turn means different storefronts from the point of view of the end customer.
- Generally, this resource is used when the store has other brands that have similar logistics and payment methods or when a store needs a separate environment for a different public, for example.
- All components are shared between store names: catalog, promotions, sitemap, prices, payment settings, and others. However, they can be segmented for different sales conditions through trade policies and bindings.
Additional environment (account)
- There will be two VTEX environments, each having a main account, completely separate from one another. Also, all the components of both environments will be configured independently, which expands the options for configuring and segmenting sales conditions and shopping experiences.
- The additional environment mentioned in this article is not the same as a franchise account, which shares the catalog with the main account and does not have an independent storefront, even when it operates as a separate VTEX Admin.
Comparing multistore and additional environment architectures
The following table shows how the different architectures are related to the components and features of the VTEX platform.
| Property | Multistore architecture (store names) | Additional environment architecture |
|---|---|---|
| Architecture | A single VTEX Admin (account) with multiple subaccounts (store names). | Two separate VTEX Admin environments (accounts). |
| Segmentation of sales conditions | You can segment applications such as catalog, prices, payments, promotions, and other components through trade policies and bindings. | Because there are two separate environments, with independent configurations, the merchant has more control over segmentation options for sales conditions in different scenarios. |
| Type of team | This is recommended when the same company and the same team manage two or more ecommerce stores with similar catalogs and some of the same items, but want to have separate storefronts for the customers to see each experience with a different brand. | Recommended when different teams within the same company manage different online stores. |
| Storefront | Each store has a different storefront, but all stores are managed through the same VTEX Admin. If you only want to change the website language, without changing the operation of the store, you can use multibinding and catalog internationalization to set that up within the same VTEX environment. Note that this architecture is different from a franchise account; this account doesn't have its own website. Consumers browse directly on the website of the main account, which acts as a marketplace in this case. | Each account manages its own storefronts in separate VTEX Admins and can use all available options for segmenting storefronts. |
| VTEX Admin performance | Linking additional trade policies to the same main account can affect the performance of the VTEX Admin. Platform features can be slowed down because information needs to be updated in each trade policy. Impact on Admin performance is also to be expected if the product catalog is very extensive (more than 2 million products), which increases indexing time. | You can create multiple trade policies for each environment separately. Linking more trade policies to the same main account can affect the performance of the VTEX Admin, which can slow down some platform features. However, since separate environments are used, there is less need to add multiple trade policies. |
| Costs | Even though adding a store name has no extra cost, you still need to request an additional trade policy if you want to differentiate business rules. Learn more about trade policies and segmentation of available settings in How trade policies work. | You need to request an additional environment at the additional cost specified in the VTEX agreement. You may also request a trade policy if you want to segment the settings of each environment for different conditions. Learn more about trade policies and segmentation of available settings in How trade policies work. |
| Operation | When using this type of architecture, you should assess the complexity of managing catalog, promotions, prices, inventory, orders, and payments taking into account the different store names since all the information will be in the same Admin. You can set up catalog internationalization to sell in different countries. | We recommend this architecture when you have operations in two different countries, and you need to separate the languages in the catalog itself to facilitate the operation of teams that also use different languages to communicate. |
| Master Data | Each subaccount has its own Master Data setup, which is independent from the main account. You can use pointing to save the data of the default entities (CL, AD, and OD) from the subaccount in the main account’s Master Data by opening a ticket with Support. Pointing doesn’t migrate data, rather it works as a redirect to allow storing the data of the default entities from the subaccount in the main account. This solution doesn’t apply to custom entities, which are only visible in the account where they were created. Support doesn't handle data migration. We recommend using the Master Data API or the Master Data interface to extract the data from the main account and import it into the subaccount. | Each account will have its own independent Master Data. |
| Information security | All components are shared between the store names, such as catalog, promotions, prices, and payment settings. It's important to take this into account when different teams in the same company have access to the VTEX Admin. For example, Brand A and Brand B are different store names. Employees of Brand B will be able to view the catalog, prices, and orders of Brand A. | The separate environments prevent access by employees from different teams to the information and settings of components such as catalog, promotions, prices, and payments. For example, Brand A and Brand B are different VTEX environments. Employees of Brand B can't view the catalog, prices, and orders of Brand A. |
| License Manager | The same License Manager manages all users. | Each Admin will have its own License Manager, and user management will be separate. |
| Gift card | Subaccounts will have access to the same gift card management, and it will be possible to use the gift cards in different storefronts. | Each Admin will have its own gift card management, and it won't be possible to use a gift card generated in one environment in the other. |
| Marketplace structure | The marketplace structure doesn't apply between different store names since they share catalog, prices, and inventory. | An environment can be a seller in the other environment and vice versa. Products sold on both websites are based on the seller-marketplace relationship. Learn more in Configuring a VTEX marketplace and Configuring a seller on a VTEX marketplace. You can also create franchise accounts to operate as white label sellers since they have different prices, inventories, and logistics. This can be done by requesting an additional environment (if they have some, but not all, items in common in the catalog) or through a franchise account (when the catalogs are completely the same). Learn more in Choosing between standard account, franchise account, and Seller Portal. |
| Sitemap | There will be a single sitemap for the main account, which will be shared between the store names. | Each account has its own independent sitemap. |
| B2B: Catalog | You can't change the unit of measure configured in the catalog for each trade policy. Example: B2B stores sell wholesale, while B2Cs sell in small quantities. The B2B storefront with a centralized catalog will have only one unit in the product page. Depending on your business, you will need to customize the storefront to allow a minimum of units for a given SKU. You can expand the catalog by creating kits, but kits would be created for most products, which basically generates a duplicate of the catalog. | Since the catalogs in each environment are independent, the current multistore environment restrictions don't apply.One of the catalogs can be dedicated to only handle B2B sales. |
| B2B: orderForm settings | When using a multistore architecture, all store names will share the same orderForm settings for Checkout. There are systems that can be integrated to the VTEX Admin and depend on this type of configuration to integrate, such as tax providers. In practice, in a tax provider integration, the orderForm will be called by both B2C and B2B within a multistore environment, which is detrimental for the operation. | You can create a separate orderForm configuration for each environment, and meet the needs of external checkout integrations of a B2B store. |