In the previous episode, we built the foundation of a Jira Configuration Explorer app that surfaces workflow transitions and their associated screens, powered by the Search Workflows REST API and a jira:adminPage UI.

In this follow‑up, we’ll complete that experience by resolving raw screen IDs into human‑readable screen names, wiring them into a DynamicTable, and making sure our REST paths and query parameters are constructed safely with the route tagged template function.

We’ll walk through how to:

• Call the Jira Get screens REST API from a Forge resolver, batching and paginating requests so you can safely look up hundreds of screens by ID

• Join workflow transition data with screen metadata and display everything in a sortable DynamicTable that’s tailored for Jira admins

• Turn each row into a navigation hub using Link components that deep‑link to the workflow editor, specific transitions, and classic screen configuration pages

• Avoid common pitfalls when passing parameters to route, including safely handling query strings with URLSearchParams to prevent path traversal and query injection issues

By the end of the session, you’ll have a configuration explorer that not only lists which workflows use which screens, but also gives you clickable, admin‑friendly navigation and a solid pattern for combining multiple Jira REST APIs in a secure Forge app.