To clarify my specific setup and the exact point of failure, let me detail what happens in the flow right now. I'm currently using an Execute Code card to handle the process. The Current, Blocking Process (Synchronous): Code Card Execution: The user provides data, and the flow reaches the Execute Code card. API Call: The code calls my Supabase Edge Function (via an HTTP request). The Wait (The Freeze): Crucially, the code card is designed to await the response from Supabase. It looks like this: Flow Blockage: Because the Execute Code card (and the code within it) is synchronous by design within the Botpress flow engine, the entire conversation thread must wait for the external network latency and processing time to complete. The user sees the typing indicator for the entire duration. My Point of Frustration: I hoped that even if I didn't assign the variable immediately (workflow.variables.resultData), the function call itself could run in the background. My ideal scenario was: Launch the Supabase function call. Let the Execute Code card finish instantly. The flow advances to the next conversational step. The Supabase function eventually sends the result back to Botpress somehow. I assign the variable later in the flow using the data that arrived (this is the part I don't know how to implement). However, if the Execute Code card includes the standard network request logic, it locks the flow until the API call is fully resolved. The whole Botpress conversation context is frozen because the flow is waiting for the code card to return a value, not just fire a request. So, the core of the problem is: How do I make the Execute Code node initiate the task and then immediately exit and return control to the flow, knowing the data will arrive later?

but in the code i m waiting for the data to assign them to variables

then it doesnt wait for the api call to complete before moving to the next line of the code

if that works in your setup

but if you need to parse and extract data from the response that wont work

✅ Solution: Asynchronous Processing (The "Fire and Forget" Pattern) The core principle is to offload the slow task to a dedicated backend system (like Supabase) and use an automated cascade of events on the server side to execute the work, while the conversational front-end (Botpress) maintains user engagement. 1. Phase "Fire" (Initiation) Action: The conversation initiates the process by making a single, rapid API call to the backend. Purpose: This call immediately triggers the upload of the data and an insertion into the database, setting the initial status to PENDING. Result: The API returns instantly (typically in milliseconds) with a unique ID for the job. The conversational flow captures this ID and continues immediately without blocking, thus preventing timeouts and user frustration.

2. Phase: “Forget” (Automated Backend Processing) All slow operations run entirely on the server in the background. Decoupling: Instead of running one long, blocking function, the task is split into smaller steps (for example, Classification followed by Detailed Extraction). Automation (Triggers/Webhooks): Database triggers—such as PostgreSQL triggers—monitor changes to the status column and automatically start the next step in the workflow. Cascade Flow: Trigger 1: When the status changes to PENDING, it starts the Classification process. Trigger 2: When the status updates to CLASSIFIED, it automatically starts the Extraction step (the long-running 40-second task). Result: The slow operations run continuously in the backend, and the record progresses through the statuses: PENDING → CLASSIFIED → COMPLETED.

3. Phase "Checkpoints" (Retrieval) While the backend processes the data, the conversational flow engages the user with other questions. When the data is finally needed: Mechanism: The flow uses a series of "Checkpoints" (Execute Code cards) that perform quick Polling (a fast SELECT query) against the database using the unique job ID. Looping Logic: If the database status is not yet COMPLETED, the code returns a "WAIT" signal. The flow then enters a small, controlled loop (e.g., Wait 2 seconds, then retry the Checkpoint) until the data is ready. Success: When the status is COMPLETED, the flow retrieves the pre-processed results and uses them to continue the conversation (e.g., display the results, proceed to calculation).

what do you guys think of this ?

If the extracted data is parsed correctly while the convo is still going on that should work