A portal nobody uses costs more than no portal at all.

Yes, it is the same product renamed. It has been Salesforce Communities, then Community Cloud, and is now Experience Cloud, so all three names still appear in older documentation and job specs. It is Salesforce's digital experience platform: branded portals, communities and self-service sites built directly on your Salesforce data. Common uses are partner portals for deal registration and lead distribution, customer self-service hubs for logging and tracking cases, and dealer or employee portals for distributed teams. The distinguishing characteristic is that it is native — a portal action creates a real CRM record rather than a copy that has to be synchronised.

Not urgently, and be sceptical of anyone who says otherwise. Salesforce has not announced a retirement date for Aura, and both runtimes were still receiving features in the Spring '26 and Summer '26 releases. What has changed is direction: Aura is effectively in maintenance, receiving fixes rather than new capability, while framework investment goes to Lightning Web Components and LWR gets new portal features first. So the real questions are whether your site is public and needs to rank in search, whether page performance is costing you adoption, and whether you want portal AI capability in the next year or two. Salesforce now ships component-level Aura-to-LWC migration tooling, which helps, but it migrates components rather than whole sites — so the effort is real. We produce a migration readiness assessment and effort estimate so the decision is made on a number.

A focused portal — a customer self-service site or partner community on standard components with moderate customisation — typically runs 6 to 10 weeks. A fully custom LWR build with bespoke branded design, Agentforce deployment, complex permission architecture and deep CRM or external integration typically runs 12 to 20 weeks. Enterprise environments with several portal types, large external user populations or multiple external system integrations extend further. The biggest single driver of timeline is the permission model: a simple single-audience portal is quick, while account-based isolation across a multi-tier partner network is not.

Usually yes, and this is our most common Experience Cloud engagement. Low adoption is almost never caused by the platform. It is caused by navigation that does not match how the user thinks, too many clicks to reach the one thing they came for, a permission model that hides data people need or exposes data they should not see, or a CRM sync they have learned not to trust. We audit the architecture, permission model, integration health, component quality and content structure, then fix the four to six root causes behind the drop-off — usually without disrupting the users who have started relying on the portal. A full rebuild is warranted only when the object or sharing model cannot represent the audience you now serve.

Configuration covers the site setup and theming, navigation, standard components, Salesforce CMS content structure, the whole external permission architecture, object and field exposure, and the CRM object mapping — which is a great deal of what a portal needs. Custom development starts when a workflow needs a screen Salesforce does not ship, such as a deal registration wizard with conditional logic or a knowledge search with taxonomy filtering, when external system data must be surfaced inside a portal page, or when an Aura component has to be rebuilt as a Lightning Web Component. This boundary arrives earlier on Experience Cloud than on most Salesforce products, because LWR ships a smaller standard component set than Aura did. We identify at design time which screens will need custom components, so it is in the scope rather than discovered halfway through the build.

Through account-based data isolation, which is designed and tested as its own phase before any UI work begins. The building blocks are external user profiles and permission sets, organisation-wide default settings for external users, sharing sets that grant access based on the user's account, sharing rules for the cases those do not cover, and component-level visibility controls for what appears on a page. Getting this right is the most technically demanding part of an Experience Cloud build and the most common source of post-launch incidents, in both directions — partners seeing another partner's pipeline, or partners locked out of their own records. We test the model against every edge case, including the awkward ones like a contact who works for two partner accounts, before a single external user is invited.

Inside Salesforce it is not really integration at all — it is direct object access. A case logged in the portal is a Service Cloud case immediately; a deal registered by a partner is a Sales Cloud opportunity immediately. There is no connector and no sync interval, which is the main architectural reason to choose Experience Cloud over a standalone portal bolted onto Salesforce by API. For systems outside Salesforce — ERP data, billing platforms, product usage or an external identity provider — we use MuleSoft, Workato, Celigo or direct REST integration depending on data volume and what middleware you already own. That external layer is designed for real-time reads where a user is waiting on the page, and for resilient asynchronous handling where they are not.