Hello Community,
We’re currently designing a bi-directional integration between Appian and multiple external distributed systems — including CRM, KIOSK, and MOBILE channels. We're evaluating two architectural approaches and would appreciate your insights, especially around Appian events, correlation IDs, and event-based routing strategies.
In this model:
When Appian creates a task (e.g., KYC Review), it exposes the task ID to an external system (such as CRM).
The external system then uses this ID to call back into Appian to complete the task.
In this preferred model:
A correlation ID (UUID) is generated at the beginning of the interaction and shared between Appian and the external system.
This correlation ID is used consistently throughout the lifecycle of the end-to-end process across all systems.
Appian does not expose any internal task or process IDs externally — and the external systems don’t share theirs either, ensuring true loose coupling.
When a subprocess within Appian (e.g., Risk Check, Fraud Check) requires input from an external system:
It registers a wait state using a Receive Message Event with the correlation ID and expected event type (e.g., KYC_COMPLETED).
KYC_COMPLETED
The external system responds to a unified API endpoint with the correlationId and eventType, and Appian routes the message internally to the appropriate subprocess or task.
correlationId
eventType
Does Appian recommend an event-driven, correlation-based approach over task ID–based integrations in distributed, multi-channel environments?
Are Receive Message Events with correlationId linkage widely used in real-world, enterprise-scale Appian implementations?
Any design patterns or examples for building a scalable, centralized event router in Appian to handle such integrations?
Thanks in advance — especially interested in input from architects or teams who've implemented robust Appian integrations with external platforms at scale!
Discussion posts and replies are publicly visible
Approach 1: Why even do this? A User Input Task is meant to directly interact with a human.
Approach 2: Did you consider cut that process into two pieces and to stop the first process after sending the message, and on the incoming event just start the second one? You might have to persist some data to DB, but I think this a better approach.
The new auto-scale architecture seems to designed with such scenarios in mind. Receiving messages through an API, then consume each message by firing off a process.
I agree. I would not use the Receive Message event. You could potentially have a ton of processes waiting on a response.
Just stop the process and start a new process on the response.
That makes sense — I understand now that once the process ends, any process variables are lost. To address that, our approach is to persist all necessary state (e.g., customer info, loan amount, risk score, stage, etc.) to a database or Appian record before ending the process.
Then, when the external system responds, we’ll start a new process using the correlation ID, retrieve the relevant data, and continue the workflow from the appropriate point.
This allows us to maintain a stateless, event-driven, and loosely coupled architecture without exposing internal task or process IDs between systems.
One concern I still have: since we have many processes with different sets of variables, what's the best way to persist process state when ending a process? Would you recommend storing everything in a flexible structure like a JSON payload inside a shared context table or modeling each process with its own CDT?
I just want to make sure we choose something scalable and maintainable as the number of services grows and want to make sure we’re thinking along the same lines here — are we aligned on this approach?
This is free advice so it doesn't come with any warranties but the approach you described makes sense to me.
How to get payed advice?
In my world of process modelling, I have a record alongside the process. And that record is what I would use. But, you can also just have a separate table which stores the correlation ID, the process model id to start, and a JSON to persist some data.
Most people here do Appian business for a living. Just ask, we are happy to help.