Salesforce Commerce Cloud Multisite － Single Realm vs. Multiple Realm

Understanding Realms and Sites in Salesforce Commerce Cloud

If you are managing multiple brands/websites on Salesforce Commerce Cloud, then you must have encountered a pertinent question – should you utilize multiple realms for developing, configuring, or managing multiple websites, or opt for a single realm for all of them? Finding the correct answer to this question is crucial to improve efficiency and scalability as well as meeting business objectives.

In this blog, we have explained the relationship between realms and sites. We have also outlined the benefits and limitations of using a single realm in comparison to multiple with respect to business objectives.

Before diving deep into the subject, it is important to understand what the terms ‘Realms’ and ‘Sites’ refer to in the context of Salesforce Commerce Cloud.

Realms in Salesforce Commerce Cloud

A realm is a piece of the Salesforce Commerce Cloud that describes the aggregation of service (both software and hardware) that Salesforce provides to its customers. Further, a realm contains instances (application infrastructure) that include web servers, application servers, and database servers. Typically, a realm consists of two groups: a primary instance group (PIG) and a secondary instance group (SIG).

A customer receives 9 instances per realm - 3 instances for staging, testing, and deployment on the PIG and 5 sandbox instances for code development on the SIG. To scale, customers can have up to 47 sandboxes per realm (most of which are available for a fee).  A specific point of delivery (POD) serves the realm, located in a single data center.

Sites in Salesforce Commerce Cloud

Each realm can host as many sites as you want to create. There is no commercial impact on measurement system analysis (MSA). The calculation of the subscription fee depends on gross merchandise value (GMV) sum within a realm. Sites within a realm generally share an admin, development, and operations team. These sites can also share code (via their cartridge path) and business objects like product data, category structure, content library, and customer list. Each site comes with a dedicated inventory module.

The Architecture of Site and Realm

A realm is designed to host multiple sites.

The designs of data objects inside a realm are shareable across all sites and can be local to a specific site. For example:

Shared Objects

• Inventory | Pricing | Products and Product Photography | Custom Code | Customers | Content Assets

Site-specific Objects

• Content Slots | Orders | Promotions | Site Preferences or Configurations

Single Realm vs. Multiple – Which Approach is Better?

Each approach has its pros and cons. Let’s go through the details.

Single Realm

Pros:

1. Leverages same core codebase
2. Easy to maintain
3. Better for small teams

Cons:

1. The customization specific to the site is difficult and hard to maintain.
2. A shared codebase dictates the business requirement. A functionality becomes a priority only if it benefits all brands and not for a specific requirement of an individual brand.
3. Roll-out or release (good or bad) for global code affects all brands.

When to Opt for the Single Realm Approach

The sites within a realm have an inherent relationship with regards to their management – specifically related to operational and administrative tasks such as:

• Data Replication | Code Deployment | User Rights and Administration

Since many objects are shareable across all sites within a realm, a business can streamline merchandising, development, QA, support, and maintenance of their sites within a realm. This streamlining creates significant efficiencies and scalability when compared against solutions that include redundant processes and multiple databases that need synchronization.

Generally, all sites within a realm share a merchandising team or at least reflect a business where the merchandising teams work collaboratively on schedules, processes, and priorities. They also share an admin, development, and operations team. Code, jobs, processes, and functionality needs to be scheduled, prioritized, and configured in such a way to address the needs of all sites within the realm. On the downside, creating individual control at a site level in these areas is nearly impossible within a realm due to inherent sharing, which is architected within the sites in a realm.

Note: This sharing does not limit the differentiation of sites within a realm but does limit the business processes and operating models of the sites within a single realm.

Multiple Realm

Pros:

1. Flexibility in having different code and functionality
2. The global code does not affect all brands – it will only affect the brands in that realm
3. Different business requirements or logic can run independently if the code is for a different brand

Cons:

• A higher infrastructure cost.
• A new STG, QA, PROD instance is required to push code from a lower environment to a production environment.
• New Sandboxes are required since a different set of code is being developed and maintain.

When to Opt for Multiple Realms Approach

Customers who use this approach, in general, have different partners or development teams responsible for the site in each unique realm. These customers also have business teams who can define, prioritize, fund, and execute initiatives independently from each other (this usually means their P&L report into different business units).

Customers who leverage multiple realms benefit from the differentiation in how business processes are defined and managed while benefiting (in an offline manner) from the native compatibility of the Salesforce Commerce Cloud architecture (importing or exporting from real to realm is easy).

How to Work Around Brand Consistency Issues with a Multiple Realm Approach:

• Have an alignment between business units or brands or regions
• Identify and acknowledge organizational constraints or culture which makes alignment difficult to attain

Conclusion

The realm architecture (single or multiple) is a decision that has both financial and operational implications. However, since code and data are transportable between realms, it is possible to re-architect the user of realms over time as the business evolves. For example:

• Allow a site – or a set of sites – to move from a shared realm to one of their own, as business results justify the financial aspect.
• Alternatively, merging site(s) from multiple realms into a single realm is a bit more of a challenge as it likely requires code refactoring.

Regardless of the commercial impact of the multiple realms approach, architecting a single realm solution where multiple realms are needed should be avoided at all costs as it will make it difficult (if not impossible) to achieve the business objectives.

If you’re facing performance issues with your Salesforce Commerce Cloud e-commerce website, then you can implement these 6 easy techniques to make your Salesforce Commerce Cloud website faster, resulting in higher conversion.