Integration and Enterprise Systems

Executive summary

Enterprise AI that cannot read truth from and write actions to systems of record is a chat toy—not an operational capability. Integration and enterprise systems skill lets an AI Solution Engineer map ERP, CRM, core banking, ITSM, IdP, DMS, payments, and workflow boundaries; choose APIs vs events; design sync vs async patterns; implement idempotency, retries, dead-letter queues (DLQ), versioning, and legacy coexistence so timeouts do not create duplicate incidents, payments, or case records. Without this capability, assistants hallucinate freshness, double-post on retries, throttle fragile mainframes, and fail architecture review at the moment write-back is required.

When to use this page

• Assistant must create tickets, update cases, post notes, or trigger workflows—not read-only FAQ.
• Discovery lists Salesforce, SAP, ServiceNow, Temenos, Finacle, Dynamics, mainframe as dependencies.
• Business asks for real-time answers backed by batch ERP data—sync/async mismatch imminent.
• Pilot saw duplicate ServiceNow or CRM records after timeouts.
• Core banking or payments involved—SoR, audit, and idempotency non-negotiable.
• Event-driven enterprise bus (Kafka, Solace, MQ) exists—need event contract for AI side effects.
• Legacy API rate limits (5 TPS) threaten UX if orchestration calls synchronously per token.
• Stage 3 exit requires integration map and failure modes—this topic produces them.

Executive view

Focus on **duplicate incident cost**, **SoR clarity**, and scenario £/regulatory impact. Ask: if the AI times out, do we create one record or three?

Technical view

Produce integration maps, OpenAPI/event schemas, idempotency design, DLQ/replay runbooks before enabling write paths.

Why this matters

AI demos integrate with one happy-path API call in Postman. Production integrates with 15-year-old ERP batches, CRM governor limits, ITSM mandatory fields, IdP token lifetime, DMS ACL sync lag, and mainframe MQ with 500ms–30s latency variance. A telecom billing assistant created ServiceNow incidents on ERP timeout; retry logic without idempotency produced 1,840 duplicates in six weeks; cleanup £95K; programme paused.

System of record (SoR) discipline prevents AI from becoming a shadow database. If CRM shows updated status but ERP is truth, reconciliation breaks finance. Integration architecture states which system owns each entity and which direction sync flows. AI orchestration should call domain APIs that enforce invariants—not raw database writes.

Sync vs async choice determines UX and reliability. Synchronous ERP read inside chat loop may exceed 8s SLA; async with correlation ID and status polling scales. Events decouple AI side effects from fragile downstream—publish CaseEscalationRequested rather than blocking on ServiceNow during user wait.

This topic pairs with Architecture Guide integration view and topic 15 API/idempotency implementation.

Learn

Enterprise system landscape and roles

Definition. Common enterprise systems and typical roles:

System class	Examples	AI interaction patterns
CRM	Salesforce, Dynamics	Read account/case context; create tasks, log interactions
ERP	SAP S/4, Oracle ERP Cloud	Read orders, inventory, pricing; limited write via approved APIs
Core banking	Temenos, Finacle, mainframe	Read balances, holds; strict write via payment/workflow APIs
ITSM	ServiceNow, Jira Service Mgmt	Create incidents, attach AI summary
IdP/IAM	Entra ID, Okta	User auth; group claims for ABAC
DMS/ECM	SharePoint, Documentum	Corpus source; metadata for RAG
Contact centre	Genesys, Amazon Connect	Agent assist; wrap-up codes
Workflow/BPM	Camunda, Pega	Human approval steps
Payments	Stripe enterprise, bank rails	Rare direct AI write—always human gate
BI/data	Power BI, Snowflake	Metrics—not SoR for transactions

Engagement use. Build integration inventory early: system, owner, API/event availability, rate limits, sandbox, classification, SoR for each entity. Mark read, write, both per use case—with auth method.

Pitfalls.

• Assuming CRM is SoR for financial truth—it rarely is.
• Undocumented shadow Excel exports as integration.
• Ignoring vendor package customisations that break API upgrades.
• Contact centre CTI treated as real-time ERP—it's not.

Worked example. Servicing assistant: Salesforce read account; core banking API read balance (SoR); ServiceNow write incident on escalation (SoR for ITSM); SharePoint read policy corpus; Entra ID auth; no ERP write in pilot.

System of record matrix

Definition. SoR matrix documents authoritative system per entity and allowed AI interactions.

Entity	SoR	AI read	AI write	Notes
Customer profile	CRM	Yes	No	Mask PII in logs
Account balance	Core banking	Yes	No	Real-time API
Billing dispute case	CRM	Yes	Draft only	Human publish
IT incident	ServiceNow	Yes	Create	Idempotency required
Policy document	DMS	Yes	No	Version in citation

Engagement use. Review with business owners and integration COE. Writes require compensating controls (human approve, idempotency, audit). AI never SoR for regulated entities.

Pitfalls.

• AI writes CRM field that ERP reconciles nightly—conflict.
• Two systems both "master" for product catalog.
• Write without workflow state—draft vs published confusion.

Worked example. Lending assistant posts memo draft to LOS notes field marked AI_DRAFT; human promotes to official record; SoR remains LOS, not vector index.

API integration patterns (REST, GraphQL, OData, SOAP)

Definition. APIs are primary integration for modern SaaS and many ERP extensions: REST/OpenAPI, GraphQL (Salesforce), OData (SAP), legacy SOAP (mainframe wrappers).

Engagement use. Prefer vendor-supported APIs over screen scraping. Version APIs explicitly (/v2). Use pagination, field selection to reduce payload. Circuit breakers on slow ERP. Cache read-heavy reference data with TTL aligned to business tolerance—not stale balances.

Pitfalls.

• Chat calls 20 micro-APIs serially per turn—latency death.
• SOAP/XML without timeout—thread pool hang.
• GraphQL unbounded query depth—cost blowout.
• Using admin integration user for all users—audit fail.

Worked example. Salesforce: composite API batches 3 reads; OAuth OBO per user; cached product catalog 15 min TTL; balance always live core banking call with 800ms timeout + degrade message.

Event-driven integration (Kafka, MQ, Event Grid, webhooks)

Definition. Events communicate facts asynchronously: InvoiceDisputed, PolicyPublished, CaseCreated. Producers publish to bus; AI services consume to refresh index or publish side effects after user action.

Engagement use. Use events when: downstream slow, multiple subscribers, or temporal decoupling required. Schema registry (Avro/JSON Schema); CloudEvents envelope for metadata. AI service publishes EscalationRequested with correlation_id; ITSM adapter creates ticket; callback event TicketCreated updates session.

Pitfalls.

• At-least-once delivery without idempotent consumer—duplicates.
• No ordering guarantee assumed when required—use partition key.
• Giant payload events with PII—minimize, reference by ID.
• Missing dead-letter on poison messages.

Worked example. Policy CMS webhook → Event Grid → index refresh job; user escalation → Kafka topic servicing.escalations → ServiceNow consumer with idempotent external_id.

Sync vs async integration choices

Definition. Synchronous: caller waits for response in request path—simple UX, fragile under slow SoR. Asynchronous: caller receives 202 Accepted + tracking ID; completion via poll, webhook, or SSE update.

Engagement use. Decision tree:

Condition	Prefer
Read needed for answer, p95 <800ms	Sync with timeout + cache
ERP p95 >3s or batch SoR	Async pre-fetch or materialized view
Write with human wait in chat	Async + progress UI
Financial write	Async + human approval workflow
Fire-and-forget notify	Event only

Pitfalls.

• Sync 30s SAP call in chat loop—timeouts and duplicates on retry.
• Async without status UX—user thinks failed.
• Sync write on non-idempotent API with retries—duplicate records.

Worked example. Balance check sync (400ms). Dispute case creation async: return case_ref in 200ms after queue accept; notify user when CaseCreated event arrives (~5–30s).

Idempotency, deduplication, and exactly-once illusion

Definition. Idempotency ensures repeating the same request does not duplicate effect. Implement via Idempotency-Key header (client-generated UUID per user intent), natural keys (session_id + action_type), or upsert semantics where supported.

Engagement use. All write paths require idempotency design documented in OpenAPI. Server stores key → response mapping 24–72 hr. Retries safe. Combine with outbox pattern for DB + event atomicity.

Pitfalls.

• Retry POST on 500 without key—duplicate tickets.
• Key scoped per request not user intent—double-click duplicates.
• Idempotency store lost on deploy—duplicates return.
• Assuming vendor API is idempotent—it often isn't.

Worked example. POST /tickets requires Idempotency-Key: {session}:{intent_hash}; ServiceNow adapter checks table idempotency_keys before create; ERP timeout retry returns same incident_id from store.

Retries, backoff, circuit breakers, and DLQ

Definition. Retries with exponential backoff on transient errors (429, 503, timeout)—not on 400/401/403. Circuit breaker stops cascade when ERP unhealthy. DLQ holds failed messages for manual replay after fix.

Engagement use. Policy: max 3 retries, jitter backoff; breaker open 30s after 5 failures. DLQ alert to ops; replay runbook validates idempotency before bulk replay. Distinguish technical retry from business retry (user clicks again).

Pitfalls.

• Infinite retry on mainframe—overload.
• DLQ without owner—messages age forever.
• Replay without fix root cause—refill DLQ.
• Retry on 409 conflict—may need merge not retry.

Worked example. Kafka consumer: 3 retries → DLQ topic servicing.escalations.dlq; PagerDuty on depth >100; runbook RB-INT-07 replay max 50/min with idempotency check.

Authentication for service-to-service integration

Definition. Patterns: OAuth2 client credentials (service), on-behalf-of (user context to CRM), mutual TLS (bank APIs), API keys (discouraged, rotate often), signed requests (AWS SigV4).

Engagement use. Prefer short-lived tokens from vault; certificate rotation calendar. User-context actions use OBO so CRM audit shows actual user, not bot account. Separate credentials per env. Scope minimal: incident.create not admin.

Pitfalls.

• Shared integration user ServicingBot for all actions—no accountability.
• mTLS cert expires weekend—outage.
• Token cached past expiry—flaky 401 retries duplicate if idempotency weak.
• Storing client secret in prompt config.

Worked example. ServiceNow: OAuth OBO with user JWT; core banking: mTLS + service cert from HSM; secrets in Key Vault; rotation 90 days automated.

API versioning, compatibility, and consumer-driven contracts

Definition. Versioning: URL (/v2), header, or schema evolution with backward compatibility. Consumer-driven contracts (Pact) test adapters against provider sandbox expectations.

Engagement use. Pin major version in ADR; subscribe to vendor release notes. Deprecation timeline 6 months. Contract tests in CI (topic 15). For events, schema version in envelope; upcast old events in consumer.

Pitfalls.

• Silent Salesforce field rename breaks adapter.
• Breaking change Friday deploy—no contract test.
• Multiple consumers on informal JSON—schema drift.
• AI team owns adapter nobody maintains post-go-live.

Worked example. CRM adapter Pact with sandbox; fails CI if Account.BillingCycle removed; pinned API v54.0 until migration epic complete.

Legacy, mainframe, and rate-limited systems

Definition. Legacy systems expose MQ, SOAP, file drops, or strict TPS caps (5–50 TPS). AI orchestration must not fan out per token.

Engagement use. Materialized views or cache layer refreshed on schedule/events. Bulkhead dedicated pool for legacy calls. Queue write requests; never synchronous mainframe in chat critical path unless proven fast.

Pitfalls.

• RAG retrieves doc then each chunk triggers ERP lookup—TPS fire.
• Nightly batch file as real-time truth without stamp.
• Mainframe commit without compensating transaction on AI failure.
• Screen scraping breaks on UI upgrade.

Worked example. Core banking read via API gateway cache: balances TTL 0 (live), product metadata TTL 1 hr from replicated read model fed by nightly batch + intraday events.

ERP-specific integration considerations

Definition. ERP (SAP, Oracle, etc.) integrates via IDoc/BAPI, OData, or middleware (Mule, Boomi). Writes often workflow-heavy—create sales order, not arbitrary field patch.

Engagement use. Map AI actions to approved BAPI/transactions with approval workflow. Read via CDS views or replicated lakehouse for analytics-heavy context. Respect change pointers for delta sync.

Pitfalls.

• Direct table write bypassing business rules—audit finding.
• AI summarises stale ERP extract from yesterday's batch.
• Custom Z-transaction undocumented—upgrade break.
• Licensing block on API user count.

Worked example. Spare parts agent: read inventory from OData StockSet; order create via approved BAPI BAPI_SALESORDER_CREATEFROMDAT2 only after human approve in BPM; idempotency on client_po_ref.

CRM and case management integration

Definition. CRM holds customer relationship, cases, opportunities. AI reads 360 context; writes tasks, case comments, draft emails—often with validation rules and mandatory fields.

Engagement use. Use composite/bulk APIs; respect governor limits. Store AI metadata: source=assistant, prompt_version, confidence. Field-level security applies to bot user—test with real profiles.

Pitfalls.

• Bot user bypasses validation via system mode—policy violation.
• Case create missing category—rollback fail mid-flight.
• Logging entire CRM payload—PII leak.

Worked example. Salesforce: create Case with Origin=AI Assistant, Category=Billing, attach AI summary as CaseComment with IsPublished=false until agent approves.

Core banking and payments boundaries

Definition. Core banking systems execute authoritative financial state: balances, holds, transfers, loan accounts. Payments rails move money—highest scrutiny.

Engagement use. AI read via approved banking APIs with strong auth. Write (payment, hold release) never direct from LLM tool without human approval and dual control where required. Log immutable audit. Idempotency on payment instruction ID.

Pitfalls.

• Tool transferFunds in agent prototype—regulator nightmare.
• Balance read from CRM cached field—wrong amount advice.
• Async payment without status polling—user told success prematurely.

Worked example. Assistant shows balance from core API live; initiates payment request object in workflow queue; human approves in core app; AI never calls payment POST.

ITSM integration (ServiceNow and peers)

Definition. ITSM tracks incidents, problems, changes. AI creates incidents from user reports, attaches diagnostics, links CMDB CI when known.

Engagement use. Map categories, urgency, assignment groups. Idempotency mandatory—timeout duplicates common. Attach conversation transcript as work note with PII redaction. Close loop: incident resolved event updates user session.

Pitfalls.

• Default assignment group null—lost tickets.
• Duplicate incidents on retry—Scenario telecom £95K.
• AI sets resolved status—premature closure.

Worked example. POST /api/now/table/incident with idempotency; fields short_description, u_ai_session_id, assignment_group=Servicing L2; correlation stored; DLQ on 503.

Document management and collaboration sources

Definition. DMS (SharePoint, Documentum) supplies corpus and metadata for RAG; may require sync jobs respecting ACL.

Engagement use. Prefer API/Graph delta sync over crawl. Propagate ACL changes to index within SLA. Version metadata on every chunk. Write to DMS (save generated memo) via checkout/checkin patterns.

Pitfalls.

• Index ACL stale 7 days—leak or over-restriction.
• Saving AI output to published library without review.
• Path-based sync breaks when site restructured.

Worked example. SharePoint delta sync every 15 min; ACL trim at query; AI-generated memo saved to /drafts/ai/ only; promotion workflow moves to official library.

Frameworks and methods

Integration mapping template

#	System	Entity	R/W	Pattern	Auth	SoR	Rate limit	Idempotency	Failure mode
1	Salesforce	Account	R	REST sync	OBO	CRM	10K/day	N/A	Cache 15m metadata
2	ServiceNow	Incident	W	Async event	OAuth	ITSM	300/min	Key	DLQ+replay
3	Core API	Balance	R	REST sync	mTLS	Core	50 TPS	N/A	Timeout degrade

Sync vs async decision record

Document in ADR-005 per write path: chosen pattern, timeout budget, UX behaviour, idempotency key format.

Idempotency key standard

Format: {tenant}:{session_id}:{action}:{intent_hash}; store 72 hr; return original 201 body on replay.

Retry policy template

Error class	Retry	Max	Backoff
Timeout	Yes	3	exp+jitter
429	Yes	5	Retry-After
400	No	0	—
401	No	0	refresh token once

Event schema skeleton (CloudEvents)

{
  "specversion": "1.0",
  "type": "com.bank.servicing.escalation.requested.v1",
  "source": "/ai/orchestrator",
  "id": "uuid",
  "correlationid": "session-uuid",
  "data": { "accountId": "...", "summaryRef": "..." }
}

8D alignment

Design: integration map and contracts. Develop: adapters with contract tests. Deploy: DLQ monitoring. See 8D Framework.

Real-world scenarios

Scenario A: Duplicate ServiceNow incidents (telecom billing)

Servicing assistant creates incidents when users report billing errors. ERP validation call timeouts 12% under load; orchestration retries POST without idempotency. 6 weeks, 1,840 duplicates, £95K cleanup, NPS hit.

Fix: Idempotency-Key on intent; async pattern—queue incident create; ERP check decoupled; DLQ + replay runbook RB-INT-07. Post-fix: duplicate rate <0.01% over 90 days; p95 user response 1.2s (async accept).

Scenario B: SAP order duplicate PO (manufacturing)

Spare parts agent prototype posts purchase orders synchronously on LLM tool call. Network blip causes retry; duplicate POs £140K before pilot stopped.

Fix: Remove direct write from agent; human approve in BPM; BAPI call with client_ref idempotency; tool registry read-only in prod. Lesson: ERP write never LLM-direct.

Scenario C: Core banking balance misread (retail bank)

Assistant reads CRM custom field Last_Balance__c updated nightly batch—not live core. 847 users receive wrong balance guidance over 3 weeks; £210K remediation and regulatory notification.

Fix: SoR matrix enforced; balance only from core API live; CRM field deprecated for AI; contract test fails if adapter reads CRM for balance. Incident Severity 1—architecture review mandates SoR doc before any read integration.

Scenario D: Salesforce governor limit outage (SaaS B2B)

Agent assist calls 20 SOQL queries per message turn; peak Monday hits governor limits; 4 hr outage for 1,200 agents.

Fix: Composite API batching; cached account context per session; query plan review; load test 500 concurrent agents. Outcome: queries per turn ≤3; zero governor incidents next quarter.

Scenario E (stretch): Core banking event-driven limit hold

Corporate banking assistant requests temporary credit limit hold for dispute investigation. Sync mainframe call unacceptable latency. Design: publish HoldRequested event; core consumer processes; HoldConfirmed event returns to session via SSE.

Numbers: p95 user wait 1.8s for acceptance (queued); mainframe processing median 12s async; zero duplicate holds with idempotent hold_request_id; audit trail on event store 7 years.

Middleware and iPaaS (MuleSoft, Boomi, Workato)

Definition. Integration platform as a service (iPaaS) and ESB/middleware centralise connectors, transformations, and routing—common in enterprises with SAP and Salesforce coexistence.

Engagement use. AI orchestration calls iPaaS-exposed API rather than point-to-point ERP—benefits: rate limiting, transformation, audit, reusable connectors. Negotiate SLA with integration COE; version APIs at iPaaS layer. Avoid double orchestration—AI team and iPaaS both retry without shared idempotency store.

Pitfalls.

• iPaaS becomes black box—debugging hard without correlation IDs.
• Per-message iPaaS cost at LLM fan-out scale—budget surprise.
• Bypass iPaaS "for speed"—breaks COE standards.

Worked example. MuleSoft API POST /experiences/servicing/escalations wraps ServiceNow + ERP validation; AI team single integration point; idempotency enforced at Mule layer with 72 hr key store; COE owns connector upgrades.

File-based and batch integration (still common)

Definition. File drops (SFTP, S3 landing, mainframe JCL) exchange CSV, XML, ISO 20022 batches—often T+1 truth for ERP analytics.

Engagement use. AI must not treat yesterday's file as live balance. Document staleness watermark in answers: "as of batch 2024-03-15 02:00." Event FileLandingCompleted triggers silver layer refresh; RAG index updates after gold validation.

Pitfalls.

• Assistant cites file data without timestamp—misleading.
• Partial file failure processed as complete.
• SFTP credentials on orchestration pod.

Worked example. Nightly SAP customer master 04:00; assistant shows master data badge batch_age=6h; intraday changes via API only for VIP tier with sync path.

Integration testing and sandbox discipline

Definition. Integration testing uses vendor sandboxes with synthetic data—never prod keys in CI. Service virtualization when sandbox unstable. End-to-end tests cover read + write + idempotency replay.

Engagement use. Sandbox refresh cadence documented; tests skip gracefully if sandbox down but block release if prod-like staging fails. Data masking when copying prod-like fixtures.

Pitfalls.

• Sandbox missing mandatory fields—false green tests.
• Prod integration user in CI—audit fail.
• No test for duplicate retry scenario.

Worked example. CI job integration-snow: creates incident with Idempotency-Key; simulates 503; retries; asserts one incident; runs against ServiceNow dev instance reset weekly.

Anti-corruption layer for legacy terminology

Definition. Anti-corruption layer (ACL) translates legacy ERP codes to domain language used in prompts and UX—prevents model hallucinating obsolete product codes.

Engagement use. Adapter maps MATNR → sku_display_name; maintains versioned dictionary synced from MDM. Prompt uses display names only; tools use internal IDs after validation.

Pitfalls.

• Raw ERP JSON in prompt—token waste and confusion.
• Stale dictionary—wrong product mapping.
• LLM asked to guess SKU from description alone in regulated ordering.

Worked example. Manufacturing assistant: user says "blue widget 220V"; ACL resolves 2 SKUs; clarifying question—not guess; order tool requires sku_id from ACL match list.

Partner and B2B API integration

Definition. B2B integrations (partner portals, industry utilities) use API keys, mTLS, OAuth client, often with strict SLA and change windows.

Engagement use. Contractual notice period for schema changes; fallback when partner down; rate pool shared across programmes—coordinate with vendor management.

Pitfalls.

• Partner throttle shared across dev and prod keys.
• AI summarises partner confidential data into wrong tenant.
• Missing legal review for AI processing partner feeds.

Worked example. Insurance bureau check API 50 TPS cap; cache negative results 24 hr; positive no cache; partner outage message scripted—not LLM invented.

Contact centre and CTI integration

Definition. Contact centre platforms (Genesys, Amazon Connect, Five9) provide agent desktop, call transcripts, wrap-up codes, screen pop. AI agent assist suggests responses and after-call summaries—integrated via CTI or event streams.

Engagement use. Real-time assist requires sub-second retrieval—pre-warm index; async summary post-call acceptable 30–60s. Respect PCI pause—no card data in transcript index. Supervisor review queue for AI suggestions before customer send (regulated sectors).

Pitfalls.

• Transcript stream to LLM before DLP redaction—PCI leak.
• Assist UI adds 8s latency—agents disable it.
• Wrap-up codes auto-set by LLM—wrong workforce analytics.

Worked example. Genesys: AI summary job triggered OnCallEnded event; summary draft in 30s; agent edits before CRM save; PCI segments masked by contact centre platform before event leaves PCI zone.

Workflow and BPM human-in-the-loop

Definition. BPM (Camunda, Pega, Appian) orchestrates human tasks—AI submits draft decisions into workflow; humans approve/reject; system of record updated only on approved path.

Engagement use. Replace direct write integration with workflow case creation carrying AI recommendation JSON. Audit trail in BPM immutable. SLA timers for human step—escalate if breached.

Pitfalls.

• AI bypasses BPM "temporarily"—becomes permanent shadow process.
• Workflow variables store full prompt—PII retention issue.
• Human rubber-stamp—no sample review of AI quality.

Worked example. Credit limit exception: AI fills recommended_limit and rationale; Pega task routes to underwriter; on approve, core banking API called with workflow_case_id idempotency; reject returns feedback to improve eval set.

Integration observability and correlation

Definition. Integration observability traces correlation_id from user message through orchestration, adapters, ERP, events—visible in single pane (Jaeger, Application Insights).

Engagement use. Mandate W3C trace context headers on all internal and external calls. Dashboards: adapter latency by system, error rate by error class, DLQ depth, idempotency replay count.

Pitfalls.

• Logs without correlation—cannot link duplicate ticket to session.
• Metrics only at orchestration—ERP slowness invisible.
• Alert on every adapter retry—noise.

Worked example. Trace corr=8f3a... shows: chat 200ms, CRM read 340ms, retrieval 420ms, model 1800ms, ServiceNow async accept 90ms; duplicate investigation finds retry without key at legacy adapter—fixed.

Data synchronisation patterns for AI context freshness

Definition. Keeping AI context fresh uses poll, webhook, CDC, or event sourcing—choice affects integration architecture.

Pattern	Freshness	Complexity	Best for
Scheduled poll	Minutes–hours	Low	Legacy without events
Webhook	Seconds	Medium	SaaS with callbacks
CDC	Seconds	High	Warehouse/lake aligned
Event sourcing	Seconds	High	Domain-driven systems

Engagement use. Align with topic 09 data architecture—integration is delivery mechanism for freshness SLA. Document max staleness per source on integration map.

Pitfalls.

• Poll every 1s on ERP—TPS ban.
• Webhook without signature verify—spoofed refresh storms.
• CDC lag 45 min but assistant promises real-time.

Worked example. CRM account changes via Salesforce Platform Events → bus → cache invalidation <30s; ERP product master nightly batch + badge in UI; policy CMS webhook immediate index job.

Integration security review checklist

Before production write path:

• OAuth scopes minimal; mTLS where required
• Idempotency on all writes
• PII minimised in transit payloads
• DLQ and alert configured
• Contract tests in CI
• SoR matrix signed
• Replay runbook tested in staging
• Rate limits and bulkheads documented
• Audit fields on AI-generated records
• Pen test scope includes tool/API abuse

Attach completed checklist to ARB pack—integration COE sign-off.

Canonical integration patterns catalogue

Reuse patterns in Architecture Guide—document engagement choice:

Pattern ID	Name	When	Avoid when
INT-01	Read-through cache	ERP slow, data tolerates TTL	Real-time balances
INT-02	Async write + poll	Write >3s	User needs instant confirmation
INT-03	Event outbox	DB + bus atomicity	No transactional source
INT-04	Idempotent POST	All writes	Vendor provides native idempotency
INT-05	Federated read	Merger multi-SoR	Single golden MDM available
INT-06	BPM gate	Regulated writes	Low-risk read-only

Reference pattern ID on integration map—speeds ARB review and pattern library growth.

Vendor API lifecycle management

Definition. SaaS vendors deprecate API versions on predictable schedules—AI adapters must track sunset dates and migration epics.

Engagement use. Calendar reminders 6 months before sunset; contract tests fail early on beta sandbox; dual-run period writes to both API versions if needed—never big-bang Friday.

Pitfalls.

• Salesforce API version years behind—security patch forces emergency migration.
• SAP OData service retired—assistant hard down.
• No vendor relation—surprised by breaking change email.

Worked example. Salesforce v52 sunset in 8 months; epic CRM-441 migrates adapter to v58 with Pact green by month 5; dual-run 2 weeks; zero production incident at cutover.

Integration testing data management

Definition. Test data for integrations must be synthetic or masked—never copy prod PII to developer laptops or CI runners without legal basis.

Engagement use. Maintain fixture library: anonymised CRM accounts, fake ERP orders, ServiceNow sandbox reset scripts. Version fixtures with adapter tests—update when schema changes.

Pitfalls.

• Prod dump in S3 "for realism"—breach.
• Stale fixtures—tests green, prod fails on mandatory new field.
• Shared sandbox manual edits—flaky tests Monday mornings.

Worked example. Fixture repo integration-fixtures/v3/ loaded into sandboxes every Sunday 02:00; CI uses same version pin; schema change triggers fixture major bump and adapter PR in same release train.

Read-only pilot integration minimisation

Definition. Stage 3 pilot should default read-only integrations until idempotency and async patterns proven—write paths are Phase 2 in transition architecture (topic 08).

Engagement use. Integration map marks Phase 1 read vs Phase 2 write explicitly; ARB approves read first; write requires separate mini-ARB with failure-mode doc.

Pitfalls.

• "Read-only" except one small write—scope creep to payments.
• Pilot write volume low so duplicates ignored until scale.

Worked example. HR assistant Phase 1: SharePoint read + ServiceNow read tickets; Phase 2: ServiceNow create with idempotency after 6 weeks read-only eval stable ≥93% pass rate.

Escalation matrix for integration incidents

Severity	Example	Response	Owner
Sev 1	Duplicate financial write	Stop write path; exec notify	Integration lead
Sev 2	ERP read down >30 min	Enable degraded FAQ	Ops + product
Sev 3	DLQ depth >500	Replay after root fix	Integration on-call
Sev 4	Single adapter timeout spike	Monitor; tune breaker	Dev team

Publish matrix in runbook portal—reduces panicked disable of entire assistant when one adapter flaky.

Integration incidents involving write paths always trigger idempotency audit before re-enabling traffic—confirm duplicate count zero in SoR.

Practice exercises

Primary exercise: Integration map and failure modes (3–4 hours)

For servicing assistant (CRM read, ITSM write, DMS read) or commercial lending assistant (LOS read/write draft, ERP read inventory):

1. Integration inventory (≥8 systems or endpoints) with R/W, auth, SoR.
2. Sync vs async decision per path with timeout budgets.
3. Idempotency design for every write—including key format and store TTL.
4. Retry/DLQ/replay policy and runbook outline.
5. Failure-mode notes: timeout duplicate, partial success, stale read, rate limit.

Acceptance criteria: Reviewer identifies SoR for each entity; write path has idempotency and DLQ; no sync mainframe in chat critical path without justification.

Stretch exercise: Event contract design (3 hours)

Design Kafka/Event Grid flow for policy publish → index refresh and user escalation → ticket create → user notification. Include schema version, DLQ, correlation ID propagation, and PII minimisation in payloads.

Acceptance criteria: Event schemas versioned; consumer idempotent; replay procedure documented.

Reflection exercise: Duplicate incident post-mortem (45 minutes)

Write one-page post-mortem for Scenario A as if idempotency not implemented. Include timeline, cost, customer impact, preventive artefact list. File in pattern library.

Questions you should be able to answer

1. What is the system of record for each entity the AI reads or writes?
2. Which integrations are read, write, or both—and who owns each API?
3. Where is sync vs async used—and what is the user UX on async?
4. What idempotency key format prevents duplicate writes on retry?
5. What retry policy applies per downstream—and when is retry forbidden?
6. What DLQ paths exist and who owns replay runbooks?
7. How is user context propagated to CRM/core (OBO, mTLS, scopes)?
8. What rate limits constrain design—and how do you bulkhead/cache?
9. What contract tests prevent vendor schema changes breaking adapters?
10. How do events refresh RAG corpus vs API polling?
11. What legacy/mainframe constraints forbid synchronous chat calls?
12. What ERP write paths require human approval—and how enforced?
13. What audit trail proves who initiated AI-suggested actions?
14. What degradation occurs when CRM or core is unavailable?
15. What versioning strategy applies to APIs and event schemas?

Negative cases

CRM as balance SoR. Wrong financial guidance. Fix: SoR matrix; live core read.

Retry POST write. Duplicate tickets/orders. Fix: idempotency keys.

Sync ERP in chat. Timeouts and angry users. Fix: async/materialized views.

Shared bot user. No accountability. Fix: OBO per user.

No DLQ. Lost escalations silent. Fix: DLQ + alert + replay.

Governor limit ignore. SaaS outage. Fix: batch/composite; session cache.

Screen scrape integration. Breaks on UI update. Fix: supported APIs.

AI writes payment. Regulatory catastrophe. Fix: human gate; no payment tool.

Stale batch truth. Answers from yesterday. Fix: freshness SLA; event-driven sync.

Event without schema. Consumer drift. Fix: registry + contract tests.

Full payload PII on bus. Compliance breach. Fix: reference by ID.

Idempotency store ephemeral. Duplicates after deploy. Fix: durable store 72 hr+.

Integration map absent. ARB blocks at write phase. Fix: Stage 3 artefact early.

Integration with Architecture Guide

Topic 24 capability	Guide chapter
Integration view, adapters	Architecture Guide
API implementation	Topic 15
Hybrid connectivity	Topic 16
Data corpus sync	Topic 09

Output

Expected outputs for this topic:

• Integration map (systems, R/W, auth, SoR, patterns)
• API/event contract list with versions
• Idempotency and retry policy per write path
• DLQ and replay runbook outline
• Failure-mode notes (timeout, stale, rate limit, partial success)
• Sync vs async decision record (ADR cross-ref)

Practice checklist

• SoR matrix reviewed with business owner
• Every write path has idempotency documented
• Retry policy distinguishes transient vs business errors
• DLQ owner and replay rate limit named
• No unjustified sync calls to slow legacy in chat path
• Contract tests planned for critical adapters (topic 15)
• Practice artefacts filed in pattern library

Related playbook content

• Architecture Guide — integration view and adapter patterns
• Delivery Guide — release of integration components
• Enterprise Architecture — integration architecture view
• Software Engineering — API, CI, contract tests
• Cloud and Platform Engineering — hybrid networking
• 8D Framework
• Architecture and cloud

Key takeaways

• System of record clarity prevents AI from becoming a shadow database or wrong-truth advisor.
• Idempotency and async are mandatory for enterprise write paths—timeouts will happen.
• Events decouple AI from fragile ERP/mainframe latency; APIs need caching and bulkheads.
• CRM, ERP, core banking, ITSM each have distinct rules—no generic "integrate to API."
• DLQ + replay runbooks are production artefacts, not ops optional extras.
• Pair with Architecture Guide for integration pattern depth.

What to do next

1. Complete integration map before enabling any write API in pilot.
2. Implement idempotency in Software Engineering CI with contract tests.
3. Align hybrid paths with Cloud and Platform Engineering.
4. Continue with Delivery and Programme Management.