Experience Cloud customer and partner portals

Start with the task people need to complete

A portal earns adoption when it replaces a frustrating exchange: a dealer checking an order, a customer following a case, or a partner submitting a qualified opportunity. A branded home page alone does not remove the repeated email, spreadsheet or telephone call. Emerge designs Experience Cloud around a small set of useful external journeys and the Salesforce records that support them.

We identify the external audiences, the organisations they belong to and the decisions they are allowed to make. Customer self-service and partner collaboration can have different identity, sharing and approval requirements. Those distinctions are established before choosing a template or adding content, with licence and feature fit confirmed for the intended users.

Model external access deliberately

An external user may represent an individual customer, a dealer location or several related accounts. We define how that relationship is established, reviewed and revoked. An email domain by itself is rarely sufficient evidence of authority to see every record belonging to a company.

Record visibility is designed alongside the portal task. A partner may need to see an opportunity they introduced without seeing another partner’s pipeline. A customer may view a case but not internal investigation notes. An order summary can expose status while keeping commercial terms or personal details restricted. We document these distinctions in an access matrix that business owners can review.

The identity journey includes invitation, first sign-in, forgotten access, role changes and departure. A portal can appear secure during a successful demonstration while failing when a user changes organisations or an administrator removes a relationship. Those lifecycle events are part of implementation and acceptance.

An illustrative dealer collaboration journey

A dealer signs in and selects the account context they are authorised to represent. They can review approved product information, submit an enquiry or opportunity, and follow the status of a related order. Required fields are tailored to the receiving sales or operations team so submissions arrive ready for action.

Salesforce records the submission with the partner’s identity and source context. An internal owner accepts or requests clarification, and the portal displays an appropriate status. If order details come from an ERP or commerce platform, a controlled interface retrieves or publishes the permitted view. Delayed data is labelled with its freshness rather than presented as a live commitment.

When a dealer needs help, the portal starts a case with relevant account and order context. Attachments and comments follow the same audience rules as the underlying record. Internal escalation remains visible to staff without disclosing restricted notes to the external audience. This is an illustrative workflow; the exact data and permissions follow the organisation’s operating model.

Balance experience with maintainable configuration

We define a content model and reusable page patterns for the priority tasks. Accessibility, mobile layouts, navigation and search are reviewed using the language customers and partners actually use. Public educational content and authenticated account information need different indexing and caching behaviour.

Customisation is assessed against its maintenance cost. A distinctive interface can be appropriate, but it should not obscure the supported identity and record-sharing mechanisms. Integration boundaries and component responsibilities are documented so a later release can change presentation without silently changing access.

Content also needs an operating owner. Product documents, onboarding instructions and service guidance can become misleading when they outlive a commercial change. We include review and retirement rules, and distinguish a document download from a transactional action that changes a business record.

Test isolation and completion, not only appearance

Acceptance includes at least two unrelated external organisations and the internal roles that support them. Tests attempt to reach records outside each user’s permitted scope through navigation, direct links and the application interfaces used by the portal. Removed access and changed account relationships are tested explicitly.

Functional journeys cover a successful submission, missing information, a duplicate request, a delayed source system and a failed attachment. The receiving team verifies that the resulting record is usable and owned. The customer-facing confirmation must match the actual state of the transaction.

We pilot with a defined audience and review whether the portal reduces the manual exchange it was intended to replace. Task completion and support questions provide more useful feedback than page views alone. The rollout includes a support route for users who cannot sign in or cannot find the right account context.

Give the portal an owner after launch

The handover covers external-user administration, sharing rules, content stewardship, integration monitoring and release procedures. Business teams know who approves new journeys and how a change to the internal data model could affect external visibility.

A useful first engagement selects one customer or partner task with clear demand. Emerge turns it into an accessible portal journey, a reviewed access model and a tested handover into the operating team that fulfils the request.