Salesforce Experience Cloud

CRM is designed primarily for a company's employees.

A portal has completely different users, goals and ways of being used.

A customer should not have to wonder which Salesforce object a piece of information comes from. They should know where to find a document, status or history and how to carry out the action they need.

That is why we treat Experience Cloud as a separate digital product, with its own UX, information architecture, navigation, design and permissions model. Salesforce data and processes sit underneath.

In one of our projects, we modernized a loyalty portal based on Salesforce Experience Cloud.

The project included rebuilding the frontend, moving from Aura components to LWC, introducing a new design and creating a custom theme.

The portal gave users access to loyalty programme and self-service functions.

In solutions like this, it is particularly important that the interface meets the standards users know from other digital services.

A loyalty programme can have sound data and processes, but if the portal is hard to use, good adoption is unlikely.

Not every project requires building a portal from scratch.

Often the bigger problem is an existing solution developed over many years: older Aura components, custom code, a design that needs rebuilding and a growing cost for every subsequent change.

We do not, however, begin with the assumption that all legacy code must be rewritten.

First, we check which elements still work well and can stay as they are, which need business changes, and which genuinely hinder development and should be rebuilt.

Modernization is a technical and business decision, not a project to rewrite as many components as possible.

Velocity can handle the full UX/UI process for Experience Cloud: user journeys, information architecture, screen designs, responsive UI, design and a custom theme. We can also work from a design supplied by the client.

In self-service portals, UX has a direct business impact. If users cannot find the information they need on their own, they will still contact support - regardless of how many functions the portal technically offers.

Experience Cloud can also serve as a layer for partners, distributors and other business users.

In this case, the permissions model becomes particularly important.

One person may see data for the whole company, another only their own cases, and someone else may be allowed to approve certain operations.

That is why we design data access together with the process, rather than as a final configuration step.

If you need a public marketing site without login or a connection to Salesforce, simpler solutions exist.

If the portal does not use Salesforce data or processes at all, it is worth checking whether tying it to Experience Cloud provides real value.

If core CRM processes are inconsistent, data is incomplete and ownership is unclear, it is better to put the foundations in order first. A portal built on such a system would only expose those problems to external users.