Salesforce Storefront Reference Architecture (SFRA) was launched in 2018 by Salesforce. It was launched with a mobile-first optimized UX so that businesses can provide a smooth user experience in the mobile-dominated world. The predecessor to SFRA was SiteGenesis Architecture. SiteGenesis was made for a desktop generation and it doesn’t support a native mobile web experience.

Naturally, SFRA is more advantageous in today’s world. But the difference between the both doesn’t end there. SFRA has more advanced features and I have written about the major difference between SFRA and SiteGenesis here.

Businesses that are using SiteGenesis are looking for a way to migrate to Salesforce SFRA and it is the perfect solution for eCommerce. As experts in Salesforce Commerce Cloud, we advocate hiring a professional agency that can handle your salesforce migration.

Salesforce Storefront Reference Architecture is an ideal solution for both B2B and B2C businesses. If you tick any of the following options, your business will benefit from implementing SFRA solutions. 

• Businesses looking to build new eCommerce sites
• Salesforce Customers probing for new sites
• Salesforce Customers looking for rebranding sites or building regional sites
• Salesforce Customers with sites build on SiteGenesis and looking to redesign their sites.

There are two ways to go about migration from SiteGenesis to SFRA. They are,

1. Leveraging both architectures and the cartridges are separately tread.
2. Employ SFRA completely, redesigning and rebuilding the site.

Our salesforce experts advocate and prefer using the second method of rebuilding the site using a single architecture. Although it might take longer, the entire site will be built uniformly and thereby avoiding site degradation. Converting the site to a single architecture standard is preferred because of the following reasons,

• It provides the user with a standard and coherent experience.
• The development process of two architectures might get complicated due to challenges in integration, resulting in a ‘buggy’ platform.
  Comprehensive testing and quicker Quality Assessment process.
• Avoids multiple coding standards and styles while developing the site, which might be confusing.
• In a standard single architecture, the business user and the consumer can experience a single, simple, and standardised ease of usage

There are some concerns that need to be given importance while implementing the SFRA solution to your site. The first concern is regarding the data available on the old SiteGenesis site. Both the data and the existing site can be used for the SFRA site. During development, a temporary site can be made if both storefronts are in the same environment. However, data must be migrated from one site to another during implementation based on the requirement.

In SiteGenesis, for developing new features and functionalities, the existing code has to be overridden or replaced. But that is not the case in SFRA architecture. In order to promote proper adoption of future updates, SFRA features are extended in the existing code. Therefore, the current features and code from the SiteGenesis storefront have to be reviewed against the SFRA.

The migration process from SiteGenesis architecture to SFRA might take any time from six weeks to six months depending on the complexity of your storefront and its features in it. The process is very delicate and it should be done with the utmost care since the slightest issue can affect the user experience. In this consumer-centric economy, there is nothing more valuable than providing an excellent user experience.

As stated earlier, it is preferable to outsource the SFRA migration process to a professional salesforce partner agency. ASR Tech Group has undertaken 100+ projects around the globe and our people are salesforce certified experts, who deliver the required solutions on time. Contact us Today!

The Storefront Reference Architecture was launched by Salesforce B2C commerce
This offers retailers a starting point for building state-of-the-art shopping experiences faster and easier than before. The user experience has been optimized for mobile devices, making it much more efficient, robust, scalable, and modern than the older SiteGenesis platform.

Salesforce acquired Demandware, originally built on Intershop. Demandware, an upstart, was one of the first companies to offer SAAS (Software-as-a-Service) for eCommerce. As the predecessor of SFRA, the SiteGenesis architecture does not natively support mobile web experiences, has slower performance, and does not offer code extensions.

In this blog, SFRA and SiteGenesis are compared based on the following criteria,

• Business Value Generated
• Architecture

SFRA follows the MVC (Model-View-Controller) architecture. This enables the user to create new features and functionalities without duplicating the templates. The existing models and controllers can be extended to create the required functionalities. All business logic is centralized in the controllers and is removed from the templates.

On the other hand, SiteGenesis is a single code structure. It has a monolithic architecture and therefore in order to add new features to the store, developers have to duplicate the existing templates and make changes to the code. SiteGenesis uses an old software architecture.

Mobile-First design: The sites are developed mobile-first and built from the bottom up into a fully responsive desktop site.

Improved Features:

• SFRA optimized modular design and components make it easier for non-IT business users to build their pages. In other words, Business teams can start building pages with zero IT dependency.
• Improved wireframes and UX including single-page accordion-style checkouts and collapsible summaries.
• Framework that enables fast, easy, and customized websites that are pixel perfect and with an extensibility model to build a unique brand experience.

Following integrations are included with SFRA:

• In-store pickup
• Apple Pay
• Gift Registry
• Wishlist
• Site Map
• Product compare
• GDPR Customer Data Download

Code Customization and Maintainability

Commerce Cloud suggests developers customize the SFRA through overlay cartridges without making changes to the codebase, for proper separation of custom code and easier upgrading in the future. This makes implementing new features, bug fixes, and future upgrades easier as compared to Site Genesis where upgrades are done manually.

Modern Framework: Bootstrap 4, and jQuery frameworks are used to write templates. It provides enhanced page speeds and client-side page performance.

Better UI/UX: SFRA base templates have been created with the best practices backed by research and thousands of audits by Salesforce which analyze the impact of UX on site performance.

Testability: SFRA improves testability by leveraging unit tests for all base functionalities

• Controllers are tested using integration tests (mocha, chai, and request-promise)
• Models are tested with unit tests (mocha, chai, sinon, and proxyquire)
• Views are tested with functional tests (mocha, chai, and webdriver.io)

Administers Development of Modular, Maintainable, and Upgradeable Code
SFRA encourages developers to write less code because functionality can be extended by out-of-the-box and easily configurable components instead of copying code and modifying it.

Automatic Support for CI/CD (Continuous Integration, Continuous Deployment)
CI/CD tools are included for automated deployments and testing
Industry Standard Development Patterns
SFRA supports MVC and middleware patterns which is recommended by the Industry leading app-engines (express.js)

Data Models and Format (JSON)
SFRA supports extensible data models and data transfer in serialized JSON format which is the industry standard.

Amended Class Inheritance and Extensibility Model
SFRA base framework for models and controllers can be untouched with new classes developed as extensions hence avoiding duplication of code which was the norm in Site Genesis.

Easily available Developer Libraries to enhance Storefront Experiences
Popular libraries like Bootstrap, and jQuery structure the layout, component, and user experience on Storefront.

In conclusion, Storefront Reference Architecture is better than SiteGenesis simply for the fact that SiteGenesis was for the previous generation which relied on desktop websites. More than 50% of the traffic generated all over the world is generated through mobile devices and it makes sense to give importance to mobile-first applications.

Not to mention, SFRA is technically and architecturally superior to SiteGenesis as stated above. If you have an eCommerce website that is still running with SiteGenesis, our humble suggestion is to consider migration to SFRA. We have written about migration from SG to SFRA here. It is always better to hire experts in Salesforce for the migration process, for it is better to be safer and sure. Contact ASR Tech Group’s Salesforce Experts today and embrace the future!

Our Client is a public corporation and an independent unit of one of the US State Government. Their goal was to provide the citizens of their state with quality and affordable plans and to reduce the number of residents who have no insurance plans.

Our Client was using Oracle CRM for the day-to-day functioning of the organization. When the citizens contacted them, their Call Center Representative would create a new contact for the citizen every time and log cases for them. Cases were tagged with a bunch of categories and sub-categories to route them through the workflow. This workflow had some challenges that were affecting the overall productivity of the organization. The key challenges were,

High Call Handle Time – The overall call handle time for each user was 21 minutes when our client utilized Oracle CRM. The primary reasons were that the Oracle system was slow to load and use, the contacts had to be created individually and key rules for streamlining data were missing.

Bad Data Quality – There was no integration between the Oracle CRM and their Enrollment system. This led to inconsistencies in customer data and thereby leading to poor data reports and metrics.

High Maintenance and Customization Cost – The primary reason for our client to migrate from Oracle was the cost of customization. They wanted to make a lot of enhancements to Oracle but the cost of customization and maintenance was very high

Our Client was looking for a solution that could solve all the above challenges i.e., something that could streamline their workflow, improve data integrity, and at the same time flexible and customizable. Our experts at ASR Tech Group understood the problem in detail and came to the conclusion that Salesforce Service Cloud would be the perfect solution for their needs. The State mandated to implement the entire solution in Salesforce Gov Cloud.

Our experts at ASR Tech Group had previous experience in migration and implementing Salesforce Service Cloud. With all the ASR’s consultants onboard we created a hybrid agile workflow for the project. The Collaborative Model aims to combine the best of both the models – Waterfall and Agile. It removes the disadvantages of both the models; while bringing together the advantages of both.

The key highlights of Hybrid Agile Methodology is:

• Gather Requirements and Design the solution using the Waterfall methodology
• Develop the solution using Agile Methodology.
• At the end of each sprint perform a demo to the stakeholders. Adjust requirements and development based on the feedback provided during the demo.

The complete project was implemented over a period of 6 months and below are some of the key tasks performed by expert Salesforce consultants in ASR Tech Group.

• Analysis of current Oracle System and functionalities and designing new end-to-end solutions in Salesforce Service Cloud, identifying enhancements to be built.
• Data Migration Strategy for converting Data from Oracle to Salesforce.
• Implementing the Knowledge base for handling calls more efficiently and identity management using SailPoint to improve collaboration.
• Building Integrations between Salesforce and their enrollment system to pull consumer information automatically while creating a case.
• Routed Cases using Case Assignment rules and used process builders to automate the case workflow.
• Built an internal system to store all legacy data from Oracle. Automated reports and dashboards for monitoring operations.
• Conducted training and managed the transition of over 500 users from legacy system to Salesforce.
• The team is currently working on building a CTI Integration with Cisco phone systems for the call center.

• 3 integrations were developed to improve the process workflow.
• 13 minutes average call handling time, reduced from 21 minutes.
• 5000 cases created per day by 540 internal and 200 partner users.