Feed

Hi Snigdha, 

It looks like your flow is being triggered, but the call to the Prompt Builder template is failing.

Since the error mentions a "Network error during Prompt Engine callout, I'd suggest checking a few things:

1. Prompt Template: Make sure your translation template is activated. Try testing it directly in Prompt Builder to see if it's generating a response.
2. Flow Configuration: Check the "Translate Fitness Survey Input" flow and confirm that the prompt template action and input mappings are configured correctly.
3. Einstein Generative AI: Verify that Einstein Generative AI is enabled and you have the required permissions.
4. Debug Logs: Check the failed flow interview or debug logs to see if there's any additional information about the error.

I'd recommend testing the prompt template directly first. If it works there but fails through the flow, you can focus on the flow configuration.

If the template itself is also failing despite everything being configured correctly, it could be a temporary issue with Salesforce's Prompt Engine service.

 I'm also sharing a video that walks through the process. Hopefully, it helps you identify what's causing the issue.  

Hi, 

Looking at your screenshots, both fields seem to be created correctly and are already added to the page layout. 

A few things I'd suggest checking:

1. Lightning Record Page: Go to Object Manager → Energy Audit → Lightning Record Pages. If Dynamic Forms are enabled, make sure both fields are included in the relevant field sections.
2. Action Layout: Check under Buttons, Links, and Actions to see if a custom New action is being used. If so, check its layout, as it can be different from the standard page layout.
3. Field-Level Security: Make sure both fields are visible to your profile.
4. Feed Tracking: Since the challenge isn't recognizing Audit Notes, I'd also check Setup → Feed Tracking → Energy Audit and confirm whether Feed Tracking is enabled and Audit Notes is selected, if required by the challenge. 
    

You can also refer to this Salesforce article for more details: 

Hello @Palash Das make sure to look in the L section of the available permission sets. DevOps Center Admin permission is now Lifecycle Center Admin permission, as shown below in this screenshot :Eric

@Steeve ORGAWITZ

1. Yes, this is a known pattern after EAC reconnection. When a user reconnects, EAC re-establishes its sync baseline and re-pushes its stored version of events back out. Because the organiser is the user, Exchange treats each rewrite as a legitimate update and notifies every attendee. The timezone/body-only change rewriting 6 months of meetings is the classic signature. You’re not misreading it.
2. Reducing the re-sync window is the key lever. EAC syncs events within a configured time range, and past events outside that window aren’t re-pushed. In your EAC configuration, check the sync timeframe setting for events. If it’s set to sync a wide historical window, narrowing it so EAC only syncs recent and future events dramatically limits what gets rewritten on reconnect. You generally don’t need EAC rewriting April’s meetings anyway. Tightening that window before any mass reconnect is the single most effective prevention. A full reconnect with no past-event sync isn’t really exposed as a clean toggle, but narrowing the event sync window gets you most of the way there.
3. The mitigation is to control the reconnection itself, not suppress notifications after the fact.

Narrow the event sync window first (above), then have users reconnect. Far fewer events in scope means far fewer rewrites.

Your testing makes sense, Rhonda. This is a race condition with Wait elements on Platform Events: a paused interview only picks up events published after it reaches the Wait. If the third DPE finishes and publishes its event before the flow gets to the Wait, the event is missed and only the timeout path can move the flow forward. 

Two good ways forward: 

1. Keep your build and shorten the timeout. A 2-hour timeout is a reasonable safety net, as long as it's comfortably longer than your longest DPE run. Check a few run durations in Data Processing Engine monitoring and add some buffer. 

2. Replace the Wait with a separate platform event-triggered flow that subscribes to the completion event and runs the final step. This never misses the event, because it doesn't depend on a paused interview already listening. 

If option 1 gives you the results you need, it's fine. The only cost is a small delay and some paused interviews. Good call flagging the documentation with Salesforce.