# 14. How do we know whether a GRC connector is a working integration?

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](https://help.archerirm.cloud/exchange/content/exchange/integrations/servicenow.htm). ([help.archerirm.cloud](https://help.archerirm.cloud/exchange/content/exchange/integrations/servicenow.htm))

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.