I wouldn't treat all three integrations the same way, since Appian gives you different tools depending on the protocol and timing requirements. For the SOAP mainframe, I'd use an Appian Connected System with a SOAP-based integration, or a custom web service smart service if the WSDL is complex or legacy-heavy. Since mainframes are often slow and unreliable, I'd never call this synchronously from a user-facing interface — I'd push it into a process model where I can control timeouts and retries. For the REST API with OAuth2, I'd configure a Connected System with OAuth2 authentication so Appian handles token refresh natively rather than me hand-rolling token management in expressions, which keeps credentials secure and centralizes auth logic. For the real-time event stream, I'd expose a web API, or use Appian's native Kafka connected system if available in that version, as the ingestion point, landing events into a process model via a start event or message event rather than polling.

The most critical requirement here is guaranteeing no data loss, so I'd separate data capture from data transmission entirely. The interface would save user input into an Appian data store or record type immediately upon submission, before any external call is attempted. This means the source of truth for what the user entered lives in Appian first, decoupled from whether the downstream system is currently reachable. The actual integration call would happen inside a process model, not inline in the interface's submit logic, because interfaces are request/response — if the external system times out, the user's session shouldn't be the thing blocking or losing their data. I'd trigger an asynchronous, decoupled process after the save, so the interface returns immediately to the user with a "submitted, processing" state rather than hanging on a call to a system that might be down.

From there, resilience gets built into the process model itself. I'd configure error handling and exception handling on the integration smart service nodes so a failed call doesn't kill the entire process, and route failures to a retry sub-process using a timer event to introduce delay and exponential backoff rather than hammering a downed system immediately. I'd cap retries, say at five attempts, and then route to a manual exception queue — a task assigned to an admin or support group — so failures don't just vanish silently. Because Appian process instances are persisted, a process waiting on a timer or a failed node stays alive in the engine, so once the external system recovers, the retry logic, or a scheduled sweep process that checks for pending or failed records, picks it back up automatically without any developer intervention. I'd also make sure retries don't create duplicate transactions downstream by passing a unique correlation ID with each outbound call, so the receiving system or Appian itself can detect and ignore duplicates.

Finally, I'd add a status field on the record — pending, sent, failed, confirmed — visible in a dashboard, so both users and support staff can see exactly where a submission is in its lifecycle instead of treating integrations as a black box, and I'd log integration attempts including payload, response code, and timestamp to a dedicated audit data store for troubleshooting intermittent failures with systems Appian doesn't control. The core architectural principle driving all of this is that interface responsiveness should never depend on external system availability, and process logic should never assume a downstream call will succeed on the first try. By decoupling data capture from data transmission and building retry and exception handling directly into the process layer, the application stays resilient regardless of what's happening with the mainframe, the REST API, or the event stream, and recovery happens automatically instead of requiring someone to manually re-trigger failed transactions.