Tackling core system replacement with Salesforce Headless 360 × MCP — Architecture guidelines for enterprise client projects 2026

"The standard Salesforce UI doesn't fit our frontline workflows," "Lightning components make it difficult to integrate AI agents"—we are seeing an increase in inquiries like these from mid-market and enterprise organizations running core operations on SFDC. Offering a solution is Salesforce Headless 360, announced by Salesforce. By providing full access to core CRM, service, and marketing functions via APIs, CLIs, and MCP, it officially supports decoupling frontend experiences from business logic.

This article outlines how to architect core replacement client projects by combining Headless 360 with MCP for enterprises running core systems on SFDC.

Why headless Salesforce matters right now

Using SFDC through APIs has existed previously (via Heroku Connect or raw REST API calls). Headless 360 differs decisively in the following three aspects:

In short, the longstanding ideal of "business logic in SFDC, full freedom on the frontend" is no longer impractical. This directly impacts client projects for corporate websites, sales portals, and partner portals.

Applying the "use-case-aggregated model" from design patterns for turning existing SaaS APIs into MCP servers to Salesforce MCP constitutes the core of this article.

Overall architectural picture

We organize the standard architecture for "Headless SFDC + custom frontend + AI agents" across four layers.

• Salesforce Headless 360: Core data, workflows, and permissions management
• BFF (Backend for Frontend): Frontend optimization, caching, and aggregation
• Custom frontend: Flexible selection among Astro, Next.js, TanStack Start, etc.
• MCP layer: Natural language orchestration of SFDC by agents

Whether to insert a BFF is always a critical design decision in client projects. Our rule of thumb is that read-heavy internal portals require a BFF, while write-heavy operational UIs can depend directly on MCP.

Three common patterns in client projects

Pattern A: Headless redesign of sales portals

Projects addressing user frustration with sluggish Lightning interfaces. SFDC data remains untouched while replacing only the frontend with TanStack Start or Astro.

• Timeline: 3 to 5 months
• Impact: Perceived page navigation speeds improve by 3x to 5x
• Caution: Lock down permissions, mobile responsiveness, and offline requirements early

The frontend design principles detailed in our article on building corporate sites with TanStack Start apply directly to headless SFDC projects as well.

Pattern B: Partner and customer portals

Projects exposing select SFDC capabilities directly to distributors, dealerships, and end customers. Leveraging Headless 360 allows teams to:

• Extend SFDC permission boundaries directly to external users
• Retain full in-house control over branding and UX
• Embed AI chat via MCP to enable natural-language quote generation

This makes such implementations entirely feasible.

Pattern C: Core revitalization via SFDC × AI agents

The most ambitious pattern: replacing first-line sales and customer support touchpoints with AI agents that manage SFDC state via MCP.

server.tool("update_opportunity_stage", async (args, ctx) => {
  if (!ctx.userApproved) {
    return {
      kind: "approval_required",
      summary: `商談 ${args.opp_id} を「${args.next_stage}」に進めます`,
      approval_token: issueApprovalToken(args),
    };
  }
  return await sfdc.opportunity.update(args.opp_id, {
    StageName: args.next_stage,
    NextStep: args.note,
  });
});

Following the HITL principles from our guide to integrating Anthropic Computer Use into business workflows, updating opportunity stages or issuing quotes always requires human approval.

Phased approach (4 phases)

Big-bang overhauls of SFDC core systems inevitably run into trouble. We structure proposals into four distinct phases.

Whether you align with the client on the exact scope to transition to headless during Phase 1 dictates success or failure. Entering a PoC with undefined boundaries causes scope creep to explode.

Pitfalls: Governor limits and API quotas

SFDC enforces daily API call ceilings (Governor Limits). Surging API requests from headless architectures risk hitting these limits and halting operations. Lock down the following three controls early in design:

1. Caching strategy: Cache master data in the BFF or Cloudflare KV
2. Leveraging Composite APIs: Batch multiple operations into single requests
3. Monitoring API consumption: Alert when usage exceeds 60% of license allocations

Summary — The era where Salesforce operates behind the scenes

Particularly across insurance, real estate, and manufacturing, demand is surging to completely modernize operational UX while leaving SFDC in place, sparking competition for development partners.

Headless 360 is a strategic update where Salesforce acknowledges its role behind the scenes. With broader frontend choices and standardized AI agent integrations, the strategic capability of development partners directly dictates project outcomes for enterprises using SFDC.

The crux of Headless 360 projects lies in deciding during Phase 1 which SObjects not to make headless. Whether to introduce a BFF or interface directly with MCP, and where to handle Governor Limits—these two decisions alone drastically reshape timelines and staffing structures. If you share your current SFDC architecture and operational pain points, we can determine the right phase to begin. Please reach out via our contact form.