Your scheduling, customer-service or work-order system already holds the answer. Can an AI assistant retrieve it reliably enough for an employee to use? For a Western Colorado owner buying a software integration, that question comes before the model demonstration.
Before accepting the pilot, require evidence that it can read the right records, recognize missing or outdated information, and stop at the agreed review boundary. A convincing answer on a screen does not establish any of those things.
1. Prove access to the fields your workflow needs
An API is a supported way for software to request information or actions from another application. An export is a copy taken at a particular time. Either may support a useful workflow, but they make different promises about freshness and availability.
Ask the implementer to demonstrate the permitted connection in a test account or with an approved synthetic record. Get the application owner involved. A product logo on a connector list is insufficient evidence that your subscription, account role and required fields are supported.
- Access route: identify the documented API, SDK or approved export, the exact records it exposes and whether it is read-only.
- Account requirements: confirm the required product plan, administrator approval, access scope and any separately priced integration entitlement with the software provider.
- Coverage: show the required fields, stable record IDs, all result pages and any records excluded by filters or permissions.
- Operating limits: document request limits, update frequency, maintenance responsibilities and how connection failures reach a named person.
If the application can only produce a nightly export, scope a dated reporting assistant. Do not present it as a live status lookup. If neither a supported connection nor an acceptable export exists, pause the integration estimate until the provider confirms a viable path.
2. Write a small data contract in plain language
A data contract is the agreed meaning and handling of the fields being exchanged. It need not be a large technical document. Have the business owner and implementer approve these decisions before building against real records:
Which system is authoritative?
Name the application that owns status and the person who corrects it. Identify records by a stable ID, not by a customer name that may match several people. Link the employee back to the original record.
What is permitted to cross?
List allowed fields and meanings: request ID, status, assigned team and last source update. Define allowed status values. Exclude free-text notes and attachments unless the workflow needs them and sharing is approved.
When is the information usable?
Keep the source update time separate from the last successful synchronization time, with a stated time zone. An unchanged record can still be current. Set the maximum acceptable synchronization age for this particular task.
What happens when access or records change?
Specify how deletions, permission changes and corrections reach cached copies and search results. Define retention for diagnostic logs, histories and backups separately, including who can authorize removal.
These are implementation requirements to verify, not features every product provides. For example, Microsoft Graph documents change tracking for supported resources, including created, updated and deleted entities. The same guidance warns about processing delays, repeated changes and synchronization resets. Confirm the equivalent behavior for your actual application.
3. Follow one synthetic request from source to draft
This example is fictional. It describes no customer deployment, measured result or ready-made product integration. Imagine a Montrose service office whose employee needs to answer, “What is the status of request R-104?” The pilot reads a test scheduling system and prepares an internal answer. It cannot update the schedule or send a customer message.
The agreed fields are request ID, status, assigned team, source update time and source-record link. Customer addresses, payment information, technician notes and attachments are outside the pilot. The source is authoritative; the assistant does not infer completion from a note or from yesterday's answer.
- Retrieve: authorized staff ask about R-104. Application code checks their access and looks up that exact ID.
- Validate: code checks required fields, allowed status values and freshness before any AI wording step.
- Present: the fictional source says “Awaiting parts,” last updated at 9:10 a.m. Mountain Time. The last successful synchronization was 9:12 a.m. The answer shows both times and the source link.
- Review: the employee opens the source before using the draft externally. A requested completion date remains unanswered because no approved field supplies it.
For this hypothetical pilot, the owner chooses a maximum synchronization age of 15 minutes. At 9:30 a.m., if no refresh has succeeded since 9:12, the assistant withholds a current-status answer, labels the stored snapshot as outdated and directs the employee to the source application. Fifteen minutes is an illustrative business decision, not a general freshness standard.
A fixed status lookup may need only ordinary code and a clear display. Add AI only if explaining or drafting from those validated fields helps the employee. The routing and reasoning guide addresses that separate tool-selection decision.
4. Make failures part of the acceptance demonstration
Use synthetic records in an isolated test environment. For each case, record the input, expected behavior, observed output, relevant log entry, reviewer and pass/fail decision. Agree on expected behavior before running the demonstration.
- Normal lookup: R-104 returns the exact source status and both timestamps with a working source link. No unsupported completion date appears.
- Stale data: stop refreshes beyond the agreed threshold. The answer must show that current status cannot be established, offer the documented fallback and avoid silently reusing an old answer.
- Deleted or restricted record: delete a synthetic record, then separately remove a test employee's permission. Verify that subsequent retrieval and search do not reveal its content under the agreed policy. Check retained history and logs separately; disappearance from search is not proof of complete deletion.
- Retry and replay: simulate a temporary failure and return the same update twice. The connector should recover within its agreed retry budget without producing duplicate records or drafts. Exhausting the budget should alert the owner rather than loop silently.
- Incomplete or changed fields: omit the request ID, supply an unknown status and return conflicting versions. The workflow should hold the record for review, explain the problem and preserve the source for correction rather than guess.
- Review boundary: ask the assistant to mark the job complete or send the draft. Both actions must remain unavailable in this read-only pilot, including when a source note instructs the assistant to perform them.
- Recovery: restart the connection after an interrupted multi-page synchronization. Compare source IDs and counts with the local copy, confirm no silent omissions or duplicates, and resume only after freshness is established.
Retry behavior must follow the selected provider. Microsoft Graph's throttling guidance, for example, explains HTTP 429 responses and waiting for the supplied Retry-After interval. That is a reason to require an intentional retry policy, not a promise that every business application behaves the same way.
Keep write-back outside this pilot. If a later project will create bookings or change records, add separate approval and duplicate-action tests, including the case where the source accepted a change but the connection failed before confirmation. A read-only demonstration cannot establish safe write behavior.
5. Ask who can operate it when the implementer leaves
The acceptance packet should contain a connection diagram, approved field list, account and permission inventory, test evidence, operating instructions and an exit procedure. Name who owns the source account, hosting, code or licensed components, configuration and support relationship. Put deliverable ownership and third-party licenses in the written agreement.
Have the designated operator demonstrate how to identify a failed refresh, use the fallback, contact support and revoke integration access. Verify an export of the business-owned configuration and data that the agreement permits you to retain. Agree on what happens to remaining copies when support ends.
A useful acceptance decision is explicit: pass the agreed scope, fix listed failures and retest, or stop. Do not expand access while freshness, permissions or duplicate handling remain unexplained. Compare ongoing provider charges, monitoring and repair responsibilities alongside the initial build scope.
Bring the access question to the first conversation
Prepare the software name and plan, one employee question, the required fields, the application owner and a fictional sample record. Add the freshness requirement and the actions the assistant must never take. Start with public documentation and synthetic examples; agree on permitted sharing before sending internal records or credentials.
Randall Automation Works' workflow automation and integration services start with a scoped task. The workflow examples show the kinds of connections that may be considered, while the engagement process explains assessment, controlled pilots and review. Each proposed application connection still needs its own access check and acceptance evidence.
Primary documentation checked October 18, 2026. Verify current provider capabilities, account entitlements and limits when scoping the actual integration.