SFCC Myths Debunked

My name is Yaroslav; I’ve been in development for nine years, with more than one year as a Web Development Lead at Astound Commerce. If you are a developer and are hesitant whether to work with Salesforce Commerce Cloud (SFCC) or not, this article is just what you need. We’ll try to debunk some heated rumors about this platform

Ecommerce is currently growing at a high pace and offers a vast abundance of commerce solutions, but not all of them can boast of flexible scalability and proper control over the online commerce process.

Choosing the right platform can increase the growth rate of sales across all online commerce channels. However, sometimes the client may have doubts about a particular platform because they found negative reviews on the internet and do not know that they are just myths.

Myth #1: SFCC is an obsolete platform, and modern businesses don't use it.

Frankly, it is one of my favorite legends. Just imagine for a second that more than 17 years have passed since SFCC (at that time Demandware) came into existence. Over those years, the platform has accumulated enough experience in the ecommerce marketplace, based on ever-evolving customer demands and requirements, that it earned the B2C and B2B Commerce Suite leadership position at the end of 2020, according to Forrester Research*, an independent research firm. SFCC was scored the highest in terms of criteria such as artificial intelligence and machine learning ecosystem, product vision and customer capabilities scaling, order management, and revenue leveraging.

Giant brands like Under Armour, Puma, Adidas, Calvin Klein, L’Oreal, Philipp Plein, and Boohoo have already chosen and are using Salesforce Commerce Cloud, to give just a few examples of SFCC customers.

For Under Armour, for example, the SFCC platform set a whole new standard for mobile shopping. Reduced page download times resulted in a 65 percent reduction in bounce rate, and the introduction of a user-friendly progressive web app (PWA)** interface improved site navigation and tripled the click-through rate.

Salesforce Commerce Cloud’s innovative solutions enable companies to personalize the consumer experience and thus drive sales growth, launch advertising campaigns, use traffic splitting and A/B testing without technical support. Einstein artificial intelligence, built into the platform, provides personalized product recommendations to all site visitors, collects data on customers, and orders and displays items that are frequently purchased together.

Salesforce also provides a number of related customer relationship management system (CRM) and marketing software-as-a-service (SaaS) services that can be integrated into a customer’s solution set. This is where the next common myth about SFCC is rooted.

Myth #2: SaaS solution is not the best choice for running an online business

Salesforce Commerce Cloud is driven by a scalable cloud-based SaaS solution, which often scares away potential customers due to rumors about the risk of data loss. Let’s take a look at the benefits and debunk the myth keeping brands from migrating to the platform.

As a cloud-based product, this system is able to handle huge demand and traffic spikes without prior planning. In the event of a sudden spike in demand, the platform is scaled up in the background without any intervention. The SaaS model is device-independent because it uses cloud technology, providing access to functionality through a web-based application. Consequently, neither partial or complete device replacement nor outages affect your data, because it is kept in a cloud storage.

Instead of buying an expensive software license, users subscribe to a cloud solution as a service. This option of implementation and maintenance is less expensive than the alternative, is open source, and lowers the entry barrier for development and project start-up, especially in the initial stages. Today, both small and large entities are increasingly choosing SaaS because of its flexibility and innovation.

An IBM blog in 2014 predicted that more and more companies would take a SaaS-focused approach to business applications, and it worked, especially in ecommerce.

Another benefit is “seamless” updates, as Salesforce continuously introduces and expands many new features in the background. These are available through the administration panel, often with little or no technical intervention on your part. Consequently, the product owner can focus on business strategy and not constantly worry about the platform–a huge benefit for the customer because technical maintenance and uptime issues are the software provider’s responsibility.

Myth #3: SFCC cannot compete in the same market as Shopify and Magento

Salesforce Commerce Cloud is one of the most in-demand and highly regarded online commerce platforms and has been ranked in the top 15 for the past few years, according to Gartner’s research on the digital market segment***.

The platform was named a Leader in the Gartner’s Magic Quadrant Digital Commerce**** report for 2020, having completed more than two trillion B2B and B2C transactions and allowing customers to purchase goods and services online and in self-service mode.

According to this Gartner report, “leaders” in the space demonstrate the following capabilities:

  1. Depth of solutions and scale of commercial opportunities (for B2C and B2B)
  2. Support for large transaction volumes and high revenue levels
  3. High-quality sales and support services both directly and through an ecosystem of applications, services, and certified integration partners
  4. Integration of third-party services compatible with the core trading platform
  5. Cutting-edge innovation, typically in the form of technological updates to trading platforms and product functionality, investments inside and outside of core digital trading platforms, and customer programs enhancing the customers’ ability to succeed 
  6. Distinguished by financial, technical, and organizational viability; continuous development, and customer assessments; often set a competitive benchmark

Myth #4: Ecommerce will not be in demand after the pandemic (shopping habits)

With the advent of COVID-19, the way consumers make retail purchases changed. The standard user experience started transforming immediately, with the usual shopping mall experience changing to online shopping as one of the most important alternatives to the old purchasing format. For example, according to Salesforce’s first-quarter shopping index, in April 2021, the number of unique customers nearly doubled (up 40 percent) vs. the previous year. BOPIS (buy online, pick up in-store) revenue was 27 percent up in the first quarter. In July, Salesforce released its Buying Index for the second quarter of 2020, showing that the number of online shoppers remained consistently high, even though offline locations had gradually resumed operations by that time.

According to another report by Activate Consulting, last year, the volume of global ecommerce has already reached $3.4 trillion, and its further rapid growth is predicted, so by 2024, the world’s ecommerce will grow from $3.4 trillion to $6.5 trillion.

This tremendous momentum was made possible by global isolation. The fact that this was the first purchase online for many consumers and that it was made during the quarantine period is surprising and astounding.

Myth #5: The expert community is poorly represented in the ecommerce services market

This may have been true 10-15 years ago, but now given SFCC’s leading position in the ecommerce market, the number of certified professionals and developers who are just starting their journey is also growing. This is an area where this platform really excels, because there are hundreds of skilled agencies and a huge number of certified and experienced developers.

The SFCC, on its TRAILHEAD platform, provides anyone with access to documentation, the opportunity to prepare for certification, and the opportunity to join a community that will help explore the intricacies of the platform.

I will also share a few useful links:

  1. Documentation – https://documentation.b2c.commercecloud.salesforce.com/DOC1/index.jsp 
  2. Developer center – developer.commercecloud.com/s
  3. Github – github.com/SalesforceCommerceCloud
  4. Salesforce AppExchange – appexchange.salesforce.com

To sum up

Salesforce Commerce Cloud is a product that is improving, getting smarter, and giving developers flexibility on an ongoing basis. A variety of templates and commercial APIs for creating customized implementations and a community of more than 2.3 million people will never leave you alone with a difficult task.

Consequently, if you chose SFCC as your platform for implementing both B2C and B2B ecommerce solutions, you made a smart move.

* Forrester Research is an independent research and advisory firm founded in 1983 providing its clients with data on the impact of information technology on businesses and customers. Reports are based on annual surveys of more than 675,000 consumers, business and technology leaders worldwide; rigorous and objective methodologies, including Forrester Wave™ assessments.

** PWA (progressive web app) is a technology in web development that visually and functionally transforms a website into an app. A mobile app in the browser.

*** Gartner is a research and consulting firm specialized in information technology markets. It is best known for introducing the concept of ERP and for its regular “Magic Quadrant” and “HYPE Cycle” research reports. Gartner research is regularly featured in such publications as the Financial Times, The Wall Street Journal, The New York Times, Der Spiegel, The Register and ZDNet. Along with IDC and Forrester, it is considered a key researcher of IT markets.

**** A market segment analysis report, which includes an image with the distribution of suppliers by specified quadrants. Every year, the company produces several dozen “magic quadrants” on a regular basis.












Headless for Storefront

Ivan Khartov has been working as a front-end developer at Astound Commerce for four years and in the overall sphere of front-end development for around nine years. In his article, Ivan will introduce you to the core differences between traditional Salesforce Reference Architecture (SFRA) and headless architecture, the benefits and key advantages of headless implementation, and the necessary knowledge to implement a storefront head.

Before proceeding, it is important to understand the definition of storefront in the framework of headless architecture. Storefront is an ecommerce service, allowing brands to advertise their products and generate transactions. In traditional architecture, an ecommerce storefront is inseparable from the platform; changes cannot be made without affecting the back-end. In other words, a change made on the front-end also requires a change to be made on the back-end and vice versa. The back and forth consultation is done to ensure a well-functioning service in accordance with the product requirements. From the perspective of a front-end developer, this creates certain challenges and restrictions, not allowing one to use all the available modern solutions.

A storefront for headless commerce is a self-contained web storefront that’s completely separate from the ecommerce platform and any other back-end application. The independence of a headless storefront provides more flexible and innovative solutions, where all communication with the back-end happens via API.

Table of Contents

Storefront in Traditional and Headless Architecture

Currently, there are three main approaches during solutions development: commerce-led, experience-led, and API-led. API-led can also be referred to as “the new way” or “headless ecommerce.”

The commerce-led model provides solutions for effective order management; however, it cannot react quickly to any dynamic changes or to consumer behavior. Aside from that, the inner interfaces’ functions are limited, preventing improved experience with the content.

The experience-led model separates the platform from the presentational layer. In this case, the content management system maintains accessibility, playing a major role. Both of these approaches cause limitations. Since the back-end and front-end are bound to each other, implementing any changes in your solution is difficult and slow. This limits opportunities and causes unnecessary challenges for any upcoming initiatives.

The API-led model, or headless model, allows the ecommerce platform and the content management system to cooperate with the user interface, or storefront, via API. This grants far more flexibility and freedom to implement innovative solutions faster and with higher quality.

When directly comparing the traditional storefront to the headless storefront, Ivan says there are three key differences:

Core Technologies

Now that we’ve discovered the key differences between traditional and headless ecommerce, we can focus on the technologies required for implementation. The structure of the technological stack for the development of a new product might add additional work within the frame due to the abundance of factors and variables, which should be considered.

Here’s an overview of the three main frameworks: React, Vue.js, and Angular. The graph below displays demand for these frameworks over a five year span, as reported by Google Trends.

It is preferable to work with the framework you are already familiar with. If you are not familiar with any of them, you could select one by observing the information in the diagram below. From the presented chart, it is apparent that the preference for React has been greater than Angular; however, Vue.js is gaining popularity.

React has the lightest production size, which shall increase the speed of any solution; Angular weights the most since it is a robust framework by itself, while React is simply a library. Vue.js is balanced between the two (and proves to be quite easy to learn) while providing the benefits of Angular, which is far more challenging to adapt to.

There is no “correct” option here; however, it is important to consider the indicated data. Select the framework you are most comfortable with, yet if you are unfamiliar with any, begin with the easiest. Even though Angular is a fully functional framework, it is quite difficult when Vue.js is easier to understand and yields the same useful tools.

Keeping the following abbreviations in mind will also be helpful for front-end development. What is SPA, PWA, CSR, or SSR?

How an SPA Works

A single-page application is a site with a page that updates dynamically instead of downloading the data from the server. In such cases, all the necessary code for the web application (HTML, CSS, JS) needs to be uploaded once. After that, all the contents and elements of the web application update automatically, without any further requirements to restart the browser. This allows a faster load of the web application, reducing the traffic between the server and the browser. Facebook, LinkedIn, Netflix, and Gmail are all examples of a good SPA.

How a PWA Works

A Progressive Web App is more like a set of guidelines and checklists, rather than a specific architecture. A PWA is famous for and differs from a SPA via the following characteristics:

How CSR Works

Among these basic concepts, it is also important to understand the rendering process. Client-side rendering (CSR) is the rendering of specific pages on the browser with the use of JavaScript (JS). All logic, data, templates, and routing are generated on the client side, not on the server (SPA). The avoidance of frequent updates of the page, compared to regular websites, and faster download of visual elements after the initial load are definitely advantageous here. However, the initial slow load, negative influence on SEO, and higher requirements for memory capacity on the users’ devices prove to be a disadvantage.

How SSR Works

Server-side rendering (SSR) generates the entire HTML for the page on the server in response to the navigation. This allows smoother processing of the templates and contents for the client. Benefits include a faster initial loading time of the page compared to SPA or CSR applications, no negative effects on SEO, and elimination of additional loading requests that occur during the initial load of the page to the server. However, the higher requirement of resources during each page’s load is a drawback.

In the context of developing ecommerce storefront solutions connected to SEO and the interface, it is necessary to use SSR. But what can be done if the application (SPA) is written on React or Vue and only uses CSR? In such a case, the universal SSR framework comes in handy.

Universal SSR Framework

What is a universal JS framework? Nuxt and Next are described as the “universal JS frameworks,” meaning they simply support universal rendering.

Nuxt is a framework for universal applications that is based on Vue. It handles all of the configurations to set up a server-side rendered Vue application.

Next does what Nuxt does, but for React applications. It is a framework for building universal applications that leverage React.

So what about Nest? As it turns out, Nest is where we see a departure. Nest is not an analog of Next and Nuxt at all. As noted above, those two technologies are focused on bringing the front-end server side. Moreover, they support specific front-end frameworks, Vue and React, respectively. The goal of Nest is to help you rapidly develop your back-end. It supports both JavaScript and TypeScript.

Instead of an out-of-the-box node application, Nest introduces annotations, best practices folder structures, and associated concepts. All additions that you may be familiar with if you’ve used technologies like Spring for Java.

To summarize:

But what is TypeScript? It’s a programming language developed and maintained by Microsoft and functions as an extension of JavaScript options. Knowing TypeScript gives an advantage because it is such a powerful language and provides faster reactions and flexibility in the framework; typisation also helps create better code documentation, allowing for a higher quality output overall. Some frameworks, such as Angular or Next, already use it, though it is recommended that TypeScript is used in general as well.

The next tool, which is very useful for successful headless implementation, is Storybook, the tool that allows you to work without a backend. It will enable you to test and document every required component. Storybook will document all changes as they are made, allowing for far smoother cooperation between front-end and back-end developers, quality assurance engineers, and other teams. The tool also allows you to add any preferred add-ons, for example, the one on accessibility which runs on specific parameters and roles, detecting any errors or sections requiring adjustments. This will allow you to build a site entirely independent from the back-end.

Design Methodology

The main concept is that the storefront design and all its components can be dissected down to atomic bases. In this case, an atom is a button; a molecule is a button with either a label or an animation; an organism is a larger body of the page, either a header, while the menu is a completely separate organism.

What are the benefits of Atomic Design? Atomic Design can require a lot more thought and planning, but it’s often worth the extra effort. Here are some of the benefits of using this type of design:

This tactic and approach work optimally with Storybook, especially when constructing a headless storefront. Overall, this results in a more efficient timeline, where more effort is invested in improving the front-end content, and you as a developer are freer to make all the necessary changes right away. Sometimes it can take weeks to see the effect of your work on the content, which could also affect motivation. With headless architecture and the tools and approaches mentioned above, you can develop all sorts of solutions comfortably and in the way you prefer.

Final Considerations

When should you consider going headless? The headless approach requires specific changes. It is important to answer the following questions before taking action:

Once you have established solid answers to the above questions, you may then consider going headless, finding more adaptable and flexible frameworks for your front-end developers, benefitting the performance of your solutions, and providing higher quality products to the consumers.

Inside Our QA Team

Whenever you look at a job vacancy, there is a regular list of responsibilities, requirements, and a few lines of what it will be like to work in this particular company. Undoubtedly, that’s what the vacancy description is for — to give the general understanding of the job. To receive more information on how your work will be organized, you’ll have to get to the interview stage of the hiring process.

This article, however, will provide you with an inside look at what Astound’s Quality Assurance team is like, and what roles and testing directions we have. Besides, you will learn about the experience of a QA specialist at Astound firsthand — from our team members. Read on!

First off, here is the helicopter view of the team and their experience:

And here’s the review of the QA Department’s structure. Below, we’ll examine its main elements.

Let’s start with the Testing Management team. QA Functional Managers help the team members grow and develop. They are responsible for putting together a Project Team, which is usually done not only considering the skills, experience and personality of each team member, but also their preferences.

Our QA Trainer organizes external and internal training activities — workshops, meetups, bootcamps. The latest internal one was on analyzing requirements. Plus, the Trainer also prepares our colleagues for ISTQB certification.

QA Lead sets up the processes within the QA Project Team, conducts communication with the PM, the client, and all the other leads on the project. Such expert manages the team, their motivation and also the QA part of the project — optimizes the processes and creates artifacts. The Lead is also there to support you in case you’re stuck with a particularly hard task.

QA Technical Practice Leads (TPLs) provide all kinds of technical support. They mentor other team members — those that aren’t actually Leads (Middle+ and Senior specialists), but only take a leading role on this particular project. TPLs themselves work as Leads on a project from time to time not to lose technical expertise.

Another part of TPLs’ work is their discussion with QA Leads on the experience, challenges and communication cases on projects. These usually result in the new best practices to be used on the next projects. TPLs also conduct training activities, they optimize the work of the department — suggest new approaches and templates.

QA Audit is performed by TPLs whenever there is a request from an FM or a project team. The main purpose is to analyze the QA work on a particular project and provide the list of must-have action items or things to improve that can be applied either on this project or in the future ones. There is a specific audit procedure with a list of questions, but it’s flexible, new questions can be added if necessary. It was thanks to the QA audits that the team was able to grow the customer satisfaction rating up to 9,5 out of 10.

QA as a Service implies that our QA Team doesn’t participate in the project from the start. Instead, they are hired to provide a QA service on a certain phase. An example of that would be User Acceptance Testing. It’s performed in the pre-production phase (acceptance of the project). Our team write the UAT procedure, approve it with the client and then provide the support. The client goes on to test the product from the business side.

As for our different testing directions, it’s better to hear about them from our QA team members. You’ll read their stories and learn what fascinates them about the specific testing practice they specialize in: Manual, Automation, Accessibility, Security and Performance testing.

Manual Testing

Yuriy Logoyda joined Astound as a Junior specialist with minimum experience in 2011 and grew to the position of a manual QA Lead in just 5 years.

He states that while nowadays people are considering automation to be a necessary part of the QA process for all projects, the smart use of all testing types is the right choice.

“For small projects the use of automation is not reasonable, while manual testing can provide more benefits. Due to the constant change in technologies and top-selling sites dictating the rules of success, the life of the site redesign period is really short. Manual QA that is quickly adaptive to the new changes is the right choice to perform fast testing of new features.”

Yuriy also notes that the human factor of manual testing allows finding things that could be missed in the process of design planning.

“Manual QA Engineers can act as real customers — we can share our opinion, provide arguments — and that helps our clients to come up with the best solutions and improve their sales.”

Test Automation

Georgi Georgiev had been interested in automation ever since he joined the company as a Junior manual QA engineer. Having grown to a Middle position, he discussed his willingness to become a TA Engineer with the Manager, who supported him and assigned him a coach. Step by step, with the help of the coach, he studied the basics of Test Automation, and then became first a Junior, and later — a Middle TA engineer. Of course, his journey isn’t over and there is much more to learn and explore.

Georgi has shared why he enjoys working in Test Automation:
“What I love about automation is that programming and testing are intertwined — I am looking for the middle ground between what I want to do as a QA specialist and what’s best to do as a programmer. I enjoy using machine power to additionally help and support the QA Team during their already busy days.”

He also added that when used correctly, automated tests show their real power in terms of execution speed (including parallelism) and accuracy (a machine will always do what it’s instructed to, and it’ll never get tired or distracted).

Performance Testing

“Without the performance testing, you never know the site’s performance level and what should be improved. Users expect webpages to load as quickly as possible. And if it doesn’t happen, they get frustrated and leave. Also, if a website isn’t ready for Black Friday, it may crash once the amount of users increases rapidly, and the client won’t get the expected sales.”

Oleksandra Zhmurko was among those who built the Performance testing processes from scratch. At Astound, she had first been a manual QA Engineer, then a Lead up until 2017, when she first became acquainted with performance testing, and for the next 2 years she combined leading teams and doing performance testing work. Now, Oleksandra is a Performance QA Lead.

It all started when her team stumbled upon a performance issue on a Magento project. That’s when Oleksandra first thought about diving into performance testing. Then later, she, and a couple of other team members got to work on a first performance QA project.

“Since that time our team has already worked on plenty of exciting projects — simultaneous load testing of 10 sites, a high load project with up to 80000 concurrent users, a project with Headless SFCC, and many others — more than 25 in total. Each project brings something new and gives opportunity to continue learning.”

And, no project can be a success without a strong team. For several years now, Andriy Vovk and Roman Rak have been developing the Performance Testing department together with Oleksandra. At this moment, it consists of 6 team members.

Security Testing

“The online retail market is booming, with worldwide eCommerce sales having reached almost $4 trillion by the end of 2020. And, this kind of success attracts unwanted attention in the face of cyber-criminals. Good reputation is valuable for the clients, so it’s important to assure the web shops’ safety for end users and the site owner. The main goal of Security Testing is to identify the threats in the system and measure its potential vulnerabilities, so the threats can be encountered and the system does not stop functioning.” — Vitaliy Taradayko, Senior Test Automation Engineer and Security Test Lead comments on the value of Security testing.

For Vitaliy, this journey began when the QA department announced the initiative to implement Security testing.

“At the time, there was a lack of information on Security testing, so I had to do most of the research myself. However, this challenge pulled me into the process even more, and I practised testing the company sites every day after work. Eventually, I’ve tested more than 25 sites.”

Vitaliy’s Functional Manager noticed his efforts, and together they thought of how they could develop Security testing into a separate service. It was decided to launch an internal BootCamp where Vitaliy would share his knowledge and experience to those interested. As a result, two BootCamps have already given us a number of skilled Security QA Engineers, who, together with Vitaliy, are now employed on one of the biggest and most interesting projects in the company.

Accessibility Testing

This testing direction ensures that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, these people can perceive, understand, navigate, interact with the Web, and contribute to it.

Yevhenii Poliakov, QA Lead and Scrum Master with 6+ years of experience in testing, has helped build the Accessibility testing practice at Astound from scratch.

“On my project, I introduced Accessibility analysis as a mandatory part of each requirement analysis session. Also, Accessibility testing is now a part of testing activities for each functionality.”

Yevhenii also created an onboarding program for QA engineers, prepared artifacts, tools, and conducted several training sessions.

“It is important because it’s a social responsibility to make content available for all users. Plus, non-compliance can mean reputation and financial damage as Accessibility is supported by law in a lot of countries. Around 2000 accessibility lawsuits are processed each year.”

A few more words about our QA team

Our Technical Practice Lead Olena Kovalova noted:
“In the QA department all new thoughts are welcome. You should always look at the templates or processes critically, not just blindly follow them, and if you think something could be improved somehow, everyone will be ready to hear out your idea.” That’s the secret ingredient to the Astound’s QA success.

Contribute your own ideas to our QA team, grow and develop together with us! We now have several job openings!

The Scoop on Salesforce Developers

The position of a Salesforce Developer is often confused with that of an SFCC Engineer. What is the difference between them, what exactly does a Salesforce Developer do on a project, and what’s it like to work as an SF Developer at Astound Commerce?

To answer these questions, we’ve talked to Ilya Yefremov, who has been part of the Astound Commerce family for almost 2 years. He himself is a Senior Salesforce Engineer, and at the moment is looking to extend the team of SF Developers at Astound.

First things first, what does a Salesforce Developer do and how does this position differ from an SFCC Developer?

Salesforce Developers, unlike SFCC Engineers, don’t create ecommerce stores. They customize the CRM platform that includes Salesforce Service Cloud, Salesforce Sales Cloud and, since recently, the Order Management System. This CRM platform helps companies automate their sales, marketing, and customer service processes.

The Sales Cloud allows a company to manage the entire sales process from capturing a lead to closing a sale. It includes features like Web-to-lead, with an opportunity to create auto-response rules so that no lead is left unnoticed. There is also a business analytics function that lets anyone with access create reports using all the information from the cloud.

The Service Cloud is about automating customer service and support. There is a customizable user interface for support agents, with productivity tools and analytics, a service console — to manage multiple customer service cases simultaneously, and other features like the Public Knowledge Base and service process automation.

And then, there is OMS — Salesforce Order Management — a recent development. It’s a huge brand new application that includes about 25 new objects and its own automated processes. Companies can use it separately or together with, for example, the Service Cloud, so that support agents have access to order data along with the information on service cases and customer profile. The system is highly customizable, where an admin with a few clicks can set up a user interface and tailor the business logic according to the business needs.

Has Astound already started working on the OMS projects?

Astound, being the Salesforce Platinum Partner, was the first company to get OMS clients. At the moment, we are working on three projects, implementing this new functionality.

In which cases exactly does our company involve a Salesforce Developer on a project?

It depends on the client’s needs. When a client orders only an ecommerce site, our SFCC Developers work on implementing the Commerce Cloud. In such cases, a Salesforce Engineer is not needed. But, if a client wants to process all the cases and orders through the Service Cloud, a Salesforce Developer is employed to customize the Service Cloud according to the client’s needs — to process sales, orders, to set up the work of a call center, or work with customer service cases.

Mostly, we implement an ecommerce solution, and the Service / Sales / and now OMS Clouds come as a secondary task, but sometimes a client doesn’t need a site, but only a data management system — to manage leads, opportunities, sales, call centers and others. In such cases, SFCC Developers are not involved in the project, since Salesforce Engineers will be performing the customization here.

If Salesforce Developers are not involved in every Salesforce project, is there really a big demand for this kind of IT specialists on the market?

In the US, more and more companies are switching to Salesforce. At the moment, Salesforce is like the Apple of the ecommerce world. So, software provider companies are opening SF / SFCC Developer positions, hiring a team, and taking in clients, since indeed, there is a huge demand for SFCC and other SF Clouds implementations.

Meanwhile, the number of Salesforce Developers on the market is small. This technology is relatively new, so people usually choose to study more standard ones like Python, Java and JavaScript.

What technologies does a specialist need to know, to work as a Salesforce Developer?

Basically, full stack. For back end they need to have the knowledge of Apex, a Salesforce programming language, which syntactically resembles Java. So, if you know Java, with minimum effort you can train yourself in Apex. We even have one Engineer that switched from Java to Salesforce development.

For the front end part, for UI, Salesforce Developers use JavaScript. And, also, there is a Lightning Web Components framework. In SF development, other front end frameworks can be used, but LWC is the newest one. And we at Astound use only new technologies to provide the best solutions for our clients.

Apart from that, what an SF Developer needs to know, is the configuration opportunities of the Salesforce platform. Primarily, you have to be a Salesforce platform administrator, since lots of stuff can be configured manually.

Do we at Astound expect the candidates to be Salesforce certified?

We require that a candidate has Salesforce Platform Administrator and Developer I certifications.

Now, what about you? How did you become part of our team as a Salesforce Developer? What do you like about working at Astound?

I completed a Salesforce Developer course in another company and then applied for this position at Astound. One of the reasons for choosing this company was that it provided solutions for such clients as Adidas, Puma, Jimmy Choo and others.

I love the fact that we have Business Analysts and Solution Architects that communicate with the client, so I don’t have to. I receive a clear set of tasks that I can work on and not worry about misunderstanding the client and what they meant by this or that requirement. It’s all been handled by my teammates, so I can focus on my code.

The processes are well set. We have multiple SDLCs that we can tweak based on the project.

And, our Solution Architects work closely with Salesforce. Once our client wants to add a specific feature that can’t be implemented without the help of Salesforce, our architect can contact the Salesforce team directly and influence a lot of aspects. This is not the case for many other companies.

You are a Senior Salesforce Developer now. What’s the next step for you here?

I can grow to become a Solution Architect. It would be exciting to work closely with Salesforce on their newest applications.