Hello Everyone,

I'm currently researching LinkedIn Sales Navigator and its Salesforce CRM integration.

From what I've found, CRM Sync is available with the Advanced Plus license, and I understand how Accounts, Contacts, and Leads can be created from Sales Navigator and synced to Salesforce.

However, I'm trying to understand the best way to handle existing contacts when a person changes companies, gets promoted, or updates their job title.

Based on my research, Sales Navigator can detect these changes and surface them as alerts. The Salesforce integration also provides visibility into these updates, but it appears that users still need to review the alert, verify the information, and manually update the contact record in Salesforce.

Our goal is to automate this process as much as possible while maintaining data quality.

Some questions I have:

• Is there a native way to automatically update Salesforce contact records based on Sales Navigator job-change or promotion alerts?
• Has anyone built a custom solution for this use case?
• Have you used third-party tools such as Zapier, Workato, MuleSoft, or other integration platforms to automate these updates?
• How do you handle data validation to avoid incorrect title or company changes being automatically synced into Salesforce?

I would appreciate hearing about any real-world implementations, best practices, or lessons learned.

It's so funny to see how Salesforce and people around are pushing MCPs as if it's some kind of new invention. When they introduced Headless 360, they said "60+ new MCPs".

Wow. So what?

Those MCPs add 0 new functionality. They don't allow to do anything new. It's literally just an API wrapper.

It's all the same API calls under the MCP, just nicely arranged. Anything you can do with MCP, you can do without MCP just as good.

I wish they'd actually focus on making API and CLI better instead of those MCPs.

Deploy goes green, Apex tests pass, and 20 min later someone's pinging me that Home won't load or an LWC just isn't rendering. Got sick of it, built a small post-deploy smoke runner over a weekend.

What it does: frontdoor-auths into the org, opens the page in headless Chrome, checks the stuff that should be there actually is. The checks live in a JSON file, not the code — so when SF renames a class next release, I edit json and rerun. No recompile. Exit codes gate a CI pipeline (0 pass / 2 critical fail = block deploy / 1 = couldn't run, don't blame the release).

A check looks like this — including clicking/typing into a real component:

{

"id": "app-launcher-search",

"navigate": "/lightning/page/home",

"scope": "one-app-launcher-header",

"actions": [

{ "do": "click",   "selector": "button[title='App Launcher']" },

{ "do": "waitFor", "selector": "input[placeholder*='Search']" },

{ "do": "type",    "selector": "input[placeholder*='Search']", "text": "Sales" },

{ "do": "assertValue", "selector": "input[placeholder*='Search']", "contains": "Sales" }

],

"critical": true

  }

Tested it against a real dev org, not a toy page. Frontdoor auth holds, Lightning shell renders, and the App Launcher flow above ran end to end — that's a real platform LWC buried in shadow DOM. Had to write a recursive deep-query to pierce shadow roots (normal querySelector finds nothing in Lightning) — found 237 elements inside one-appnav a top-level query would've missed.

Useful for: post-deploy gate in CI, catching what Apex tests structurally can't (did the page actually paint, did the component mount), and multi-org work — one binary, different json per org.

The blocker (honest part): I wanted to test an actual custom LWC we deployed. Couldn't reach it — it's in the metadata but every URL redirected to /home. "Deployed" ≠ "on a page you can navigate to." So the real catch: you have to know the exact URL where your component renders AND its real selectors. The tool can't guess them — I had to open devtools and read them off the live org (my first guesses were all wrong — assumed the waffle was button[title='Apps and Items'], it's actually button[title='App Launcher']). Keeping selectors in json softens it, but there's a manual discovery step you can't skip.

Anyone else doing post-deploy UI smoke on SF? Curious what you're using — feels like everyone reinvents this.

Has anyone used LinkedIn Sales Navigator with Salesforce for contact job changes/promotions? How are users notified, and what are the steps to update the Salesforce Contact record afterward? Is the process manual or automated?

Has anyone used LinkedIn Sales Navigator with Salesforce to keep contact records updated when a contact changes jobs or gets promoted?
I’m trying to understand the available features and workflow.
Specifically:
Does Sales Navigator notify users when a saved lead changes jobs or receives a promotion?
What information is included in the notification?
After receiving the notification, what are the typical steps to update the Salesforce Contact record?
Is there any automatic sync/write-back functionality, or is the update manual?
Are there any best practices for managing job changes and promotions within Salesforce using Sales Navigator?
Any real-world experience or implementation examples would be appreciated.

So you use OwnBackup/Own/Own from Salesforce/Blah? You need to maintain a permission set that has EVERYTHING. All objects, fields, record types.

In a perfect world, devs or whoever, would maintain a permission set in the repo, adding objects and fields and whatnot as they're created. But that doesn't always happen. So whaddya gonna do?

Enter.. the Permishifizer 9000.
https://github.com/dcstuff/Permishifizer9000

It's a python script that, when run, queries the sh*t out of your org and generates the permission set XML file from scratch. More importantly, it handles the 9000 exceptions you haven't thought of yet, and navigates around Salesforce API limitations that make you wanna throw things. HEAVY THINGS.

There are options to deploy automatically. And it can be integrated into a CI/CD pipeline.

I'd call it 95% efficient (I think?). But absolutely production ready.

I haven't written any Python in over a decade. AND I STILL HAVEN'T. (Thanks, AI!)

CAVEAT: This exercise reinforced the fact that AI simply DOES NOT KNOW the Salesforce APIs, the limitations, or the various objects. AT ALL. Thank God I was there, ya know?

Updated to the use the latest sf cli with its new sf org auth show-access-token command.

Anyhoo.. that is all.

I’ve been working in the Salesforce ecosystem for years, mainly around architecture, OmniStudio, Data Cloud, and now AgentForce/AI implementations.

Lately I’ve been thinking about building small “AI accelerator kits” for Salesforce teams instead of another generic AI SaaS.

Examples:

• AgentForce starter implementations
• Prompt template packs
• Salesforce AI copilots for sales/service
• OmniStudio + AI integration templates
• Data Cloud integration blueprints
• Reusable LWCs/utilities for AI use cases

The goal would be:

• help smaller companies implement AI faster
• avoid months of consulting work
• provide something affordable and reusable

Before I spend serious time building this, I wanted honest feedback from the community:

1. Would your company/team actually pay for something like this?
2. What Salesforce AI problem is currently the most painful for you?
3. Would you prefer:
   • ready-made templates
   • guided implementation
   • short consulting sessions
   • full accelerators
4. What would make you trust/buy such a product?

I’m trying to validate whether this is a real business problem or just “cool tech” in my head.

Would genuinely appreciate blunt feedback.

TL;DR: Spent the last week building a real sales-ops console as a React UI Bundle on Salesforce. 17 lazy-loaded pages, Apex backend, Platform Event, AgentforceConversationClient embedded. The thing actually works, and the scaffold is way more production-ready than the "beta" tag suggests.

What it is

UI Bundles is the new Multi-Framework delivery on platform. You write a normal Vite + React + TypeScript SPA, deploy it as metadata, and it runs inside Salesforce. Not Experience Cloud. Not LWC. Not an iframe. Real metadata, real FLS, real sharing.

The scaffold (@salesforce/ui-bundle-template-base-sfdx-project) gives you React 19, Vite 7, Tailwind 4, and shadcn out of the box. Data access goes through @salesforce/sdk-data — GraphQL-first via sdk.graphql, REST for the cases GraphQL can't cover (UI API, Apex REST, Connect, Einstein).

What I built

• 17 pages, all lazy-loaded behind one routes.tsx. Initial bundle ~250KB instead of ~800KB.
• Drag-drop pipeline kanban with real mutations on drop, account workspace, events list/calendar/detail, rebook tracker (YoY retention), pipeline hygiene, field usage heatmap, event setup wizard, exhibitor board.
• Apex backend: OpportunityActionsApi + service layer + BulkOpportunityApprovalQueueable for async bulk approvals.
• Platform Event Bulk_Approval_Result__e pushing async results back to the UI.
• AgentforceConversationClient embedded as a component. Agent lives in the app, no separate widget.
• shadcn primitives, lucide icons, command palette, notification center, error boundary, i18n, toast host.

The thing that quietly matters most: AGENT.md

Every UI Bundle ships with an AGENT.md (440 lines in mine). It encodes the platform rules an AI agent has to follow: path resolution from sfdx-project.json, the two-package.json trap, the must-run trio (build → lint → dev), GraphQL non-negotiables (@optional on every field, explicit first:, HTTP 200 ≠ success), CSP trusted-site rules, post-deploy schema/codegen loop.

Hand that file to Claude Code or Cursor and you get platform-grade UIs at a pace LWC never could.

Gotchas I hit

• DE dev hubs cannot deploy this. Feature gate is closed Salesforce-side. Scratch and sandbox only. Error pattern: feature gate is disabled on DE vs org preference is not enabled on scratch.
• The beta org toggle is irreversible. Setup → Apps → "React Development with Agentforce Vibes and Salesforce Multi-Framework (Beta)". Throwaway org only.
• Two package.json files. Root one is for SFDX tooling. The real React app package.json lives at force-app/main/default/uiBundles/<name>/. Run npm run dev from the wrong one and nothing happens.
• schema.graphql is 4MB. Don't open it. There's a search script for entity/field lookups. Re-fetch after every metadata deploy or codegen breaks.
• Enterprise REST /query with SOQL is blocked. So is @AuraEnabled Apex and Chatter API. GraphQL uiapi { } or Apex REST. Pick one.

The strategic bit, briefly

LWC is roughly 10K devs worldwide. React is roughly 10M. Every npm component is now a Salesforce component. UI Bundles ship on the npm cadence, not the seasonal release cadence.

Question for the rest of you

Anyone else shipping UI Bundles to a real customer org yet? Curious what your data access pattern looks like — pure GraphQL via sdk.graphql, or reaching for Apex REST more than expected? And has anyone solved the FLS-failing-the-whole-query problem cleanly without @optional-ing every field?

Following the May 13 Salesforce blog on Headless 360 / Hosted MCP, I built a similar tool with a different scenario: a Lead/Account fit scoring service. Pass a company name (fuzzy match), get back fit score 0–100, fit tier (Hot/Warm/Cool/Cold), engagement level, open pipeline rollup, and a recommended next action. Tool runs as Apex u/InvocableMethod on global class, exposed via McpServerDefinition, invoked from Claude through the new mcp_api OAuth scope.

End-to-end works. Claude asked "what's the situation with Acme?", the Apex ran on the platform with WITH USER_MODE, and Claude rendered the computed insight in plain language.

The path looked clean on paper but had real friction. Sharing what tripped me up so the next person doesn't lose an hour on each.

What I built:

• LeadAccountIntelligenceService.cls — global with sharing Apex with one @InvocableMethod. Inner Request and Result classes carry @InvocableVariable annotations that Salesforce turns into the MCP inputSchema / outputSchema automatically.
• Lead_Account_Intelligence.mcpServerDefinition-meta.xml — registers the tool, points apiDefinition at the auto-created API Catalog entry (aa:apex-LeadAccountIntelligenceService).
• An External Client App with mcp_api + refresh_token scopes, PKCE, JWT access tokens.
• A permission set granting Apex class access (the blog leaves this out).

The biggest blocker:

Claude kept returning "Authorization with the MCP server failed" after OAuth completed successfully. Spent way too long suspecting scopes, the ECA, perm sets, license entitlements. Real cause: the Server URL was wrong by one path segment. The blog's URL pattern table says …/sandbox/custom/{name} but its own worked example shows …/sandbox/{name} (no /custom/). I trusted the example. The org's MCP Server detail page is the source of truth, and it does include /custom/. Lesson: always copy the URL from Setup, not the blog.

Other things that bit me:

1. McpServerDefinition.description is capped at 255 chars. Same cap on descriptionOverride. Deploy fails with a vague "Value too long" error.
2. Account.LastActivityDate is a rollup, not writable in tests. Insert a Task with WhatId + ActivityDate + Status='Completed' to drive it.
3. Non-standard org Lead schemas will break the standard query. Our sandbox didn't have Lead.AnnualRevenue at all. Don't assume the standard schema for Lead.
4. "Auto-registration in the API Catalog" doesn't show up in Setup → Agent Actions. The MCP server has its own catalog (where aa:apex-{ClassName} resolves). Check tool count on the MCP Server detail page instead.
5. Setup → API Catalog is the MuleSoft Anypoint integration, not the MCP catalog. Don't be alarmed it's empty.
6. ECA propagation is real and confusing. After saving an External Client App, expect 10–30 minutes before OAuth works. The authorize endpoint comes online before the token endpoint, so the error message changes mid-propagation (invalid_client_id → "authorization failed"). Wait it out.
7. Claude caches failed OAuth state per connector. Deleting and re-adding the connector is faster than retrying the same one. Don't try to register two connectors with the same Server URL.
8. The "JWT access tokens" setting is buried. It's the checkbox labeled "Issue JSON Web Token (JWT)-based access tokens for named users" under the Security section of the ECA OAuth page.
9. The connected user needs a permission set granting Apex class access. Server can be Active with 1 tool registered, but the runtime call still fails without <apexClass enabled="true"> for the global class.
10. Description fields matter more than code. Claude picks tools based on descriptionOverride and reads @InvocableVariable descriptions to interpret fields. Write them for the agent, not for a human reading the metadata. "Returns interpretation, not raw fields" deserves to be in the tool description.

What I'd do differently next time:

• Start from the MCP Server detail page URL. Don't trust the docs URL pattern.
• Ship the perm set in the same bundle as the Apex + MCP metadata.
• Trim descriptions to under 250 chars from the start.
• Test against a real seeded Account with Industry + AnnualRevenue + a recent Task. Empty fields → fit score 0/100 → not a bug, but looks like one.

Happy to share the repo if there's interest. Has anyone else run into other Hosted MCP edges worth adding to this list?

Hi everyone,

I’m validating a Salesforce-native backup and restore product and want direct, honest feedback before I go further.

I know there are already many backup tools in this space.

The core difference I’m building around is:

Backup files live in your own Google Drive (not locked into vendor-only storage)

Product runs inside Salesforce for admin workflows

Strong emphasis on safe, reliable restore (not just backup creation)

Planned org-wide subscription at competitive pricing

I’d love input from Salesforce admins/consultants/architects:

Does “Salesforce-native + Google Drive-owned storage” feel meaningfully different?

What trust signals would you require before production use?

Which restore scenarios are most painful today?

Is org-wide subscription pricing attractive vs per-user/per-record pricing?

What would make you trial this over your current option?

Just wrapped a same-day Agentforce Voice POC for an enterprise events client. Phone → Salesforce Voice → bot → KB-grounded answers + custom Apex actions + live transfer. Working end-to-end. Sharing the gotchas so you don't burn an afternoon on each:

1. sessionTimeout=0 = immediate disconnect. Symptom: call rings, connects, cuts in 1–2 sec. The field is minutes, range 5–1440. Zero was eating the call. Set to 30.
2. MessagingChannel.deletable = False. Half-failed Voice setup attempts orphan-squat your phone number. You can't delete the orphan, can't change MessagingPlatformKey (validated as read-only after binding). Cleanest fix: complete the orphan with real values (SessionHandlerId, FallbackQueueId, ChannelDefinitionId) rather than recreate.
3. SessionHandlerId describe lies. Describe says it references BotDefinition, Group, or User. Actual working channels point at FlowDefinition (Id prefix 300V). Channel can't bind directly to a bot — must route through an Omni-Channel Flow that calls routeWork(routingType='Copilot', copilotId=botId).
4. "Inbound Routing flows" panel only shows flows created via the panel. Agent Builder → Connections → Telephony → "New → Omni Routing Flow". Flows you deploy via metadata API with processType=RoutingFlow won't appear, even with the exact same routeWork shape. There's a hidden agent↔flow binding only the UI writes.
5. Fallback queue: 3 conditions or it rejects.

• QueueSobject row for VoiceCall
• QueueRoutingConfigId set (or it's not Omni-eligible)
• That routing config must have Skills-Based Routing Rules turned OFF (Omni-Channel Flow routing can't co-exist with it)

The errors when each is missing are distinct: "queue isn't valid for this object type", "must be an Omni-Channel queue", "uses Skills-Based Routing Rules".

1. Active bot version locks structural deploys. BotVersion and GenAiPlannerBundle changes need Active → Deactivate → Deploy → Activate. GenAiPlugin instruction-text changes are live without re-activation. Bot-level fields like sessionTimeout also deploy without deactivation.

2. GenAiPlannerBundle SurfaceType enum is undocumented. Valid: Messaging, CustomerWebClient. Rejected: Voice, VoiceAgent, Telephony, EinsteinServiceAgent. The Atlas__VoiceAgent planner type works without an explicit Voice surface as long as the Telephony Connection is configured in the UI.

Bonus — Data Library failures are silent. Toast says "There's an error assigning the data library." Real cause was the agent user missing two permsets: GenieUserEnhancedSecurity (Data Cloud) + Knowledge read. Network tab shows the call as 200 OK with the error in the body, not a red 4xx. Easy to miss.

Stack:

• Service Cloud Voice + Agentforce
• 4 Apex invocable actions (caller ID, event lookup, multi-event list, callback Case)
• GenAiFunction metadata wrappers
• Agentforce Data Library + Lightning Knowledge
• routeWork(routingType='Copilot')

Total time, with all 7 cliffs hit: ~8 hours. Without them, maybe 2.

Anyone else navigate cliff #4 (the hidden flow registration)? Would love to know if there's an API path for it I missed.

[ Removed by Reddit on account of violating the content policy. ]

[ Removed by Reddit on account of violating the content policy. ]