Skip to main content
A
ahmadb3492
April 23, 2025
Question

Event-Driven vs Task-ID Based Integration in Appian with Correlation ID and Message Events

  • April 23, 2025
  • 7 replies
  • 1 view

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.

Approach 1: Task-ID Based Integration

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.

Approach 2: Event-Driven Integration with Correlation ID (Using Appian Events)

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).

  • 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.

Questions:

  1. Does Appian recommend an event-driven, correlation-based approach over task ID–based integrations in distributed, multi-channel environments?

  2. Are Receive Message Events with correlationId linkage widely used in real-world, enterprise-scale Appian implementations?

  3. 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!

    7 replies

    stefanhelzle0001
    stefanhelzle0001
    April 23, 2025

    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.

      mathieud0001
      mathieud0001
      April 23, 2025

      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.

      A
      ahmadb3492Author
      April 23, 2025

      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?

      Terms & ConditionsAccessibility statement