Approve the data movement before approving the automation. Name the records the assistant may read, the fields it may write, how duplicates are handled and the person who owns failures. A fluent conversation does not prove an integration is correct.
1. Define one permitted transaction
Start with a sentence such as: “Create a new enquiry for review, using the caller’s confirmed contact details.” List the input, destination and success condition. Creating an enquiry should not silently grant permission to change a deal stage, send an email or update billing information.
Mark each proposed action as read-only, write-with-review or permitted automatic write. Keep destructive actions, broad record edits and external communications outside the initial scope unless there is a clear reason and an agreed control.
2. Check access against the actual endpoint
Identify the CRM, subscription, available API and administrator who can approve access. A marketplace listing or a familiar brand name is not evidence that the required action is supported in your account.
HubSpot documents scopes as access to specific API endpoints and associated account data. Use the permissions required for the intended operation rather than requesting everything by default. This is a design example, not a claim that Lucentia has completed or certified a HubSpot integration.
Keep credentials on the server side of the integration, define how they are stored and rotated, and identify who can revoke them. Ask what happens when access expires or the person who installed the connection leaves.
3. Agree a field mapping and a source of truth
For every field, record where it comes from, whether it is required, what format is expected and what to do when it is missing. A spoken company name may be an uncertain match; an assistant should not convert uncertainty into a confident update to an existing account.
- Name: preserve the confirmed spelling; do not invent a last name.
- Contact method: validate the format and record whether the caller confirmed it.
- Request: distinguish the caller’s words from an AI-generated summary.
- Status: use an agreed value such as “needs review,” not an inferred sales outcome.
- Source: keep enough context to trace the enquiry without storing unnecessary conversation data.
Choose which system wins when information differs. For example, a caller’s requested appointment is not an available calendar slot until the scheduling system confirms it.
4. Design for retries and duplicates
Give each interaction a stable reference and decide how repeated requests are recognized. If a network connection drops after the CRM accepts a write, retrying blindly can create duplicates. An engineer should be able to explain how the workflow finds the prior result or safely reconciles an uncertain outcome.
Test both a new customer and an existing customer with similar details. Define whether the workflow creates a separate enquiry, links it to an existing record or asks staff to resolve the match. Avoid merging records based only on a similar name.
5. Plan for errors before a live caller finds them
Include expired credentials, missing required fields, timeouts, unavailable APIs and rate limits in the acceptance tests. HubSpot publishes usage and authentication requirements; check the current documentation for your chosen platform instead of assuming unlimited API capacity.
The assistant should not tell a caller that an update succeeded until the relevant system has confirmed the result. If it cannot confirm, it needs an honest fallback: explain that the request requires review and route the details through the agreed alternative. Keep a human owner for failed or uncertain transactions.
6. Limit data collection and logging
Write down which information enters the assistant, the integration service and the CRM. Decide what belongs in operational logs, who can access it and how long it is kept. Debugging should not require copying passwords, access tokens or complete customer conversations into general-purpose logs.
If the use case includes sensitive information, establish the applicable handling and contractual requirements before the pilot. Do not treat a vendor’s security page as proof that your whole workflow is suitable for that information.
7. Make acceptance observable
A useful test result shows the input, permitted action, resulting CRM record and any follow-up work. Test corrections, repeated submissions, failed writes and recovery using test records. Record what staff should do when the workflow is paused.
Before launch, confirm the field map, permission list, duplicate rule, failure queue, acceptance results and handover owner. These are concrete deliverables that belong in the scope.
Lucentia Services assesses integrations before agreeing delivery. Bring your CRM name, intended transaction and current manual process to a scope discussion. Supported connections and implementation costs must be confirmed for your particular systems.