Hi @Jeffrey Gementiza welcome
Handling responses from PagerDuty in automation can definitely be tricky, since the on-call endpoint returns an array of objects with nested user, schedule, and escalation_policy properties. The good news is that {{fetchedPagerdutyOncallList}} behaves like any other smart value list, so you can iterate and filter it once you know its shape.
Before anything else, it is worth flagging that the native PagerDuty actions (Create incident, Get on-call users, List services, etc.) are documented as Jira Automation steps, not Confluence Automation. If you are working inside a Confluence flow, you are likely calling PagerDuty through a Send Web Request action, or your rule is actually a Jira automation. That distinction matters because the smart value shape depends on which path you used. Either way, the first step is to log the raw output. Add a Log action or send yourself an email containing just {{fetchedPagerdutyOncallList}} so you can see whether it came back as a parsed object, an array, or a JSON string.
For the PagerDuty oncalls endpoint, each entry in the array typically contains escalation_policy, escalation_level, schedule, user, start, and end. So once the list is parsed, you can iterate it with {{#fetchedPagerdutyOncallList}}{{user.summary}} on {{schedule.summary}}{{/}} to print each on-call person, and combine it with {{#if(equals(escalation_level, 1))}}...{{/}} to narrow to just the primary responders. If you only need the top of the rotation, the cleanest approach is to pass "Earliest only" as true in the original action so PagerDuty filters server side and you do not have to filter in smart values at all. If the response came back as a raw string rather than a parsed object, chain .asJsonObject on it first before traversing into nested fields.
One important limitation to be aware of, automation does not yet support JSON path expressions or built in filtering on web request responses, tracked as AUTO-466. For more complex filtering, the community workarounds involve advanced branching to process records one by one, or flattening to a delimited string and applying .match with a regex. @Bill Sheboy community article on dynamic searches within a list walks through that pattern. If after inspecting the raw payload the structure still does not match what your filter expects, I would suggest raising a support ticket and including both the logged output and your filter logic so they can confirm how the response is being parsed in your specific flow.
Hope this helps!
Helpful links:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.