The Chained Macro
A team builds a batch macro that reads a control parameter file and, for each row, calls a second macro that standardizes addresses. The outer macro runs 3,000 iterations and takes 40 minutes. It fails on iteration 2,847 with a generic 'Tool #12: Error' and no row context. The inner macro has a 'Cancel Running Workflow on Error' setting enabled. The team also wants the app to be usable interactively with a file picker and a run button.
1. Why is the failure hard to diagnose, and what changes make it debuggable?
Read the worked answer
The outer macro reports a generic tool error with no iteration context, and the inner macro's 'Cancel Running Workflow on Error' aborts the whole run on the first bad row, so the failure surfaces far from its cause. There is no record of which control row triggered it.
Make it debuggable: (a) turn off 'Cancel Running Workflow on Error' in the inner macro and instead route errors to an output so the outer macro can log the failing row; (b) add a Message tool inside the inner macro that includes the current control value (e.g. address ID) in the message; (c) write a per-iteration log (iteration number, input row, status) to a .yxdb so the failing iteration can be replayed in isolation. Then reproduce iteration 2,847 alone.
2. How would you convert this batch process into an interactive app while keeping the batch capability?
Read the worked answer
Use an App (or a macro configured as an analytic app) with an Interface layer: a File Browse tool for the control file, a Date/Text input if needed, and a Run button. The app should call the same batch macro so logic is not duplicated.
To keep both modes: expose the control-file path as a question, and in the app workflow feed the selected file into the batch macro's control input. For scheduled batch runs, keep a separate scheduled workflow that points at the standard control file. Test the app in Designer's app-run mode (not just the canvas) because interface tools behave differently there, and confirm the error-logging from the first task still fires when run as an app.