An agent can make sales software easier to use while leaving the hard record problems untouched. Before replacing routine CRM screen work with a conversational interface, test the data and access rules underneath it.
This checklist uses illustrative sales cases. It is not a customer result or a promise about a specific product.
Keep two similar buyers separate
Create two test customers with similar names and different contact routes. Ask the agent for one customer's appointment and history.
Check which identifier it used. The agent should not merge the records or return the other customer's context because the names look alike. Keep source references that let a person inspect a proposed match.
Reject a change based on an older record
Let the agent prepare a visit-time update. Then have a rep change the time before the agent writes.
The application should detect the changed record and recover from current state. Check the accepted value, not only the wording of the agent's reply. A proposed update should not silently override a newer decision.
Test access with different user roles
Use a test user who can read a record but cannot change it. Then use a customer-facing test identity that should see only its own data.
Salesforce's custom-action guidance separates execution identity from customer authorization and calls for record and field checks. Use the platform's actual permission model. Do not treat a contact name or a record ID supplied in a prompt as authorization.
Confirm the connector covers the needed objects
List the workflow's required records, activities and actions. Compare that list with current connector documentation.
HubSpot's remote MCP guide says availability varies by subscription, permissions and configuration. Sensitive Data settings block activities and conversations through MCP. A demo with one account is not proof that the same workflow works in every account.
Check the history of an accepted change
Change a test field and inspect the recorded actor, time and old/new values where the platform supports them. Check retention and the operations that are excluded.
Dataverse auditing must be enabled at environment, table and column levels. Logs can be delayed; retrieve and export operations need additional activity logging. Do not assume that "we have an audit log" means every action can be explained.
Give unresolved updates a visible owner
Try an ambiguous customer match, a missing source and a rejected write. Check that the record remains intact and the uncertainty reaches a responsible person.
A useful review view shows the current value, proposed value and relevant evidence. It should not expose unrelated private history just to explain one change.
Compare saved effort with the repair work
Track repeated entry and navigation alongside wrong-record writes, stale updates and unresolved changes. Define the measurements before rollout and inspect the records behind them.
The aim is less routine screen work with a more trustworthy customer record. If corrections become a second full-time workflow, the interface has not earned the change.
Sources: Salesforce custom-action security guidance
HubSpot remote MCP server guide
Microsoft Dataverse auditing guidance