#Salesforce Admin368 utenti parlano di questo argomento

Hi Guilherme,

If the Contact Point App DMO mapping is already configured, I’d check the data ingestion and identity resolution side next. Make sure the required contact/app identifiers are populated and that the contact is correctly unified with the Contact Point App record. 

I’d also verify that the mobile app is properly configured for push notifications and that the test user/device is registered and associated with the expected contact. If the DMO is still not receiving records, checking the ingestion/mapping status and any Data Cloud processing errors should help identify where the data flow is stopping. 

If you can share the DMO mapping, the fields you’re populating for the test contact, and any errors shown during ingestion or testing, it would be easier to pinpoint the missing configuration. 

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.

Hi Jim, sorry to hear about the near-miss — sounds like it was close. 

Good news: Productivity and Collaboration is officially only 7% of the exam (per the Salesforce Admin Exam Guide), so it's a small, well-defined target, not something you need 138 modules for. It covers exactly four learning objectives: 

- Activity Management (Tasks, Events, activity reminders/reports) 

- Chatter (feed, groups — public/private/unlisted, following, security) 

- Salesforce Mobile App capabilities 

- AgentExchange/Agentforce use cases 

That last bullet explains why Agentforce and Productivity/Collaboration are both weak spots for you at once — Salesforce folded AgentExchange/Agentforce use-case questions into this same exam section on the current version of the guide, so it's really one combined content area, not two separate ones. 

Best single resource: the official Trailhead module "Study Up on Activity Management and Collaboration" — it's built specifically to prep this exact exam section (not general Trailhead content), and includes scenario questions and flashcards on Chatter, activities, and mobile app capabilities: 

Since you've already done beginner/intermediate + general exam prep, this targeted module (30–45 min) plus the flashcards should be enough without re-covering ground you already know — focus your remaining study time on Configuration & Setup and Security & Access instead, since those carry roughly double the exam weight of Productivity and Collaboration and are worth more of your remaining prep time per point.

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. 

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.

Hi Shezeen, congrats on Platform Foundations! 

Official next step, straight from Salesforce's own credential map: Platform Foundations is designed to lead into Salesforce Certified Administrator. That's the natural next milestone since Foundations covers reporting, user admin, data management, customization, and sharing at a conceptual level — Admin builds on exactly that with hands-on configuration depth. 

Trailhead has a purpose-built trailmix for this: search "Prepare for Your Salesforce Administrator Credential" in Trailhead — it's the official study path Salesforce curates for this exact transition. 

Two other paths worth knowing about depending on where you want to go: 

- If you're more drawn to app/UI building than admin config: Platform App Builder has no prerequisites and can be taken instead of or alongside Admin. 

- If you want to lean into where Salesforce is investing most right now: the AI Associate certification is free through 2026 and a natural add-on after Admin — it's positioned as the entry point before Agentforce Specialist if you want to move toward AI/Agentforce work later. 

Realistic default if you're unsure: Admin next, then decide between App Builder (declarative/builder track) or AI Associate → Agentforce Specialist (AI track) based on what you enjoyed more in Foundations.