I have to rewrite our training manuals again because the platform reporting is severely lacking. When teaching new administrators how to debug their Architect flows, they rely on the Flow Execution History. But if you use an Architect expression to dynamically select an audio prompt variable, the execution log simply displays ‘Played Prompt Variable’ instead of the actual name of the prompt that was resolved at runtime. It is impossible to troubleshoot whether the correct language greeting was served. Is there any method to force Architect to log the resolved string value of dynamic prompts, or do I have to instruct my students to inject arbitrary Set Participant Data blocks just to see what their flows are doing?
Hello Isa. I understand your frustration, but this presents a wonderful opportunity to leverage the newer diagnostic tools. Our enterprise administrators completely love the updated Flow Outcomes feature for this exact scenario.
Instead of relying on the raw execution history, you can define a unique Flow Outcome for each language path or prompt selection. When the expression evaluates, trigger the corresponding outcome.
This provides a beautiful, organized view in the workspace analytics without cluttering your interaction details with participant data strings. It is a fantastic way to teach new users about business reporting.
I agree with the first reply. In my experience optimizing routing, using Flow Outcomes is the best practice. However, if you only need this for debugging, there is another option.
You can enable the ‘Debug Level’ tracing in the Architect flow settings before you publish. This will capture the evaluated variables, including the resolved prompt names, in the detailed tracing logs.
You must remember to turn this off in production because it consumes excessive storage and can slow down the flow execution slightly. It is very helpful for training environments.