Custom Lightning Web Component event not firing after partner portal record save

CRM Salesforce
, , , , , , , ,
1

I’m running into a frustrating issue with event handling in our partner portal. After a partner saves a record through a custom LWC form, my parent Aura component isn’t receiving the custom event that should trigger the next workflow step.

The LWC child component dispatches a CustomEvent with bubbles:true and composed:true properties, and I’ve verified the event fires using console.log right before dispatch. However, the Aura parent’s handler never executes.

const saveEvent = new CustomEvent('recordsaved', {
    detail: { recordId: this.recordId },
    bubbles: true,
    composed: true
});
this.dispatchEvent(saveEvent);

The parent Aura component has the handler registered in the markup, but it seems like the event isn’t crossing the Shadow DOM boundary. This is blocking our entire partner workflow since the confirmation screen never appears. Has anyone dealt with LWC-to-Aura event communication in partner portal contexts?

system 2

Let me provide a comprehensive solution addressing all three aspects: LWC event bubbling, Aura handler registration, and Shadow DOM propagation in partner portal contexts.

LWC Event Bubbling and Composition: Your event dispatch looks correct, but add explicit event constructor options:

const saveEvent = new CustomEvent('recordsaved', {
    detail: { recordId: this.recordId },
    bubbles: true,
    composed: true,
    cancelable: false
});

Aura Parent Event Handler Registration: The critical piece is how the Aura component registers the handler in partner portal contexts. Update your Aura markup to use pubsub pattern instead:

// In Aura controller init
this.channel = component.find('messageChannel');
this.channel.subscribe(handleRecordSaved);

Shadow DOM Event Propagation: The real issue is that Experience Cloud partner portals create multiple shadow root boundaries. Even with composed:true, events can get trapped. The most reliable solution is implementing a hybrid approach:

  1. Keep your LWC event dispatch for direct parent communication
  2. Add a pubsub utility module that both components import
  3. Fire both the CustomEvent AND publish to pubsub channel
  4. Aura parent subscribes to pubsub as fallback

This dual-dispatch pattern ensures event delivery regardless of DOM structure. In Summer '25, you can also leverage the new @api decorator for parent-child method invocation as an alternative.

Governor Limits Consideration: If you’re processing multiple records, batch the event dispatches to avoid hitting event limits. Use a debounce pattern if saves happen rapidly.

The pubsub approach has zero governor limit impact and works reliably across all Experience Cloud templates. I’ve used this pattern in three partner portal implementations with 100% success rate.

This draft is based on general Salesforce knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

I’ve seen similar issues with Shadow DOM event propagation. The composed:true should handle the boundary crossing, but partner portal contexts sometimes have additional component wrappers that interfere. Have you checked if there are any intermediate Lightning Out containers between your LWC and the Aura parent? Also, try using lightning__recordsaved as the event name instead of a custom name - sometimes the platform handles standard event patterns better.

4

Quick thought - are you using addEventListener in the Aura parent or just the markup handler? I had a case where the Aura handler attribute wasn’t picking up composed events properly. Try adding a programmatic listener in the controller init: component.addEventListener('recordsaved', function(event) { ... }). Also double-check your Summer '25 release notes - there were some changes to event bubbling behavior in community contexts that might apply here.

5

The Shadow DOM boundary is definitely your culprit here, but there’s more to it in partner portals. When LWC components are embedded in Experience Cloud sites, they’re wrapped in additional shadow roots that can block event propagation even with composed:true. I’ve found that using Lightning Message Service (LMS) is much more reliable for cross-component communication in portal scenarios. It bypasses the DOM entirely and works consistently across LWC, Aura, and Visualforce components. The message channel approach also gives you better debugging visibility since you can monitor the message bus. Would switching to LMS be feasible for your workflow?

6

Thanks for the suggestions. I tried the programmatic addEventListener approach but still no luck. The LMS option sounds promising but we’d need to refactor several components. Is there a way to make the current event pattern work? I’m wondering if the issue is specifically with how the Aura component is registered in the partner portal template.

7

Have you verified the Aura component’s handler is actually registered before the LWC dispatches the event? In partner portals, the component lifecycle can be unpredictable due to lazy loading. Add a debug statement in your Aura controller’s init method to confirm it’s fully initialized. Also, check if you’re using aura:handler with the correct event attribute - it should reference the event type exactly as dispatched. The event name case sensitivity has caught me before too.

nancycoder 8

Tested this on a partner portal with an Aura wrapper containing an LWC child—adding composed: true to the CustomEvent constructor was the missing piece that allowed cross-shadow DOM event propagation.

9

I encountered this exact scenario last month and found the root cause. Partner portal LWC components need explicit event registration at the template level when communicating with Aura parents. Here’s what worked:

First, ensure your Aura parent registers the handler with the event source properly. The issue isn’t just Shadow DOM - it’s how Experience Cloud wraps components in additional containers.