DEV Community: Dorian Sabitov

Salesforce LWR vs Aura: what changes for Experience Cloud sites?

Dorian Sabitov — Wed, 04 Nov 2026 14:08:42 +0000

_How Lightning Web Runtime affects page performance, component development, and migration planning. _

A Salesforce Experience Cloud site can serve many purposes, from a customer support portal to an online store where distributors manage their orders. Whatever the use case, users expect pages to load quickly and the information they need to be easy to access.

The technology behind the site plays a part in that experience. Salesforce has traditionally used the Aura framework for Experience Cloud, but Lightning Web Runtime (LWR) provides a different approach to building and delivering websites and storefronts.

For organisations planning a new site or considering a move from Aura, it's useful to understand what LWR changes and what remains the responsibility of the development team.

What is Lightning Web Runtime?

Lightning Web Runtime (LWR) is a Salesforce technology for building and delivering web applications using Lightning Web Components (LWC).

Within Experience Cloud, LWR powers templates such as Build Your Own (LWR) and Microsite (LWR). Developers can create components using familiar web technologies, including HTML, JavaScript, and CSS, then configure them through Experience Builder.

The component model is an important distinction. Standard LWR-based Experience Cloud sites use Lightning Web Components. React and Angular aren't interchangeable alternatives within these templates, although Salesforce supports other frontend development approaches separately.

LWR also changes how the site delivers its components to visitors. Instead of loading everything dynamically, it prepares resources that can be cached and reused, reducing the work required when someone opens a page.

Why can LWR perform better than Aura?

The main difference comes from how the two runtimes deliver page resources.

In an Aura-based Experience Cloud site, Lightning components are delivered dynamically. LWR uses a publishing model in which components are prepared and served as static, cacheable resources.

These resources can also be delivered through Salesforce's content delivery network (CDN). By storing eligible files closer to users, the CDN can reduce the time needed to retrieve them.

That doesn't mean an LWR site displays only static information. Product details, customer records, and prices can still be retrieved from Salesforce when needed. How quickly updated information appears depends on the application's data access and caching configuration.

Salesforce describes LWR as a foundation for high-performance sites, but faster loading isn't guaranteed. Large images, unnecessary API requests, and poorly designed custom components can still cause delays.

For example, an ecommerce page might load its layout quickly while taking several seconds to display account-specific prices from an external system. In that situation, improving the integration may have more impact than changing the storefront technology.

LWR vs Aura: the differences worth knowing

Both technologies support Experience Cloud, but they differ in several ways.

Component development: Aura-based sites support Aura components and Lightning Web Components. Standard LWR templates use LWC, making the supported component model more consistent.

Publishing: Changes to component code can become available on an Aura site without republishing. In LWR, the site needs to be republished when updated standard, custom, or managed components should become available to visitors.

Available functionality: Aura has an established collection of templates and components. LWR provides lightweight templates and customisation options, but not every feature available in Aura has a direct equivalent.

These differences matter particularly when an organisation already has a customised portal.

A team might have invested considerable development effort in Aura components that support complex business processes. Moving to LWR would require reviewing those components, identifying suitable replacements, and testing the updated functionality.

For a new site, the decision may be simpler. LWR is a natural starting point when its templates and supported capabilities meet the project's requirements.

Salesforce maintains documentation covering LWR template limitations, which is worth reviewing before choosing an architecture.

When should you use LWR?

Salesforce recommends LWR for new B2B Commerce storefronts and encourages organisations with existing Aura-based B2B stores to consider migration.

LWR also works well for many custom Experience Cloud websites and portals, especially when teams want flexibility in component development and control over page performance.

Consider a manufacturer building a distributor portal. Buyers may need to browse products, access negotiated prices, and place orders. LWR can provide the storefront architecture, while Salesforce Commerce components and APIs support the relevant business processes.

An existing Aura portal needs a different assessment. If it already meets user requirements and depends on functionality that isn't supported in LWR, migration may not be the immediate priority.

The decision should consider the functionality the organisation needs, the effort involved, and what improvements the new architecture is expected to provide.

What does an Aura-to-LWR migration involve?

Migrating to LWR doesn't necessarily mean rebuilding every component.

Many Lightning Web Components developed for Aura-based sites can work in LWR without changes or with relatively small adjustments. Aura components, however, need to be replaced or redesigned using LWC.

Other changes may involve navigation, styling, component metadata, and data access. For B2B Commerce, storefront configuration also needs to be transferred and validated.

A sensible starting point is to review the existing site's components and dependencies. This helps establish which parts can be reused and which require additional development.

Testing should cover the complete user experience, including data access, permissions, navigation, and the business processes supported by the site.

The same principles apply to any Salesforce implementation: understand the requirements, assess the existing solution, and test changes before releasing them.

It's also important to distinguish an Aura-to-LWR migration from moving an older CloudCraze store to modern B2B Commerce. CloudCraze uses a different commerce architecture, so the project can involve broader changes to data and business logic. Our guide on moving off CloudCraze explains those considerations.

How do you know whether LWR is improving performance?

Performance improvements should be measured rather than assumed. For an existing site, record baseline results before migration and compare them with the new implementation. Test equivalent pages and user journeys under similar conditions.

Tools such as Google Lighthouse and WebPageTest can help identify slow-loading resources and other performance issues. Core Web Vitals provide additional measures of loading performance, responsiveness, and visual stability.

Testing can also reveal problems unrelated to the runtime. A slow API response, oversized image, or external script may affect the experience regardless of whether the site uses Aura or LWR.

Salesforce's Commerce storefront performance guidelines provide more detailed recommendations for LWR implementations.

Final thoughts

Lightning Web Runtime gives Salesforce developers a modern architecture for Experience Cloud sites and B2B Commerce storefronts. Its publishing and caching model can improve page delivery, while Lightning Web Components provide a reusable way to develop custom functionality.

For new B2B storefronts, LWR is the recommended Salesforce approach. For existing Aura sites, migration should begin with an assessment of current components, requirements, and expected benefits.

If you're planning a new Salesforce site or reviewing an existing implementation, explore Spyrosoft's Salesforce services to learn more about architecture, development, and migration support.

Originally published on the Spyrosoft blog. Read the full article: Levelling up your webstore with Lightning Web Runtime.

Salesforce B2B Commerce: pricing, ordering and ERP integration

Dorian Sabitov — Tue, 03 Nov 2026 14:53:04 +0000

How Salesforce B2B Commerce works in practice, from customer-specific pricing to online orders and integration with existing business systems.

Selling to other businesses often involves more than displaying products and accepting payments online. Different customers may have negotiated prices, access to specific products, or purchasing agreements that need to be reflected in every order.

Consider a distributor that sells industrial equipment and spare parts. Some customers order through sales representatives, while others prefer to place repeat orders online. Each account has its own pricing conditions, and information about products, availability, and orders may be managed across different systems.

Salesforce B2B Commerce is designed to support these purchasing requirements. It allows companies to create online storefronts connected to Salesforce CRM, with customer-specific pricing, product access, and self-service ordering.

In this article, we'll look at how Salesforce B2B Commerce works, which features matter in everyday business operations, and what companies should consider before implementing it.

What is Salesforce B2B Commerce Cloud?

Salesforce B2B Commerce is an ecommerce solution within Salesforce Commerce Cloud that helps businesses sell products and services to other companies through an online storefront.

The platform supports product catalogues, account-specific pricing, buyer access, shopping carts, and checkout processes. It is designed for business relationships where purchasing conditions may differ between customers.

For example, a manufacturer might sell the same products to several distributors, each with its own prices and product agreements. Instead of maintaining separate online stores, the business can use Salesforce to manage which products and prices are available to different groups of buyers.

One of the main advantages is its connection to the Salesforce ecosystem. B2B Commerce is built on the Salesforce Platform and can work alongside other products, including Sales Cloud, Experience Cloud, and Salesforce Order Management.

This gives companies the option to connect online purchasing with customer records and existing sales processes. However, integrations with external systems, such as ERP or warehouse management software, still need to be planned and configured.

How is B2B ecommerce different from B2C?

Most consumer ecommerce websites follow a relatively straightforward process. Customers browse a catalogue, select products, pay the displayed price, and complete their purchases.

Business purchasing can be more complicated.

A distributor may have negotiated pricing based on a commercial agreement. A large customer might have several employees authorised to place orders. Another customer may only be allowed to purchase products from a specific catalogue.

Repeat purchases are also common. Businesses may order the same materials or replacement parts regularly, sometimes in large quantities.

A B2B ecommerce platform needs to support these conditions without making the purchasing process unnecessarily difficult.

Salesforce B2B Commerce addresses several of these requirements through buyer accounts, buyer groups, price books, and entitlement policies.

These capabilities determine who can access the storefront, which products they can see, and what prices apply to their purchases.

For businesses with complex commercial relationships, this is an important difference from a standard consumer ecommerce experience.

How Salesforce B2B Commerce works in practice

Imagine a company that sells spare parts and maintenance equipment to business customers. It manages commercial relationships in Salesforce Sales Cloud, while its ERP system handles inventory, invoicing, and fulfilment.

The company wants to introduce an online ordering channel for existing customers without changing its entire sales process.

Here is how the purchasing journey could work.

*1. A customer signs in to the storefront *

A purchasing manager from one of the company's customers signs in to the B2B storefront.

Salesforce recognises the buyer and the business account they are authorised to purchase for.

Depending on the configuration, the customer can access a product catalogue, account-specific purchasing information, and relevant order history.

*2. Salesforce displays the correct products and prices *

The customer's account belongs to a buyer group configured in Salesforce.

This buyer group helps determine which products are available to the customer through entitlement policies. Price books control the relevant product pricing.

For example, one distributor might receive a negotiated price for replacement parts, while another customer sees the standard wholesale price.

The storefront can reflect these commercial arrangements without requiring the customer to contact a sales representative for each purchase.

Salesforce provides more information about this configuration in its documentation on buyer groups, entitlements, and pricing strategies.

*3. The customer places an order *

The purchasing manager selects the required spare parts, adds them to the cart, and proceeds to checkout.

Depending on the implementation, the checkout process may involve delivery details, shipping calculations, taxes, payment conditions, and inventory checks.

Once the order is successfully submitted, Salesforce can create an order record that becomes part of the company's commerce data.

*4. The order is passed to the ERP system *

The ERP system may still be responsible for warehouse operations, stock allocation, invoicing, and delivery.

In this example, an integration transfers the order information from Salesforce to the ERP system for further processing.

As the order progresses, relevant updates can be returned to Salesforce, allowing the company to provide order status information to customers and internal teams.

This information exchange is not automatic simply because a company uses B2B Commerce. The integration needs to define which system owns each process, what data is exchanged, and how errors are handled.

*5. Sales representatives retain visibility *

The online store becomes another purchasing channel alongside the existing sales team.

With appropriate access and configuration, sales representatives can review their customers' purchasing activity in Salesforce and use that information during account management.

For example, if a customer regularly buys replacement components, the sales representative can review their order history before discussing future requirements.

The result is a purchasing process where customers can handle routine orders themselves, while sales teams remain involved in managing commercial relationships.

Customer-specific pricing and product catalogues

One of the most useful capabilities of Salesforce B2B Commerce is the ability to manage different purchasing conditions within the same storefront.

This is particularly relevant for manufacturers, wholesalers, and distributors that work with multiple customer groups.

Salesforce uses several related components to manage the experience.

Buyer accounts represent business customers who can purchase through the store. Buyer groups allow companies to organise accounts with similar purchasing conditions.

Entitlement policies determine which products are available to those buyers, while price books help control the prices they see.

Consider a company working with regional distributors and direct business customers.

Regional distributors might have access to a wider selection of products and receive agreed wholesale prices. Direct customers may only see products relevant to their contracts.

Both groups can use the same storefront while receiving a purchasing experience appropriate to their commercial agreements.

These capabilities also require careful configuration. If a customer belongs to multiple buyer groups or has access to different price books, the pricing rules need to be tested to ensure the correct results.

For companies evaluating Salesforce B2B Commerce Cloud, it is worth reviewing these scenarios before implementation rather than assuming that every pricing arrangement will work without additional configuration.

Connecting online commerce with Salesforce Sales Cloud

Introducing B2B ecommerce does not necessarily mean replacing sales representatives.

For many businesses, an online store works best as an additional sales channel that supports existing relationships.

A customer might negotiate annual purchasing conditions with an account manager but place routine orders through the storefront.

The sales representative remains responsible for commercial discussions, while the customer gains another way to purchase products.

This approach can be particularly useful when sales teams spend significant time processing repeat orders or responding to requests for information already available in business systems.

For companies already using Salesforce Sales Cloud, B2B Commerce can extend existing customer management processes.

Sales Cloud supports account and opportunity management, while B2B Commerce provides the online purchasing experience.

When configured correctly, the two can give teams better visibility into the relationship between commercial agreements and purchasing activity.

However, the data model and integration requirements still matter. Businesses should decide how online orders relate to their existing sales processes and which teams need access to that information.

Why ERP integration matters

Although Salesforce B2B Commerce provides the online storefront and commerce capabilities, most established B2B companies already use other systems to manage important business processes.

An ERP system may be responsible for inventory, financial records, purchasing conditions, or order fulfilment. A separate warehouse management system may coordinate product availability and shipping.

Connecting these systems is often one of the more important parts of a Salesforce B2B Commerce implementation.

For example, a storefront should not allow customers to place orders based on outdated stock information if the business needs to guarantee availability before accepting a purchase.

Similarly, the price displayed online should match the commercial rules used by the organisation.

A well-designed integration needs to answer several questions.

Where is the product catalogue maintained? Which system calculates the final price? When should inventory be checked? Where is the order processed after checkout? How should cancellations, returns, and errors be handled?

These decisions affect the customer experience as much as the storefront itself.

Salesforce provides APIs and extension points for commerce processes, including checkout, pricing, inventory, shipping, and tax calculations. The implementation team can use these capabilities to connect the storefront with other systems where required.

The important part is to define the responsibilities of each system before development begins.

What to consider before implementing Salesforce B2B Commerce

The first step should be understanding how customers currently purchase products and which parts of that process would benefit from being available online.

A company with straightforward pricing and a limited product catalogue may need a relatively simple storefront. A manufacturer working with several distributors, multiple currencies, and complex commercial agreements will have different requirements.

There are four areas worth reviewing during the planning stage.

*Customer journeys and purchasing requirements *

Start by identifying who will use the storefront and what they need to accomplish.

Some customers may want to reorder products quickly. Others may need detailed technical specifications, different delivery addresses, or support for purchase orders.

These requirements should influence the storefront design and the first release scope.

*Product, account, and pricing data *

Review how product information, customer accounts, and commercial agreements are currently maintained.

If Salesforce and the ERP system contain overlapping information, decide which system should be responsible for each dataset.

This helps avoid situations where customers see one price online while the finance team processes another.

*Integration and order management *

Determine which systems will handle pricing, inventory, fulfilment, and post-purchase activities.

It is also important to review the Salesforce edition and licence arrangement. Salesforce currently distinguishes between B2B Growth and B2B Advanced, including differences in Order Management and advanced capabilities.

These differences can affect the architecture and overall implementation scope. The latest details are available on the official Salesforce B2B Commerce pricing page.

*Implementation scope and testing *

Rather than moving every customer and purchasing process online at once, consider starting with a specific customer group or product category.

For example, a distributor could launch a storefront for existing customers who regularly purchase standard spare parts.

This provides an opportunity to validate account access, pricing, checkout, integrations, and the overall purchasing experience before introducing more complex requirements.

Testing should also include unusual scenarios, such as incorrect account permissions, unavailable products, changed prices, and integration failures.

If you're planning an implementation, our article on how to start with Salesforce B2B Commerce Cloud provides additional guidance on assessing requirements and choosing an implementation approach.

When is Salesforce B2B Commerce a good fit?

Salesforce B2B Commerce is particularly relevant for companies that already use Salesforce and want to introduce or improve an online B2B purchasing channel.

It can also be suitable for businesses with account-specific pricing, repeat orders, multiple buyer groups, or complex commercial relationships.

Manufacturers, wholesalers, distributors, and companies selling equipment or replacement parts are examples of businesses where these requirements frequently arise.

However, Salesforce is not necessarily the right ecommerce platform for every organisation.

If a company has simple purchasing requirements and an existing ecommerce solution that works well, replacing it may not provide sufficient value to justify the cost and effort.

Before choosing a platform, businesses should compare their requirements with standard functionality, licensing, integration complexity, and ongoing maintenance needs.

It is also worth deciding how success will be measured. Online revenue is one indicator, but customer adoption, repeat-order activity, order accuracy, and the amount of manual processing required can provide additional insight.

The objective should be a purchasing experience that works reliably for customers and fits the company's existing operations.

Final thoughts

Salesforce B2B Commerce provides businesses with a way to introduce online ordering while supporting the commercial relationships and purchasing conditions that are common in B2B sales.

Its main value comes from connecting the storefront with customer accounts, pricing rules, and existing business processes. For companies already using Salesforce, this can make B2B ecommerce a natural extension of their CRM environment.

Before implementation, it is worth reviewing how customers buy, where product and pricing information is maintained, and which systems need to exchange data. These decisions help determine whether Salesforce B2B Commerce is a good fit and how the solution should be designed.

For companies planning a new commerce solution or reviewing an existing Salesforce environment, explore Spyrosoft's Salesforce services to learn more about implementation, integration, and ongoing development support.

FAQ

*What is Salesforce B2B Commerce Cloud? *

Salesforce B2B Commerce Cloud, commonly called Salesforce B2B Commerce, is an ecommerce solution for businesses selling to other companies. It supports online storefronts, buyer accounts, customer-specific pricing, product catalogues, and checkout processes. It can also integrate with Salesforce CRM and external business systems.

*What is the difference between Salesforce B2B Commerce and B2C Commerce? *

Salesforce B2B Commerce focuses on business purchasing requirements, including buyer groups, negotiated pricing, and account-specific product access. Salesforce B2C Commerce is designed primarily for consumer ecommerce. Both belong to Salesforce Commerce Cloud, but they have distinct capabilities and technical architectures.

*Does Salesforce B2B Commerce require an ERP integration? *

Not every implementation requires an ERP integration. However, businesses that manage inventory, invoicing, or fulfilment in external systems often need to connect those systems with Salesforce. The integration requirements depend on the existing architecture and which business processes need to be available through the storefront.

Salesforce Sales Cloud in 2026: How to Build a Sales Process People Actually Use

Dorian Sabitov — Fri, 02 Oct 2026 15:57:13 +0000

Most sales teams already have a CRM. The harder part is making sure people actually use it in the same way.

Problems usually start when the system no longer reflects how the sales team works. Leads wait too long for a follow-up, important updates stay in spreadsheets, and managers struggle to understand which deals are really moving forward.

Salesforce Sales Cloud, now part of Agentforce Sales, can bring these activities into one place. It supports the process from the first contact with a lead through opportunity management, forecasting, automation, and closing the deal.

But simply having Salesforce does not improve a sales process. The setup still needs to match the way the team sells.

Start with lead management

Lead management is often where the first problems appear.

A new enquiry comes in, but nobody knows who should handle it. Two people contact the same prospect. Other leads stay untouched for days.

Salesforce can help organise this process. Leads can come from website forms, campaigns, events, integrations, or manual entry. With the right setup, assignment rules can route them to the appropriate salesperson or team.

The next step is qualification.

Instead of treating every lead in the same way, teams can define what information they need before a lead should move forward. Depending on the Salesforce setup and licences in use, lead scoring can also help reps decide which prospects deserve attention first.

The important part is keeping the process simple.

Too many statuses, required fields, or qualification steps can make lead management slower instead of better. A good Salesforce implementation should make three things clear: who owns the lead, what happens next, and when it is ready to become an opportunity.

Make the pipeline reflect the real sales process

Once a lead has been qualified, the focus moves to the opportunity.

An opportunity brings the main information about a deal together: the customer, expected value, stage, expected close date, contacts, activities, and next steps.

The difficult part is not creating opportunity stages. It is making sure everyone understands what those stages actually mean.

For example, one salesperson may move a deal to “Proposal” after sending initial pricing, while another may use the same stage only after receiving a formal request for proposal.

Both records say “Proposal”, but they describe very different situations.

That makes the pipeline harder to trust.

Sales stages should reflect the way the organisation actually sells rather than being copied from a generic template. Clear stage definitions also make stalled deals easier to identify.

In practice, good Salesforce pipeline management is less about adding more dashboards and more about agreeing on a simple process that everyone follows consistently.

Forecasting is only as good as the pipeline

Salesforce forecasting can give managers a useful view of what is likely to close and what that means for expected revenue.

Salesforce can bring together opportunity stages, values, close dates, and forecast categories, giving salespeople and managers a shared view of the pipeline.

This can reduce the need for separate spreadsheets and manual updates before sales meetings.

But there is an important limitation: Salesforce cannot make inaccurate pipeline data accurate.

If opportunities sit in the wrong stage or expected close dates have not been updated for weeks, the forecast will reflect those problems.

Good forecasting therefore starts with good habits.

Teams need clear rules around when opportunities change stage, when close dates should move, and when a deal should no longer remain in the active pipeline.

The technology provides the view. The quality of that view still depends on the data behind it.

Use Flow for the repetitive work

Salespeople spend a lot of time on small tasks that follow predictable rules: creating follow-up tasks, updating fields, sending reminders, or requesting approvals.

This is where Salesforce Flow can help.

For example, when an opportunity reaches a particular stage, a Flow can create a task, notify the right person, update related information, or start an approval process.

Good Salesforce sales automation should remove routine work, not automate everything.

Too many overlapping Flows can quickly become difficult to understand and maintain. Before automating a process, it is often worth simplifying the process itself.

This is especially relevant for organisations that have used Salesforce for several years and accumulated different generations of automation.

Salesforce ended support and updates for Workflow Rules and Process Builder in December 2025, so Flow is now the recommended direction for new Salesforce automation.

If the current setup has become difficult to maintain, a structured Salesforce audit can help identify what should stay, what can be simplified, and what should move to Flow.

Where AI fits into Sales Cloud

AI is becoming a bigger part of the Salesforce sales experience.

Sales Cloud Einstein can support capabilities such as lead and opportunity scoring. This can help salespeople understand which leads or deals may deserve more attention.

Agentforce for Sales goes further.

AI agents can support selected sales activities such as following up with leads, answering common questions, qualifying prospects, and helping arrange meetings.

That does not mean every sales activity should be handed over to AI.

These tools work best when the underlying sales process is already clear and the Salesforce data is reliable. If records are incomplete or the pipeline is inconsistent, adding AI will not fix those problems.

In many cases, improving the data and process first creates more value than adding another layer of technology.

Avoid making Salesforce harder than selling

Many Sales Cloud problems are not really product problems.

They usually come from how the platform has been designed or how the process has evolved over time.

Some common examples are familiar:

too many automations that nobody wants to change;

duplicate or incomplete customer data;

sales stages that mean different things to different people;

low adoption because updating Salesforce takes too much effort.

A CRM should make the sales process easier to follow.

When the system becomes more complicated than the work itself, people start building their own alternatives in spreadsheets, notes, and other tools.

That is also why Salesforce should continue to evolve after go-live. Salesforce managed services can help teams maintain, simplify, and improve the platform as business requirements change.

Final thoughts

Salesforce Sales Cloud can bring leads, opportunities, forecasting, automation, and AI into one sales process.

But the goal should not be to use every available feature.

A good Salesforce setup should help salespeople understand what they need to do next and give managers information they can trust.

That usually comes back to a few basics: simple processes, reliable data, clear ownership, and automation where it actually saves time.

If you are planning a new Salesforce project, our Salesforce implementation guide covers the wider process from discovery to go-live.

For teams looking at their existing setup, you can also read our guide to the Salesforce audit framework.

And if your customer journey extends beyond sales, our guide to Salesforce Service Cloud Voice looks at how Salesforce can support customer service and contact centre operations.

The full version of this article is also available on the Spyrosoft Salesforce blog.

How to use Salesforce Service Cloud Voice for customer service in 2026

Dorian Sabitov — Fri, 02 Oct 2026 15:39:19 +0000

Customer service has moved far beyond phone calls. Customers now use email, messaging, self-service portals and other digital channels, but voice still matters when an issue is urgent, complicated or simply easier to discuss with another person.

For service teams, the challenge is not only answering calls. They also need those conversations to connect with the customer information, cases and processes already managed in Salesforce.

This is where Salesforce Voice, formerly known as Salesforce Service Cloud Voice, comes in. It brings telephony into the Salesforce service environment so agents can handle calls together with customer data, routing and service workflows.

But Salesforce Voice is more than a phone inside Salesforce. The way it works depends heavily on the telephony model, routing setup and level of automation an organisation chooses.

How Salesforce Voice differs from traditional CTI

Before Service Cloud Voice, many organisations connected their phone systems to Salesforce through CTI integrations.

This allowed agents to make and receive calls from Salesforce, but the CRM and telephony platform often remained largely separate. The phone controls appeared inside Salesforce, while much of the routing, reporting and call handling still happened elsewhere.

Salesforce Voice brings these areas closer together. Calls can become part of the Salesforce service process and work alongside customer records, cases, routing, transcription and automation.

This can also change how teams think about their contact centre. Moving from a traditional CTI integration to Salesforce Voice is not only about replacing the softphone. It may also involve reviewing call flows, routing, data, agent workflows and the way voice fits alongside other service channels.

If you are looking at the broader platform rather than Voice alone, our guide to Salesforce implementation explains how architecture, integrations, data and user processes fit together in a wider Salesforce project.

Choosing the right telephony model

One of the first decisions is what to do with the existing telephony setup.

Some organisations are building a new contact centre. Others already use Amazon Connect or another provider and want to keep it.

Salesforce supports several approaches.

Salesforce Voice provides a Salesforce-native telephony option. This can suit organisations that want Salesforce to manage more of the voice environment and keep the setup closely connected with the rest of the platform.

Salesforce Voice with Amazon Connect uses Amazon Connect for telephony while Salesforce handles much of the provisioning and setup.

Organisations that already manage their own AWS environment can use Partner Telephony from Amazon Connect. This gives them more control over Amazon Connect and the underlying AWS configuration.

There is also Partner Telephony, which allows companies to connect supported third-party telephony providers instead of moving their contact centre to Salesforce or Amazon Connect.

There is no single option that works best for everyone. The right model depends on the existing technology, required features and who should own the telephony environment after launch.

Routing calls with Salesforce Omni-Channel

Connecting telephony is only part of the setup. The next question is how calls reach the right person.

Salesforce Omni-Channel can coordinate voice with other service work, including messaging and cases. This gives the contact centre a shared view of agent availability and capacity instead of treating phone calls as a completely separate workload.

Omni-Channel flows can also help control routing. For example, calls can move to particular queues or agents based on skills and other business rules.

The system can also open relevant Salesforce records when an agent accepts a call. Instead of starting the conversation and then searching for the customer or case, the agent can already have the right information in front of them.

The exact routing model still depends on the telephony provider. Some organisations manage most routing in Salesforce, while others keep part of it within their contact-centre platform.

Where AI fits into Salesforce Voice

Voice is also becoming more closely connected with Salesforce AI.

Real-time transcription can turn a conversation into text while the call is happening. This gives agents another way to follow the conversation and creates information that can support later analysis.

Einstein Conversation Insights can analyse recorded conversations and help supervisors identify important moments, recurring topics and coaching opportunities.

Agentforce Voice takes this further. Voice-enabled agents can understand spoken requests, work with Salesforce data and carry out supported actions. Depending on the use case, they can handle suitable parts of a customer conversation and transfer the interaction to a human agent when needed.

These capabilities solve different problems.

Transcription captures what was said. Conversation intelligence helps teams analyse calls. Agentforce can take action during the conversation.

The important part is deciding where AI genuinely helps. Not every customer interaction needs automation, especially when the issue is complex or sensitive.

What to plan before implementation

A Salesforce Voice project touches more than telephony, so planning should start with the wider service process.

First, review the existing contact centre. Look at phone numbers, IVR, queues, routing, integrations and reporting. Understanding what already works makes it easier to decide what actually needs to change.

Then look at real customer journeys. What happens when someone calls? How are transfers handled? What happens if no agent is available? How should callbacks work?

Technical dependencies matter as well. Salesforce permissions, automation, integrations, data quality and network readiness can all affect the implementation.

A structured Salesforce audit can help identify issues in the current setup before Voice is added on top of it.

Ownership after launch should also be clear. An Amazon Connect setup may require AWS knowledge, while partner telephony brings its own provider-specific responsibilities.

Finally, test the scenarios agents deal with every day, not only the ideal call flow. Routing failures, transfers, unavailable agents and fallback processes should all be tested before go-live.

What about cost?

Salesforce Voice costs depend on the telephony model, licences and actual usage.

Amazon Connect setups can include different types of usage. For example, Salesforce Voice platform minutes and telephony minutes are tracked separately, and telephony usage can generate additional charges.

For this reason, the licence price alone does not give a complete picture of the cost of running the contact centre.

Before budgeting, it is worth estimating expected call volumes, inbound and outbound usage, telephony requirements and any additional AI capabilities the organisation plans to use.

Final thoughts

Salesforce Voice can make voice a much more connected part of the customer service process.

Agents can work with calls, customer data, cases and routing in the same environment, while transcription, conversation intelligence and Agentforce add further options for automation and AI.

The main challenge is choosing the right setup. A Salesforce-native model, Amazon Connect and partner telephony can all make sense in different situations.

For teams already running customer service on Salesforce, Voice can be a logical next step when phone interactions need to work more closely with the rest of the service platform.

The technology is only one part of it. A successful implementation also depends on routing, data, integrations, processes and clear ownership after launch.

If you want to look at the wider Salesforce setup, you can also read our guides to Salesforce managed services and Salesforce implementation.

The original, more detailed version of this article is available on the Spyrosoft Salesforce blog.

Salesforce Implementation in 2026: A Practical Step-by-Step Guide

Dorian Sabitov — Tue, 18 Aug 2026 11:29:11 +0000

Implementing Salesforce involves much more than configuring the platform. A typical project includes process analysis, solution design, data migration, integrations, testing, user preparation, go-live, and post-launch support.

A Salesforce implementation is the process of designing, configuring, integrating, and launching Salesforce so that it supports the way an organisation works. The exact scope depends on the business, but the implementation process usually follows a similar sequence, from validating the platform and defining requirements through to launch and continuous improvement.

The technical work is only one part of the project. Processes, data, users, ownership, and long-term platform management are equally important. When these areas are considered together, Salesforce can become a reliable system for daily work, reporting, and future development.

This guide explains the main Salesforce implementation steps, how long an implementation may take, what affects the cost, which mistakes are worth avoiding, and when external implementation support can be useful.

The Salesforce implementation process

A Salesforce implementation usually includes five main stages:
Platform validation and initial business case
Discovery and implementation planning
Mobilisation, configuration, and development
Data migration, testing, UAT, and go-live
Hypercare and continuous improvement

The depth of each stage depends on the project. A focused Sales Cloud implementation for one team will require a different level of preparation from a multi-cloud programme involving several business units, integrations, and large data volumes.

However, the sequence remains useful because it helps organisations address important decisions before they become expensive to change.

Step 0: Validate the platform fit

Before configuration starts, the organisation should confirm that Salesforce is suitable for the problem it wants to solve.

This means reviewing the main business objectives, expected users, processes, integration requirements, data sources, and likely Salesforce products. It is also useful to understand what the organisation expects to improve after implementation and how success will be measured.

At this stage, the team should avoid assuming that every existing process needs to be reproduced in Salesforce. Some processes may work well already, while others may contain unnecessary manual steps or rules that no longer serve a clear purpose.

For a relatively small project, platform validation may involve a limited number of workshops and an initial solution assessment. Larger programmes may require stakeholder interviews, architecture analysis, licence planning, and a more detailed business case.

The main result should be a clear understanding of whether Salesforce is the right fit, what the initial scope should include, and which assumptions or dependencies need further analysis.

An experienced implementation partner can also contribute at this stage by reviewing the proposed approach and highlighting where Salesforce fits the requirements well, where compromises may be necessary, or where another solution may be more appropriate.

Step 1: Discovery and the Salesforce implementation plan

Discovery converts the initial business case into a practical implementation plan.

The team looks at how people work today, where the main problems are, and how the future process should operate in Salesforce. The objective is not to document every current step and reproduce it exactly. Discovery should help determine which processes should remain unchanged, which can be simplified, and which are suitable for automation.

Workshops may cover business processes, user journeys, reporting requirements, security, permissions, integrations, data ownership, and business rules.

For example, an organisation may currently manage customer information across a CRM, spreadsheets, and an ERP system. Before deciding which fields should be created in Salesforce, the implementation team needs to understand which system owns each type of information, how data should move between systems, and whether all existing manual steps are still required.

Early prototypes can also be useful. A simple prototype often makes it easier for users to provide feedback on a proposed process before significant development work has been completed.

Discovery should also identify key dependencies. These may include external systems, data availability, integration ownership, security requirements, or decisions that need to be made by specific business stakeholders.

By the end of this stage, the team should have a prioritised backlog, an initial solution design, an understanding of the main data and integration flows, delivery milestones, key risks, and agreed responsibilities.

Step 2: Mobilisation, configuration, and development

Before the main build begins, the team should define how Salesforce changes will be developed, tested, and released.

Depending on the project, this may include sandbox management, version control, deployment processes, development standards, testing responsibilities, documentation, and release governance.

These controls are relevant to both custom development and declarative configuration. Flows, validation rules, permission sets, Apex, and Lightning components can all create dependencies that need to be understood and managed.

Once the delivery foundations are ready, configuration and development can begin.

Many Salesforce projects benefit from an iterative approach. A manageable group of requirements is completed, demonstrated to stakeholders, reviewed, and adjusted before the next group of work begins. This allows feedback to be incorporated while changes are still relatively easy to make.

Standard Salesforce functionality should generally be preferred when it meets the business requirement. Custom development is appropriate when configuration alone cannot provide the required functionality, integration, performance, or user experience.

The main risk is not customisation itself. Problems are more likely to appear when custom solutions accumulate without sufficient documentation, testing, ownership, or understanding of their dependencies.

In an existing Salesforce org, a structured Salesforce audit framework can help identify areas such as automation complexity, code quality, security, integrations, and technical debt before further development continues.

Testing, security review, and documentation should therefore form part of the delivery process rather than being postponed until the final stage of the project.

Step 3: Data migration, UAT, and go-live

As the solution approaches completion, the focus moves towards data migration, end-to-end testing, user acceptance testing, training, and production launch.

Salesforce data migration begins with deciding which information needs to move into the new system.

Migrating every historical record is not always necessary. Some information may be important for everyday work, reporting, compliance, or customer history, while other data may have little practical value in the new platform.

For example, a legacy CRM may contain many years of activities and closed records. The implementation team should determine which information users need directly in Salesforce, which data needs to remain accessible for other reasons, and whether all of it needs to be migrated in the same way.

The selected data should then be cleaned, mapped, transformed where necessary, and validated before production migration.

Testing should also cover complete business processes rather than individual features only. Configuration, custom code, permissions, integrations, automation, and migrated data need to work together.

User acceptance testing gives representative users an opportunity to confirm that the solution supports realistic business scenarios and meets the agreed acceptance criteria. UAT is most useful when users follow defined processes and expected outcomes rather than simply exploring the system without a clear test plan.

Go-live preparation should include a detailed cutover plan. This normally defines the deployment sequence, data-freeze period, migration activities, responsibilities, communications, final checks, and rollback approach.

Training and support materials should also be prepared before users receive access to the production environment.

For larger implementations, a phased rollout may be appropriate. Releasing Salesforce to one business unit, region, or user group first can reduce risk and provide useful feedback before a wider rollout.

Step 4: Hypercare and continuous improvement

The implementation process continues after Salesforce goes live.

The first weeks are often covered by a hypercare period, during which the team monitors the production environment, supports users, and resolves high-priority issues.

This may include reviewing integrations, automation, data quality, permissions, and user-reported problems. It is useful to distinguish between production defects, training questions, and requests for new functionality because each type of issue requires a different response.

Once the platform is stable and the volume of launch-related issues has decreased, responsibility can move to the normal support and development model.

From this point, continuous improvement becomes part of regular Salesforce management. Teams can review adoption, data quality, business requirements, platform releases, and the improvement backlog on an ongoing basis.

Some organisations manage this work entirely with an internal Salesforce team. Others use Salesforce managed services to provide additional administration, development, maintenance, and release support.

In either model, clear ownership remains important. Someone needs to be responsible for platform quality, prioritisation, and the way Salesforce develops over time.

How long does a Salesforce implementation take?

There is no standard Salesforce implementation timeline. Projects with a similar number of users may still differ significantly in scope and technical complexity.

As a general indication, the following ranges can be useful:

Focused or single-cloud implementation: 6–12 weeks

This may include one main business team, relatively limited configuration, a small number of integrations, and a straightforward data migration.

Mid-sized implementation: 3–6 months

A mid-sized project may cover several processes, multiple user groups, more extensive data migration, and selected integrations with other business systems.

Complex or multi-cloud programme: 6–12 months or longer

These programmes may involve several Salesforce products, multiple business units, complex integrations, large data volumes, stricter governance requirements, and phased deployment.

These ranges are indicative rather than fixed.

The actual timeline depends on scope, customisation, integration complexity, data quality, security requirements, stakeholder availability, and the speed of business decisions.

A relatively small project can take longer than expected when requirements remain unclear or legacy data requires extensive preparation. A larger programme may progress more predictably when governance, ownership, and priorities are established early.

A well-structured discovery phase helps produce a more reliable estimate because it identifies important dependencies and risks before the main build begins.

What affects Salesforce implementation cost?

There is no universal Salesforce implementation cost. The estimate depends on the scope of the project, the complexity of the existing environment, and the amount of business and technical change required.

The main cost drivers usually include:

Salesforce products and licences

The selected Salesforce products and editions, the number and type of users, and the organisation's licensing requirements all affect the overall cost.

Scope and customisation

A project covering several departments, processes, automations, or custom components will normally require more effort than a focused implementation using mostly standard functionality.

Integrations

Integration effort depends on the number of connected systems, the direction and frequency of data exchange, authentication, error handling, monitoring, and the complexity of the integration architecture.

Data migration

Data volume is only one factor. Data quality, duplicate records, mapping, cleansing, transformation, and validation can significantly affect migration effort.

Delivery and adoption

The estimate should also include discovery, architecture, configuration, development, testing, project management, training, go-live preparation, and post-launch support.

For this reason, comparing implementation prices without comparing the underlying scope can be misleading.

A reliable estimate should consider the full implementation lifecycle rather than focusing only on licences or development effort.

Common Salesforce implementation mistakes

Salesforce implementation problems often develop from several smaller decisions rather than one major technical mistake.

One common issue is reducing the discovery phase in order to begin development sooner. Requirements, dependencies, and risks may then appear later, when changes are more difficult and expensive.

Another is reproducing existing processes without reviewing whether they still make sense. Moving an inefficient process into Salesforce does not remove the inefficiency.

Overusing custom development can also make the platform more difficult to maintain, particularly when standard Salesforce functionality would have met the requirement.

Data and integrations are another frequent source of difficulty. Users are unlikely to trust Salesforce if customer information is incomplete, duplicated, inconsistent, or delayed because connected systems are unreliable.

Testing, security, and training should also receive attention throughout the project. Leaving these areas until the final weeks can expose issues when there is limited time to resolve them.

Finally, unclear ownership can slow down even a technically straightforward implementation. Business decisions need named owners, especially when requirements affect several departments or systems.

A clear Salesforce implementation plan should address these risks from the beginning.

Do you need a Salesforce implementation partner?

Not every organisation requires an external Salesforce implementation partner.

A company with an experienced internal Salesforce team may be able to deliver a focused implementation independently.

External support becomes more useful when Salesforce is new to the organisation, several Salesforce products are involved, integrations are complex, internal delivery capacity is limited, or additional architecture and governance support is required.

The role of an implementation partner should extend beyond providing developers. A strong partner can help clarify requirements, review architecture, identify dependencies, explain technical trade-offs, establish delivery standards, and transfer knowledge to the internal team.

This is particularly important when several internal teams or external suppliers share responsibility for the same Salesforce environment. Our guide to multivendor Salesforce delivery explains how roles and responsibilities can be structured to reduce gaps between teams.

The appropriate delivery model depends on the complexity of the implementation, the organisation's internal Salesforce knowledge, available capacity, and the level of delivery risk.

Final thoughts

A successful Salesforce implementation should support the organisation beyond the initial launch.

The platform needs to reflect real business processes, provide reliable data, support users in their daily work, and remain manageable as requirements change.

Reaching that point requires structured discovery, controlled delivery, careful data migration, realistic testing, user preparation, and clear ownership after go-live.

The specific implementation approach will vary from one organisation to another, but the underlying principles remain similar: understand the business problem first, make deliberate design decisions, test the complete solution, and plan for how Salesforce will be managed after launch.

If you are planning a Salesforce project or reviewing an existing implementation, you can explore Spyrosoft Salesforce services for implementation, integration, architecture, and ongoing platform development.

For a more detailed version of the process, see the full Salesforce implementation step-by-step guide on the Spyrosoft website.

Q&A: Salesforce implementation in 2026

*What is a Salesforce implementation? *

A Salesforce implementation is the process of planning, configuring, integrating, testing, and launching Salesforce for an organisation. It can also include data migration, security design, user training, and post-launch support. The objective is to create a Salesforce environment that supports business processes and can be maintained as requirements change.

*How long does a Salesforce implementation take? *

A focused Salesforce implementation may take around 6–12 weeks, while a mid-sized project may take 3–6 months. More complex or multi-cloud programmes can take 6–12 months or longer. The timeline depends on scope, integrations, data quality, security requirements, testing, and stakeholder availability.

*How much does Salesforce implementation cost? *

There is no standard Salesforce implementation cost. The estimate depends on the selected Salesforce products, project scope, level of customisation, integrations, data migration, testing, training, and delivery model. A discovery phase usually provides a more reliable basis for estimating the work because it helps identify requirements, dependencies, and delivery risks.

*What are the most common Salesforce implementation mistakes? *

Common Salesforce implementation mistakes include shortening discovery, recreating inefficient processes without review, overusing custom development, underestimating data migration and integrations, and leaving testing or training until late in the project. Unclear ownership can also delay decisions and make the implementation more difficult to manage.

*When should you use a Salesforce implementation partner? *

A Salesforce implementation partner can be useful when Salesforce is new to the organisation, the project includes several products or complex integrations, internal capacity is limited, or additional architecture and delivery support is required. A partner should also help clarify requirements, explain technical trade-offs, establish delivery standards, and transfer knowledge to the internal team.

Salesforce Audit Guide 2026: How to Assess Org Quality, Security and Technical Debt

Dorian Sabitov — Thu, 13 Aug 2026 12:58:32 +0000

_What would an independent Salesforce expert find if they reviewed your org today? _

For many organisations, that is surprisingly difficult to answer.

Salesforce may support critical business processes every day, while teams have only a partial view of how much custom code exists, how automations depend on one another, which integrations are fragile, or how much technical debt has accumulated.

That is where a Salesforce audit becomes useful.

A Salesforce audit provides an independent, structured review of your Salesforce environment. It helps you understand what is working, where risks exist, and what should be improved before those issues start affecting users, security, reporting or future releases.

This guide explains what a Salesforce audit covers, when you may need one, how the Spyrosoft CRM Audit Framework works, and what you should expect at the end of the process.

What is a Salesforce audit?

A Salesforce audit is an in-depth review of how your Salesforce org is designed, configured and maintained.

It can assess:

architecture and data model
Apex code and triggers
Salesforce Flows and other automation
security and access
integrations
data quality
platform performance
technical debt
alignment between Salesforce and current business processes

The aim is not simply to identify problems.

A useful audit should explain why an issue exists, how serious it is, what business impact it may create and what should be done next.

That makes a Salesforce audit different from a lighter platform review.

A Salesforce Health Check, for example, is commonly used to review areas such as security settings and visible platform risks. For a broader overview, see our guide to the importance of a Salesforce Health Check.

A full Salesforce org audit goes deeper into the platform's technical foundations, including code quality, automation architecture, integration design, security, scalability and technical debt.

In practical terms:

A Health Check helps you understand where to look. A Salesforce audit helps you understand what is really there, how much risk it creates and what you should do about it.

Why does Salesforce technical debt grow?

One of Salesforce's biggest strengths is flexibility.

That flexibility also makes it easy for small changes to accumulate.

A Salesforce environment may start with a carefully planned implementation. Processes are defined, licences are selected, the data model is prepared and the platform goes live.

Then the business changes.

A new field is added for one team.

A Flow is changed to support an exception.

An integration is adjusted before a deadline.

A report is created for one manager.

A package is installed for a short-term requirement.

Each decision may make sense on its own. Problems usually appear when these changes are no longer reviewed, documented or cleaned up.

After a few years, the Salesforce org may still work, but:

changes take longer than expected
releases become harder to predict
automations have unclear dependencies
integrations are difficult to troubleshoot
unused fields and components remain in the system
teams are reluctant to change existing functionality
nobody has a complete view of how the platform works

This is Salesforce technical debt.

An audit makes that debt visible and helps determine which parts actually create business or technical risk.

When should you run a Salesforce audit?

You do not need to wait for a major Salesforce failure.

In many organisations, the early warning signs appear much sooner.

Consider an audit if:

every Salesforce change seems to take longer than before
releases regularly create unexpected problems
nobody can clearly explain some Flows, integrations or custom code
important platform knowledge sits with one person or supplier
you operate in a multivendor Salesforce delivery environment with unclear ownership
users report recurring issues that are difficult to diagnose
Salesforce releases or new features are postponed because teams are worried about dependencies
you suspect security or permission risks
leadership wants an independent view of platform quality
the business no longer fully trusts estimates, reports or delivery timelines

The common theme is uncertainty.

A Salesforce audit replaces assumptions with evidence.

What should a Salesforce audit cover?

There is no single audit scope that works for every organisation. A smaller Sales Cloud implementation will need a different review from a global environment with several Salesforce products and external systems.

However, eight areas are particularly important.

*1. Architecture and design *

Review the overall Salesforce architecture, data model, custom objects, configuration approach and major design decisions.

The key question is:

Can the current architecture support future growth without making every new change harder?

*2. Code quality *

Review Apex classes, triggers, test coverage, duplication, documentation and maintainability.

Poorly structured code can increase defects, slow releases and create dependency on individual developers.

*3. Automation *

Analyse Flows, approval processes, validation rules and other automations.

The audit should identify overlapping logic, unnecessary complexity and dependencies that make changes risky.

*4. Security and access *

Review profiles, permission sets, sharing rules, field-level security and high-risk access.

A Salesforce security audit should identify excessive permissions and access patterns that may create security or compliance risk.

*5. Integrations *

Review APIs, middleware, synchronisation logic, error handling, connected systems and ownership.

An integration does not need to fail completely to create problems. Poor monitoring or unclear ownership can lead to missing data, repeated manual corrections and difficult troubleshooting.

*6. Data quality *

Check for duplicates, incomplete records, inconsistent fields, outdated information and weak data governance.

Poor data quality eventually affects reports, dashboards, automation and business decisions.

*7. Performance *

Review page load times, automation execution, platform limits, report performance and user experience.

Performance problems often reveal deeper architecture or automation issues.

*8. Technical debt and business process fit *

Identify unused fields, legacy customisations, old packages, undocumented changes and fragile dependencies.

At the same time, compare how Salesforce was originally designed with how teams actually work today.

This becomes especially important when an organisation uses multiple Salesforce cloud products.

Sales Cloud, Service Cloud, marketing tools, integrations and reporting do not operate independently. A change in one part of the platform can affect several others.

That is why Salesforce should be reviewed as one connected ecosystem.

How does the Spyrosoft CRM Audit Framework work?

A Salesforce audit needs structure.

Without a clear methodology, it is easy to collect hundreds of technical observations without answering the question that matters most:

*What should we actually fix first? *

Spyrosoft uses the Spyrosoft CRM Audit Framework to review both functional and technical aspects of a Salesforce environment.

As Michał Gronowski, Salesforce & Enterprise Architect and Co-founder & CTO of Spyrosoft Connect, explains:

“We split our work into two areas, functional and technical, and we start from a helicopter overview. Then, we dig into details where needed.”

The process consists of five main stages.

*Step 1: Understand the context *

The audit starts with business goals, known pain points, current challenges and expectations.

This prevents the review from becoming a purely technical exercise.

*Step 2: Map the Salesforce environment *

The team builds a high-level picture of:

org structure
key business processes
important customisations
data model
integrations
major automation
areas that may require deeper analysis

This gives auditors the context needed to decide where the largest risks may exist.

*Step 3: Investigate high-risk areas *

The review then goes deeper where necessary.

That could mean analysing:

Apex code
complex Flows
security configuration
integrations
data quality
performance
technical debt

Not every part of the org requires the same level of investigation.

The goal is to focus effort where it can reveal the most important issues.

*Step 4: Prioritise findings *

Finding an issue is only half the job.

Each finding should be assessed based on:

severity
technical risk
business impact
urgency
effort required to resolve it

This separates genuine risks from minor optimisation opportunities.

*Step 5: Present the findings and next steps *

The final results should be understandable to both technical teams and business stakeholders.

Spyrosoft uses a simple green, yellow and red rating model to make the current state easier to understand.

Green: healthy or low-risk areas
Yellow: areas that need attention
Red: significant risks requiring action

For management or board-level stakeholders, the detailed technical analysis can also be condensed into a key takeaways summary covering the most important risks and priorities.

What should you receive after a Salesforce audit?

A Salesforce audit should not end with a 100-page report that nobody opens again.

The useful outcome is a prioritised improvement plan.

A good Salesforce audit report should make clear:

what the biggest risks are
how serious they are
which issues affect users or business processes
which problems can be solved quickly
which changes need architectural or technical planning
what should be added to the longer-term Salesforce roadmap

Some findings may be relatively easy to address.

Examples include:

removing unused components
correcting risky permissions
fixing broken automation
documenting critical integrations

Other issues may require more substantial work:

refactoring Apex
redesigning integrations
simplifying automation architecture
restructuring the data model
reducing accumulated technical debt

The important point is that the organisation knows what to do now, what to plan next and what can wait.

For organisations with an ongoing backlog or limited internal Salesforce capacity, audit recommendations can also become part of a structured Salesforce managed services model.

Salesforce audit vs. Salesforce Health Check

This distinction is worth making clearly.

*Salesforce Health Check: *
A lighter review focused on visible risks and general platform health.

*Salesforce audit: *
A deeper review of architecture, code, automation, integrations, security, data, performance and technical debt.

If you mainly need an initial indication of platform health, a Health Check may be enough.

If you need to understand why delivery has become difficult, whether your architecture can scale, where technical risk exists or what should be improved first, a deeper Salesforce org audit is usually more useful.

What makes a Salesforce audit valuable?

The real value is not the number of issues discovered.

It is clarity.

After the audit, your team should be able to answer:

Where does our Salesforce org stand today?
Which areas create the most risk?
What is technical debt costing us?
Which problems should we fix first?
Which improvements can wait?
Can the current architecture support future growth?
What should become part of our Salesforce roadmap?

That makes an audit useful not only for administrators, developers and architects, but also for IT leaders and business stakeholders responsible for Salesforce investment.

Final thoughts

Salesforce problems are not always obvious.

The platform can continue working while changes become slower, deployments become riskier and teams gradually lose confidence in the system.

A Salesforce audit provides an independent view of the platform's real condition.

It reviews architecture, code, automation, security, integrations, data, performance and technical debt, then converts those findings into priorities.

If your Salesforce environment has been heavily customised, depends on several integrations or supports business-critical processes, an independent audit can help you understand what should be fixed now and what should become part of your longer-term roadmap.

Want an independent view of your Salesforce setup? Explore Spyrosoft Salesforce services and see how the Spyrosoft CRM Audit Framework can help you identify risks and plan the next step.

Frequently asked questions

*What is a Salesforce audit? *

A Salesforce audit is an independent review of a Salesforce org. It evaluates areas such as architecture, code quality, automation, security, integrations, data, performance and technical debt, then connects the findings to business impact.

*What does a Salesforce audit include? *

The scope depends on the organisation, but it commonly includes architecture, Apex code, Flows, security, integrations, data quality, performance, technical debt and business process fit.

*How is a Salesforce audit different from a Salesforce Health Check? *

A Salesforce Health Check is generally a lighter review of visible risks and platform health. A Salesforce audit goes deeper into areas such as code, architecture, integrations, automation and long-term maintainability.

For a lighter review, see our guide to the importance of a Salesforce Health Check.

*How long does a Salesforce audit take? *

The timeline depends on the size and complexity of the Salesforce environment. An audit may take from two to several weeks, beginning with a high-level review before moving into the highest-risk areas.

*What does a Salesforce security audit check? *

A Salesforce security audit can review profiles, permission sets, sharing rules, field-level security, guest user access and integration accounts to identify security or compliance risks.

*What do you get after a Salesforce audit? *

The expected output is a clear audit report containing prioritised findings, severity ratings, practical recommendations, stakeholder takeaways and a roadmap showing what should be addressed now, next and later.

*What happens after the Salesforce audit? *

The organisation can use the findings internally or turn them into an ongoing improvement roadmap. Where regular Salesforce support is required, the recommendations can also feed into a managed services model.

This article is based on Spyrosoft's Salesforce audit methodology. The original version is available at Spyrosoft.

Salesforce Health Check: what should you review before your org becomes hard to trust?

Dorian Sabitov — Wed, 29 Jul 2026 15:16:28 +0000

A Salesforce Health Check is not only useful when something is already broken. In many organisations, Salesforce still supports daily work, but small issues slowly start to appear.

Reports become harder to trust. Users create workarounds. Flows take longer to update. Integrations need manual fixes. Permissions are no longer clear. New Salesforce changes take more time than expected.

At first, these problems may look separate. One team complains about reports. Another team works in spreadsheets. Admins struggle with old automation. Managers question whether the data is correct.

Together, these are signs that your Salesforce org may need a closer review.

A Salesforce Health Check gives teams a structured way to understand what is happening inside the org, where the risks are, and what should be improved before small issues become bigger business problems.

What is a Salesforce Health Check?

A Salesforce Health Check is a structured review of your Salesforce org. It helps you understand what works well, what creates risk, and what needs to be improved.

The goal is not only to check whether Salesforce is available or technically working. The more important question is whether Salesforce still supports the way your business works today.

This matters because every Salesforce org changes over time: new users join, business processes evolve, teams request new fields, reports are updated, flows are changed, integrations are added, permissions are adjusted.

Each change may be reasonable at the time, but after months or years, the org can become difficult to manage. That is when Salesforce technical debt starts to grow.

A proper Salesforce Health Check can review areas such as:

Salesforce security settings,
user access and permissions,
Salesforce data quality,
duplicate records,
reports and dashboards,
Flows and automation,
integrations with other systems,
page performance,
unused fields and configuration,
release readiness,
governance and ownership,
user adoption.

In simple terms, a Salesforce Health Check helps answer one important question: can your team still trust Salesforce?

Salesforce Health Check is not only about security

Many people connect the phrase “Salesforce Health Check” with security only. Security is important, but it should not be the whole review.

A Salesforce security audit can help admins review password policies, session settings, user access, and other configuration risks. These checks are useful, especially as a starting point.

But security tools alone do not show the full picture.

For example, your security settings may look fine, but your sales team may still say that pipeline reports are inaccurate. In that case, the report may not be the real problem.

The real cause could be duplicated accounts, missing opportunity fields, outdated validation rules, poor Salesforce data quality, or a sales process that no longer matches how the team actually works.

A broader Salesforce org audit helps separate the symptom from the root cause. Instead of only changing the report, it helps you understand why the report became unreliable in the first place.

Why Salesforce orgs need regular review

Most Salesforce orgs do not become hard to manage because of one bad decision. Usually, it happens because of many small changes that were never reviewed later.

A field is added for one team. A Flow is updated for one exception. A report is created for one manager. A user gets wider access because something is urgent. An old integration keeps running because nobody wants to touch it.

At the time, each decision may make sense.

The problem appears later, when no one knows which fields are still used, which automations are business-critical, which reports can be trusted, and which permissions are still correct.

This is how Salesforce technical debt appears.

It does not always mean something was built badly. Sometimes it simply means the org changed, but the setup was not reviewed often enough.

Regular Salesforce Health Checks help bring these issues back into focus. They make it easier to see what should be cleaned up, what should be improved, and what should become part of a longer Salesforce roadmap.

Signs your Salesforce org may need a Health Check

Your organisation may need a Salesforce Health Check if the same platform issues keep returning.

Common signs include:

reports are no longer trusted,
duplicate or incomplete data appears often,
users work outside Salesforce,
Flows are difficult to update,
too many users have broad access,
integrations need manual correction,
record pages feel slow or overloaded,
new changes take too long,
the Salesforce backlog keeps growing.

User behaviour is also important. If people avoid Salesforce, export data to spreadsheets, or create their own process outside the system, the issue is rarely only technical. It often means Salesforce no longer fits daily work as well as it should.

For example, a service team may start manually reassigning cases because routing rules no longer match the team structure. At first, this looks like a small workaround. Later, it affects response times, reporting accuracy, and team performance.

The same can happen in sales. A pipeline report may look wrong, but the real issue may be poor data quality, outdated opportunity stages, missing fields, or different teams using Salesforce in different ways.

A Salesforce Health Check helps decide what should be fixed first, what can wait, and what needs a longer improvement plan.

What should be included in a Salesforce Health Check?

A good Salesforce Health Check should review the whole org, not only one report, dashboard, object, or setting.

Salesforce usually supports several teams and business processes. One issue can affect many areas at once. A data quality problem can affect reporting. A permission change can create a security risk. A new automation can influence service processes. An integration issue can create manual work for users.

The review should usually include:

Security and access
A Salesforce security audit should check users, profiles, roles, permission sets, inactive users, broad access, and security-related configuration.

Data quality
A Salesforce data quality review should look at duplicates, missing fields, inconsistent values, outdated records, and data that affects reporting accuracy.

Reports and dashboards
Reports should reflect real business processes. If users do not trust dashboards, the problem may be data, process design, field usage, or report logic.

Automation
A Salesforce automation review should cover Flows, validation rules, approval processes, and old automation that may be difficult to maintain.

Integrations
A Salesforce integration audit should check how data moves between Salesforce and other systems, where errors appear, and whether users need manual fixes.

Performance and user experience
Record pages, layouts, related lists, and user journeys should support daily work instead of slowing users down.

Release readiness
Salesforce release readiness is important because seasonal releases can introduce new features, changes, and updates that should be reviewed before they affect daily operations.

Governance and ownership
A Health Check should also review how Salesforce changes are requested, prioritised, documented, approved, and delivered.

This is especially important when your organisation uses several Salesforce products or connected systems. If you want to understand how different Salesforce products support sales, service, marketing, and operations, this guide to Salesforce cloud tools may also be useful.

The main point is simple: Salesforce should be reviewed as a connected platform, not as a set of separate technical items.

Salesforce Health Check vs Salesforce org audit

A Salesforce Health Check and a full Salesforce org audit are closely related, but they are not always the same thing.

A Health Check usually gives teams a practical view of the current state of the org. It helps identify risks, technical debt, data issues, automation problems, security gaps, and improvement areas.

A full Salesforce org audit usually goes deeper. It can review architecture, data model, integrations, automation logic, reporting structure, user access, governance, documentation, and long-term maintainability.

For example, a tool may show that a field is unused. But that does not automatically mean it is safe to remove. The field may still be used in an integration, a hidden process, an old report, or a business rule that only one team knows about.

That is where a broader Salesforce org audit adds value. It does not only show what exists in Salesforce. It helps explain what still makes sense, what creates risk, and what should be changed carefully.

What happens after a Salesforce Health Check?

A Salesforce Health Check should not end with a long document that nobody uses.

The real value is the improvement plan.

After the review, findings should be grouped by priority, risk, and business impact. Some items may be quick wins, such as removing inactive users, cleaning up unused fields, adjusting permissions, or updating outdated reports.

Other items may need more planning. This can include redesigning complex Flows, improving data governance, reviewing integrations, simplifying page layouts, or preparing the org for future Salesforce releases.

A useful Health Check should help your team understand three things:

what needs attention now,
what can be improved next,
what should become part of a longer Salesforce roadmap.

This helps teams move from reactive fixes to planned improvement. Instead of solving the same issue again and again, they can understand why it appears and fix it properly.

How Salesforce Health Check connects with managed services

If a Salesforce Health Check shows recurring issues, a growing backlog, poor data quality, or regular support needs, the findings can become a roadmap for Salesforce managed services.

This is useful because the review does not stay as a one-time audit. It becomes the starting point for ongoing improvement.

Quick fixes can be handled first. Larger items can be planned across the next months. Recurring admin, development, reporting, integration, automation, and release work can become part of a structured Salesforce support model.

This connection is important because Salesforce health is not only about finding issues. It is also about having a clear way to solve them.

When several teams or vendors are involved

A Salesforce Health Check becomes even more useful when several teams, departments, or vendors work on the same platform.

In these situations, ownership can become unclear. One team changes automation, another manages integrations, another owns reports, and another supports users. Without clear governance, small changes can create unexpected impact elsewhere.

For larger Salesforce environments, it is worth reviewing not only the org setup, but also how decisions are made, documented, and delivered.

This article about multivendor Salesforce delivery may be useful if your Salesforce setup involves several partners or delivery teams.

Final thoughts

A Salesforce Health Check is not only a technical review. It is a practical way to understand whether your Salesforce org is still secure, reliable, clean, and useful for the business.

If users no longer trust reports, teams rely on workarounds, automations are difficult to maintain, or every change takes too long, it may be time to review the health of your org.

The full Spyrosoft article goes deeper into what a Salesforce Health Check should include, how it differs from built-in Salesforce tools, and how the findings can support a longer-term improvement plan.

You can also explore Spyrosoft Salesforce services if your team needs support with Salesforce consulting, implementation, optimisation, or managed services.

Q&A

*What is a Salesforce Health Check? *

A Salesforce Health Check is a structured review of your Salesforce org. It helps identify risks, technical debt, security gaps, Salesforce data quality issues, automation problems, integration risks, and areas for improvement.

*Is Salesforce Health Check only about security? *

No. Security is important, but a broader Salesforce Health Check should also review data quality, reports, automation, integrations, performance, governance, release readiness, and user adoption.

*How often should you run a Salesforce Health Check? *

Many organisations should run a Salesforce Health Check at least once a year. It is also useful before major Salesforce changes, new integrations, process redesigns, Salesforce release updates, or a managed services engagement.

*What are common signs that Salesforce needs a Health Check? *

Common signs include inaccurate reports, duplicate data, manual workarounds, slow pages, complex Flows, broad user access, integration issues, and a growing Salesforce backlog.

What happens after a Salesforce Health Check?

The findings should be turned into a clear improvement plan. Some items may be quick wins, while others may become part of a longer roadmap for Salesforce optimisation, cleanup, governance, or managed services.

*Can a Salesforce Health Check support managed services? *

Yes. Salesforce Health Check findings can become a practical roadmap for ongoing Salesforce support, maintenance, cleanup, release readiness, and platform improvement.

Salesforce managed services: what happens after go-live?

Dorian Sabitov — Fri, 24 Jul 2026 09:52:05 +0000

Go-live is an important milestone, but it is not the end of the Salesforce journey.

In many companies, the real work starts after implementation. New users join the business. Sales, service, and marketing teams ask for changes. Reports need updates. Automations become harder to manage. Integrations need attention. Salesforce releases introduce new features and changes that should be reviewed before they affect daily work.

That is why Salesforce managed services matter.

They give companies a structured way to support, maintain, and improve Salesforce after go-live. Instead of waiting until something breaks, teams get access to the right expertise when they need it – from admin support and development work to integration support, release readiness, reporting improvements, and long-term platform optimisation. The original Spyrosoft article defines Salesforce managed services as ongoing support, maintenance, and improvement for companies that already use Salesforce.

What Salesforce managed services actually mean

Salesforce managed services are not just “someone fixing tickets”.

They are a support model for keeping Salesforce useful after implementation. In practice, this can include:

Salesforce admin support,
Salesforce development support,
integration support,
reporting and dashboard improvements,
automation updates,
release readiness,
user training,
platform optimisation.

The main idea is simple: Salesforce should not be treated as a one-time project. It is a business platform that changes together with the organisation. If the business changes but Salesforce does not, users start creating workarounds, reports lose accuracy, and the platform becomes harder to trust.

A common case is a sales process that worked well at launch. A few months later, users stop filling in key fields, managers complain about incomplete reports, and the sales team goes back to spreadsheets. The issue is not only technical. It is a sign that Salesforce needs regular review, support, and improvement.

Why support after implementation is so important

Even a well-built Salesforce org can become difficult to manage if no one owns its long-term health.

Small requests appear one by one. A field needs to be changed. A report no longer shows the right data. A Flow needs an update. An integration starts sending incomplete records. Each item may look small, but together they create a backlog that slows the whole team down.

This is where Salesforce managed services help. They give teams a way to review requests, prioritise work, fix problems properly, and keep Salesforce aligned with real business processes.

Imagine a customer service team that starts manually reassigning cases because routing rules no longer match the team structure. At first, it looks like a small workaround. Later, it affects response times, reporting accuracy, and team performance. With regular Salesforce platform support, the issue can be reviewed earlier, the routing logic can be updated, and the process can be documented before it becomes a larger operational problem.

Common Salesforce managed services models

Not every organisation needs the same support model.

Some companies need occasional help when a specific issue appears. Others need regular monthly capacity or a dedicated team that can manage the backlog, support users, and plan future improvements.

Common models include:

Ad-hoc support for occasional fixes and small configuration changes.
Monthly capacity for regular backlog work, reporting updates, Flows, and user requests.
Dedicated Salesforce team for companies with an ongoing roadmap.
SLA-based support for business-critical Salesforce environments.
Project plus managed services for companies that want support after implementation.

This flexibility is important because Salesforce work is rarely the same every month. One month, the priority may be admin support. Another month, the team may need development work, integration fixes, or architectural advice.

The original article also mentions Spyrosoft’s hourly package model, with the smallest package starting from 35 hours. This gives clients access to Salesforce expertise without maintaining and training every role internally.

What can be included in Salesforce managed services?

The exact scope depends on the company’s Salesforce setup, business goals, and internal capacity.

For some teams, managed services mainly mean admin support: users, permissions, reports, dashboards, layouts, and configuration. For others, the scope may include custom development, automation cleanup, integration monitoring, data quality improvements, release management, or architecture review.

This is especially useful when several departments use Salesforce. A small change in Sales Cloud can affect reporting. A new automation can influence Service Cloud processes. An integration issue can break data flow between Salesforce and another business system.

That is why managed services should not only close tickets. They should help companies understand how different parts of the platform work together. The goal is to keep Salesforce clean, connected, and useful for the people who work with it every day.

From reactive fixes to planned improvement

The real value of Salesforce managed services is not the number of tickets closed. It is making sure Salesforce continues to support real work after go-live.

When the platform is not reviewed regularly, small issues become normal. Users create workarounds. Reports lose accuracy. Admins spend more time reacting to urgent requests than improving the system. Salesforce may still be available, but it becomes harder to trust.

A good Salesforce support partner helps prevent this. The focus is not only on fixing what is broken, but also on understanding why the issue appeared and how to solve it in a cleaner way.

For companies, this can mean:

better control over the Salesforce backlog,
more reliable reporting,
fewer manual workarounds,
safer changes,
stronger user adoption,
access to Salesforce expertise without building a full in-house team,
better long-term scalability.

In short, managed services help Salesforce stay active, useful, and aligned with the business.

Final thoughts

Salesforce managed services are not only a support option. They are a practical way to protect the value of Salesforce after go-live.

If your backlog is growing, your internal team needs extra capacity, or your Salesforce org needs a clearer support model, it may be time to review how your platform is maintained.

I covered the main points here, but the full Spyrosoft article goes deeper into support models, service scope, business benefits, and how Spyrosoft approaches Salesforce managed services.

Read the full article here:

https://spyro-soft.com/blog/salesforce/salesforce-managed-services-streamline-the-business-by-keeping-your-platform-at-its-best

Q&A

*What are Salesforce managed services?
*
Salesforce managed services are ongoing support, maintenance, and improvement services for companies that already use Salesforce. They help keep the platform stable after go-live and support future business changes.

*What can Salesforce managed services include? *

They can include Salesforce admin support, development support, integration support, reporting improvements, automation updates, release readiness, user training, and long-term platform optimisation.

*Why do companies need Salesforce support after implementation? *

Because Salesforce changes together with the business. New requests, reports, Flows, integrations, and user needs can create a growing backlog if no one owns the platform’s long-term health.

*What support models are available? *

Companies can use different models depending on their needs, such as ad-hoc support, monthly capacity, a dedicated Salesforce team, SLA-based support, or project plus managed services. The right model depends on org size, user count, integration complexity, and how critical Salesforce is for daily work.

*Is Salesforce managed services only about fixing tickets? *

No. A good support model should not only close tickets. It should help the company understand how different parts of Salesforce work together and keep the platform clean, connected, and useful for daily work.

*When should a company consider Salesforce managed services? *

A company should consider managed services when the Salesforce backlog is growing, users create workarounds, reports lose accuracy, admins are overloaded, or the platform needs more regular improvement after go-live.

Why Standard Salesforce Related Lists Are Not Enough for Daily Work

Dorian Sabitov — Fri, 17 Apr 2026 13:06:08 +0000

Have you ever opened a Salesforce related list and felt that something was missing?

Maybe you wanted to update several records at once. Maybe you needed easier Salesforce inline editing. Or maybe you thought it would be useful to show image previews directly in the list.

The good news is that you do not need code to get features like that.

The process is simple. Find the right app, install it, and make a few quick configurations. That’s it. No code, only clicks, and free to install.

This matters because a standard Salesforce related list or Salesforce list view works well for basic display, but daily work usually needs more. Teams need to update records faster, filter data more easily, and spend less time opening records one by one.

Imagine a support manager getting ready for a customer call. They open an Account record and want to review related Cases, sort them by priority, and update a few statuses quickly. In a standard setup, even simple tasks can turn into extra clicks and wasted time.

That is exactly the gap Spyrosoft - Enhanced Related List is built to close.

Why Standard Related Lists Start to Feel Limiting

A standard Salesforce related list does its job when users only need a quick view of records. But once the list becomes part of daily work, the limits become much easier to notice.

The first issue is speed. If a user wants to update several records, review the most important ones first, or clean up data quickly, the standard setup often means more clicks than necessary. Open a record, make a change, go back, open the next one, and repeat. It is not difficult, but it is slow.

The second issue is visibility. A basic Salesforce list view does not always help users spot what matters right away. Important records do not stand out enough, filtering can feel limited, and working with larger sets of data becomes less practical.

This is why many teams start looking for features like Salesforce inline editing, Salesforce mass update, better filtering, and more flexible list management. They do not want a list that only shows data. They want a list that helps them work with it.

What Spyrosoft - Enhanced Related List Adds

Instead of treating a Salesforce related list as a simple place to view records, the app turns it into a more practical workspace. Users can do more directly on the page, without opening records one by one or asking for custom development.

The app includes two components: Sweet Related List and Sweet Object List View. Together, they help improve both related record sections and standard object-based lists in Salesforce.

What makes it useful is not just one feature, but the combination of them. Teams get Salesforce inline editing, Salesforce mass update, advanced filtering, multi-column sorting, export options, conditional formatting, and even image preview in list rows. In other words, the list becomes something users can actually work from, not just look at.

For admins, the setup is also simple. The components are configured with clicks, not code, which makes the app easier to roll out and easier to manage.

Two Components, Two Use Cases

The app includes two components, and each solves a slightly different problem.

Sweet Related List is used when you want to improve a Salesforce related list on a record page. For example, you can use it on an Account page to work with related Contacts, Cases, Opportunities, or other related records in a more practical way.

Sweet Object List View is used when you want to show records from a standard or custom object in a more flexible format. This is useful when a basic Salesforce list view is not enough and the team needs more control over sorting, filtering, editing, and display.

This split is useful because not every team works with data in the same way. Some users need a better way to manage related records directly on the page. Others need a stronger object-based view that acts more like a working area than a static list.

In both cases, the goal is the same: fewer clicks, better visibility, and a more useful list experience inside Salesforce.

Features That Make the Biggest Difference

The real value of the app comes from the way its features support daily work inside Salesforce.

Salesforce inline editing makes quick updates much easier. Instead of opening each record one by one, users can edit values directly in the list and save changes faster.

Salesforce mass update is another big improvement. When several records need the same change, users can select them and update multiple fields at once. This is especially useful for sales, support, and operations teams that work with larger sets of data.

Salesforce conditional formatting helps users spot important records faster. Instead of scanning every row manually, they can highlight records based on rules, which makes the list easier to read and easier to use.

The app also supports advanced filtering and multi-column sorting, so users can focus on the right records without extra steps. And when data needs to be reviewed outside Salesforce, Salesforce export list view options make it easy to export records to Excel or CSV.

Another useful addition is image preview in URL fields. This can make certain lists much easier to scan, especially when visuals matter.

Taken together, these features turn a standard list into something far more practical for real work.

Why This Matters for Admins and Business Teams

For business teams, the value is simple: less time spent clicking through records and more time working with data. A better Salesforce related list helps users review, update, and organize information faster, which makes daily work smoother.

For admins, the benefit is also clear. The app does not require code, so it is easier to install, configure, and maintain. The same setup can be reused across different pages, which saves time and keeps the experience more consistent.

This matters because many Salesforce improvements sound useful in theory but take too much effort to roll out. Here, the balance is different. Teams get more practical features like Salesforce inline editing, Salesforce mass update, and better filtering, while admins keep the setup simple.

That is what makes the app useful in real projects. It improves the experience for end users without creating extra complexity for the people who manage Salesforce.

Get Started

If your team works with related lists every day, this is a simple way to make Salesforce more useful without adding extra complexity. You can explore the app for free here:

Get Spyrosoft - Enhanced Related List on AppExchange:
https://appexchange.salesforce.com/appxListingDetail?listingId=4d2a7ed2-9d38-4cbf-9ab9-d8b6522515f5&tab=d

If you have any questions about the app or Salesforce, feel free to contact me at doi@spyro-soft.com or visit our homepage:

https://spyro-soft.com/services/salesforce