By Tej Pandya, founder of GrowEasy.ai
A conversational sales interface is easy to demonstrate. A customer record that survives conflicting updates is harder to build.
If an agent can read a lead, propose a visit and write a follow-up, the application needs more than a text field for the latest summary. It needs identity, access rules and a way to distinguish proposed changes from accepted state.
The design below is illustrative. It is not a deployed GrowEasy.ai feature or a customer result.
Give every customer a stable identifier
Do not use a name as the record key. Two buyers can share a name; one buyer can use several contact routes. Keep external identifiers and source references alongside the internal customer identifier.
A possible record sketch is:
customer_id
source_record_refs
record_revision
record_owner
permitted_contact_state
current_appointment
pending_changes
This is a starting point, not a universal schema. The fields should follow the business process and its privacy requirements. A model's confidence should not decide whether two customers are merged.
Validate proposed writes against current state
Let the model propose a structured change. Validate the target record, allowed fields, permissions and revision before accepting it.
If a rep changes the appointment while the agent is preparing a reminder, the older proposal should not silently overwrite the newer time. Return a conflict and recover using the current record.
The accepted record change and a completed external action are separate outcomes. Saving a callback request is not proof that someone made the call.
Scope access to the actual person and action
Salesforce's custom-action documentation distinguishes employee-facing agents from service agents. It calls for record and field access checks, and verified customer identity scoped to private service-agent actions.
That is a useful design warning: an agent's execution identity may have broader access than the customer it serves. The application must enforce the customer's boundary. Do not accept an arbitrary record ID from a prompt as proof of ownership.
These requirements belong to Salesforce's documented product context. They are not a claim about every platform's implementation.
Check what the connector really exposes
HubSpot's remote MCP guide describes supported reads and writes with existing user permissions. Availability varies by subscription, permissions and configuration. Sensitive Data settings block activities and conversations through MCP even though standard CRM APIs are a different route.
Treat the connector's documented coverage as an integration boundary. A natural-language interface cannot make an unavailable object available.
Design audit coverage instead of assuming it
Microsoft's Dataverse guidance says auditing must be configured at environment, table and column levels. Logs can be delayed and follow retention settings. Record auditing does not cover retrieve and export operations without additional activity logging.
Before launch, test which changes are recorded, whose identity appears and whether the history can explain a disputed update. Keep only the data the business needs, with an explicit retention policy.
Keep a correction screen for unresolved changes
A useful human view shows the current value, proposed value, relevant source and responsible owner. Test two similar customers, stale updates, revoked access and missing source history.
The aim is not to prove that screens are obsolete. It is to make routine work easier without weakening the record people depend on.
Sources:
https://developer.salesforce.com/docs/platform/isvforce/guide/secure-agentforce-actions.html
https://developers.hubspot.com/docs/apps/developer-platform/build-apps/integrate-with-the-remote-hubspot-mcp-server
https://learn.microsoft.com/en-us/power-platform/admin/manage-dataverse-auditing
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.