The situation
A company wants a custom service web application and an internal AI assistant to read Salesforce Cases and request approved service adjustments. Its release team also uses a CLI. Salesforce remains authoritative for customer records, approvals and adjustment eligibility; an external billing system owns invoice settlement. Supervisors already work effectively in Lightning. The proposed external UI duplicates eligibility rules in JavaScript, and a vendor claims that hiding a button protects the corresponding API operation.
Design governed capabilities outside Lightning. (1) Decide what stays in Salesforce and what belongs in the external presentation/application layer. (2) Choose API, MCP or CLI boundaries per consumer and define narrow contracts instead of assuming every interface provides identical capabilities. Headless 360 is the broader capability/interface approach, not just one MCP server and not a replacement for Lightning. (3) Specify identity, effective record/object/field access, server-side business rules and approval. (4) Explain the CRM/billing transaction boundary, uncertain outcomes and audit correlation. (5) Compare the operational cost of headless delivery with retaining native Lightning for supervisors. If you select the documented Headless 360 MCP Server, label it beta, check its actual operation catalog and client controls, and provide a supported-interface fallback rather than assuming full production feature parity.
Consider in your response
- Separate Salesforce capability ownership from presentation
- Choose API MCP and CLI boundaries deliberately
- Preserve server-side authorization and approvals
- Design distributed recovery and auditability
- Evaluate headless value against native UI simplicity
