Post-call conditional send_sms actions always skipped despite exact condition match — possible execution-timing bug

Support Help
1

Issue: We have five post-session send_sms tools configured with conditions against post_call_analysis_data fields (volcano_call_category, sms_opt_in). On the call above, the finished call’s custom_analysis_data recorded:

  • sms_opt_in: "yes"
  • volcano_call_category: "business"

These values exactly match the condition on every one of our five conditional SMS actions — including Business_Call_Notification, whose entire condition is the single equation volcano_call_category == "business".

Despite this exact match, the public call log shows all five conditional actions were skipped, roughly 2 seconds after the call ended:

textCopy

Skipping session tool Business_Call_Notification: condition not met
Skipping session tool business_call_notification_bruno: condition not met
Skipping session tool personal_call_bruno: condition not met
Skipping session tool personal_call_cesar: condition not met
Skipping session tool send_sms: condition not met

We previously had a typo in these conditions (capitalized values like "Business" instead of "business"), which we’ve since corrected to match the enum choices exactly (verified in both version 12 and our draft version 13). Even after that fix, on a fresh test call, the condition still evaluates as not met despite the recorded analysis data matching perfectly.

What we’re asking:

  1. Can you confirm whether this is an execution-timing issue — i.e., whether the condition check for post-session tools runs before post_call_analysis_data is fully populated/available, causing it to evaluate against stale or empty values?
  2. If so, is there a supported way to guarantee send_sms (and other post-session tools) wait for post-call analysis to complete before evaluating their conditions?
  3. If this isn’t a timing issue, what are we missing about how these conditions reference post_call_analysis_data fields?

Happy to provide additional call IDs or account details as needed.

2

Hey @estimates

Thanks for the detailed report and testing.

Based on the Agent Workflow behavior, post-call functions should run after Post Call Extraction, so this does not appear to be an expected timing issue. The == comparison is also case-insensitive.

Could you please share a recent Call ID where this occurred? We can review the execution logs and investigate why the condition was evaluated as not met despite the recorded analysis data matching.

Thank you!

3

One useful way to isolate this might be to treat the condition evaluation and the downstream SMS outcome as two separate things.

Since Retell says the post-call function should run after extraction, I’d try a very small controlled matrix:

  • same agent/version
  • same call flow
  • only one conditional, send_sms
  • one test where, volcano_call_category = business
  • one test where it is a different value
  • record the Call ID, extracted field value, condition result, and whether the SMS was actually sent

If the first case still shows the extracted value as “business” but the conditional action is skipped, that gives Retell a very clean reproduction case without the other four actions adding noise.

I’d also keep the final SMS delivery as a separate verification point. A condition evaluating correctly is one thing; confirming the message actually reached the intended destination is the business outcome.