Integrations Inventory and Attributes

Description — How often this integration executes or is triggered.

Benefit(s) — Enables integration scheduling analysis and capacity planning. Understanding the mix of real-time, near-real-time, and batch integrations is essential for infrastructure sizing and SLA design.

Source — Manual.

Examples — Real-time (sub-second), Near-real-time (seconds to minutes), Event-driven (on trigger), Hourly, Daily (specify time), Weekly, Monthly, On-demand, Ad hoc

Notes — For scheduled integrations, note the schedule in parentheses where relevant (e.g., Daily (02:00 UTC)).

Description — The typical number of records, messages, files, or transactions processed per execution or per day.

Benefit(s) — Supports capacity planning, anomaly detection, and SLA design. A sudden drop in average volume for a high-frequency integration may indicate a silent failure.

Source — Manual.

Examples — 500 records per execution, 10,000 messages per day, 1 file per batch run

Description — The maximum observed or expected volume per execution or per day — the high-water mark.

Benefit(s) — Needed for infrastructure sizing and burst capacity planning. Integrations that perform acceptably at average volume may fail at peak volume if infrastructure is sized only to the average.

Source — Manual.

Examples — 5,000 records per execution (month-end), 100,000 messages per day (peak trading hours)

Description — The agreed performance target for this integration — the maximum acceptable end-to-end latency or processing time.

Benefit(s) — Provides the measurable baseline for integration monitoring thresholds and incident escalation criteria. Without an SLA, there is no objective basis for declaring an integration degraded.

Source — Manual.

Examples — Under 500ms end-to-end, Within 15 minutes of trigger, Completed within 4-hour batch window, Next business day

Description — Whether this integration has built-in retry behavior on failure, and how many retries are attempted before the message is dead-lettered or an alert is raised.

Benefit(s) — Surfaces integrations with no resilience mechanism — a single transient failure causes data loss with no recovery path. Identifying no-retry integrations is a key risk management action.

Source — Manual.

Examples — 3 retries with exponential backoff, No retry (fire-and-forget), 5 retries then dead-letter queue, Infinite retry until manual intervention

Notes — Integrations with No retry that carry Mission-Critical or sensitive payloads are a governance finding requiring remediation.

Description — How failed records, messages, or files are handled when they cannot be successfully processed after all retries are exhausted.

Benefit(s) — Identifies integrations where failures result in silent data loss versus those with explicit recovery paths. Organizations that cannot answer "what happens when this integration fails?" have a governance gap.

Source — Manual.

Examples — Dead-letter queue with alert, Manual review queue, Rollback and alert, Log and continue, Halt batch and alert, Email notification to owner