#Salesforce Developer388 debatiendo

Hi @Akhilesh Prajapati

This is Account Engagement (Pardot) territory. The infinite spinner on 

Account Engagement Settings → User Management → Users is a known symptom pattern, almost always tracing back to the Salesforce↔Pardot connector/session layer rather than an actual "Users" bug. I checked the linked community thread it has 0 replies, so no prior resolution to build on there.

Here's the diagnostic order I'd work through, most-likely-cause first:

1. Check Connector authentication statusGo to Account Engagement Settings → Connectors and check the Salesforce connector's status. If it shows an auth error (commonly surfaces as Pardot API Error 184 authentication failure), that alone is enough to hang User Management, since that page pulls live data through the connector session. Reauthenticate the connector user if it's broken.
2. Confirm the connector user still has correct accessThe user account the Salesforce Pardot connector runs as needs an active Salesforce license, System Administrator (or equivalent) profile, and the Account Engagement Administrator role in Pardot. If that user was deactivated, had their profile changed, or lost the Pardot role assignment, the connector silently fails and pages like this spin forever instead of erroring cleanly.
3. Rule out browser-side blocking (very common cause)Account Engagement Settings loads inside a Salesforce Canvas app (an iframe calling out to Pardot's API). Third party cookie blocking (Safari/Chrome privacy settings), ad blockers, or browser extensions frequently break this silently. Test in an incognito/private window with extensions disabled, and try a different browser entirely before assuming it's a config issue.
4. Check Session Settings for Clickjack Protection / IP restrictionsIn Salesforce Setup → Session Settings, aggressive Clickjack Protection settings or 'Lock sessions to the IP address from which they originated' can block the Canvas iframe from completing its callout. Also check Login IP Ranges on the connector user's profile if Pardot's servers aren't whitelisted, the callout can hang rather than fail visibly.
5. Check for multiple Business UnitsIf this org has more than one Account Engagement Business Unit, User Management can hang if the specific Business Unit context is ambiguous or misconfigured for the logged-in user. Confirm which Business Unit the affected admin is scoped to, and that their Salesforce profile maps correctly to it under Business Unit Setup.
6. Escalate to Salesforce Support with the network traceIf all of the above check out, open a case with Salesforce Support (this is a Pardot/Account Engagement product issue, not something fixable via Apex/Flow/config alone). Capture a browser dev-tools Network tab trace of the failed page load first the failing XHR call to Pardot's API will usually show the real error code even though the UI just shows a spinner.

Quickest first move: step 1 (Connectors auth status) and step 3 (incognito/different browser) these two catch the majority of real-world cases of this exact symptom. If the connector shows green/authenticated and it still hangs in a clean browser, jump to step 4 (Session Settings) before assuming it needs a Support case.

I hope you find the above information helpful. If it does, Please mark it as Best Answer to help others too.

The behavior points more toward a voice-channel serialization or rendering issue with the Custom Lightning Type rather than the Apex action itself. Since the same action works through text and succeeds when the CLT is removed, I’d isolate the CLT schema and test a simple structured output first, then add fields back one at a time. I’d also check the voice action payload and supported output types in Enhanced Chat v2. 

For related troubleshooting discussions, community resources and practical solutions, these types of developer communities can also be useful references.

Hi Lena, 

Yes, removing API Enabled would impact the Salesforce Mobile App, since the mobile app requires API access. So I wouldn’t use that permission alone as the control for this requirement.  

A better approach is to keep API access for the users who need Salesforce Mobile and use API Access Control to restrict API access to only approved/allowlisted connected apps. Salesforce supports this model specifically for limiting API access while allowing approved apps.  

For report extraction, also control the Export Reports permission separately. Removing that permission prevents users from exporting report data, while folder sharing and report/dashboard permissions can be used to restrict access to sensitive content. 

I’d therefore treat this as multiple layers: API Access Control + Report/Folder permissions + Export Reports + subscription/access controls, rather than disabling API access entirely. 

Manual and Free Method: Convert MBOX to PDF using Thunderbird

1. Install Thunderbird: Download and open Mozilla Thunderbird (it’s free and open-source).
2. Add the Extension:
   • Go to Tools / Settings $\rightarrow$ Add-ons & Themes.
   • Search for ImportExportTools NG and click Add to Thunderbird.
3. Import MBOX Files:
   • Right-click on Local Folders in the left sidebar.
   • Select ImportExportTools NG $\rightarrow$ Import mbox file.
   • Choose Import directly one or more mbox files and select your files.
4. Export to PDF:
   • Once imported, right-click the folder containing your emails.
   • Go to ImportExportTools NG $\rightarrow$ Export all messages in the folder $\rightarrow$ PDF format.
   • Select a location on your computer to save the converted PDFs.

Note: While free, manual methods can be slow for very large batches, and attachments are usually saved alongside or embedded depending on your export settings.

Also if you want a dedicated automated solution that simplifies bulk processing and ensures all attachments remain intact without needing client setups, you can also check out the Kernel Email to PDF Converter to get the job done.

You’re correct that there isn’t a direct trigger point here. ProcessInstanceWorkitem doesn’t support Apex triggers or record-triggered flows, and reassigning the approval doesn’t update the Case itself. 

If you need to keep the standard Reassign action, I’d handle it with scheduled Apex:

1.  Run a scheduled job every few minutes. 
2.  Query new ProcessInstanceStep records where StepStatus = 'Reassigned'. 
3.  Use ProcessInstance.TargetObjectId to identify the related Case. 
4.  Query the pending ProcessInstanceWorkitem for that process instance to get the newly assigned ActorId. 
5.  Insert a FeedItem with the Case ID as ParentId. 
6.  Store the processed ProcessInstanceStep.Id in a small custom log object with a unique/external-ID field. 
7.  Skip any step already in that log so rerunning the job can’t create duplicate Chatter posts. 

I’d also test it by reassigning the same approval twice and then running the job twice. The expected result should be two Chatter posts total, with no additional posts from the second job run. 

If real-time posting is absolutely required, the other option is to replace the standard Reassign experience with a custom Flow/LWC backed by Apex. That custom action would update ProcessInstanceWorkitem.ActorId and create the Case FeedItem in the same transaction. But the existing standard Reassign action can’t be intercepted directly.