23% of Part II — the last use case, per the exam's own recommended order.
3 tasks · this deck covers task 3 of 3
↑ Create a Report OverviewSame testing mechanic covered throughout this study guide — the operational twist for a report flow is that "correct" means the final Stringify output is valid, well-shaped JSON with the right counts inside it.
General flow testing — the Run button, test data, Execution History, testing individual cards — is covered there in depth. This deck adds only the angle specific to testing a report-building flow.
To test, "click Run in the toolbar when editing a flow" and supply test data — "the execution history shows the data as it passes through each card in the flow." For a report flow, walk that history through the exact chain built in Tasks 1–2: Group By → Length (per type) → Add (total) → Object Construct → JSON Stringify.
→ Group By / Length outputs — per Common Error Messages (Sub 2), an array-index or invalid-type-conversion error here usually means the grouping path didn't match the user object's actual field structure.
→ Object Construct output — confirm every key you expect appears before it reaches Stringify; a missing key is silent until you inspect the object, not a runtime error.
→ Stringify output — the final string should parse back cleanly; if it doesn't, the mismatch traces back to whichever Construct input had the wrong type.
Sources: help.okta.com/wf — connector-builder/test-flows.htm (full deck: Troubleshooting Flows, Module 1)