Require evidence of the data flow, failure behaviour and support model; a connector’s name is only a starting point. Archer’s ServiceNow integration documentation provides a concrete example: it describes configurable mappings, additional licensing fees and circumstances where complex or bidirectional integrations may require professional services. Integration documentation. (help.archerirm.cloud)
Our integration acceptance schedule should specify:
| Dimension | Question to resolve |
|---|---|
| Objects and fields | Exactly which records, relationships, comments and attachments move? |
| Direction | Read-only, one-way write, or genuinely bidirectional? |
| Authority | Which system wins when values disagree? |
| Timing | Scheduled, event-driven or manual; what freshness is required? |
| Identity | Which account authenticates, and who rotates its credentials? |
| Reliability | How are retries, duplicates, partial failures and rate limits handled? |
| Lifecycle | What happens when records are deleted, merged or archived? |
| Support | Who fixes failures after either product changes? |
| Commercials | Which connector, middleware and API charges apply? |
Test a successful transfer, an expired credential, a rejected record and a retry. Verify that retrying does not duplicate findings or silently overwrite approved decisions.
For a ticketing integration, distinguish “create a ticket” from “maintain a consistent remediation lifecycle”. For evidence collection, distinguish “fetch a file” from “collect the complete population for the correct period”.
Make the buyer’s technical owner approve the interface specification before treating integration effort as fixed.
Sources cited on this page
- Integration documentation ↗help.archerirm.cloud