Customizing columns for Developer Escalation page

[Danielle Bonneau]

I enabled the "Developer Escalation" feature and am noticing that the page itself can't be customized at all - like you can't change the columns displayed.  Is there something I'm missing?  Is there a reason this is so static compared to the queues?  

I love the idea of the Support team being able to easily create a escalation tickets for devs to triage, but without the customizable columns, the developers won't be able to see the Urgency or Due Date which is critical for them to prioritize the column correctly.

Seems like I'll need to just create an old-fashioned queue and pair with automation to create the ticket instead? 

[Agha Jan · Accepted solution]

I don't think you're missing anything. If the Developer Escalation page doesn't provide the same column customization options as queues, then using a separate queue with automation may be the better option.

For a development team, having fields like Urgency and Due Date visible is pretty important for prioritization. A customizable queue would also give you more control over which information the developers see.

It would be great if Atlassian added column customization to the Developer Escalation page in a future update.

[Jean Horn · Accepted solution]

Hi there! Welcome to the Atlassian Community! 👋

I completely understand where you're coming from. Having visibility over critical fields like Urgency and Due Date is essential for development teams to properly prioritize incoming work, so it makes total sense why the static layout of this view feels limiting.

You're not missing anything! The Developer Escalation view is intentionally simple and static. Since it doesn't allow field customization, the best approach for teams needing tighter control is indeed to pair a dedicated Jira Software project with Jira Automation to clone or sync tickets.

💡 Why is it static, and when should you use each approach?

The Developer Escalation feature was designed as a lightweight, low-friction bridge to give developers visibility without cluttering their workspace. However, depending on how your development team operates, a separate Jira Software board might be a much better fit:

• Use JSM Developer Escalations if: You want a cheap, quick way for developers to view and comment on support tickets without letting them touch the workflow, change boards, or talk to customers.
• Use a Separate JSW Board if: Your developers operate in Sprints, need to prioritize bugs against new features, use automated releases, and want full control over their own statuses and columns.

📌 Good to Know

• Customization Flexibility: Moving to a Jira Software project paired with automation allows you to map any custom fields (like Urgency, Priority, or Due Date) and even automate comment syncing between both teams.
• Marketplace Apps: If you ever need complex, multi-project or cross-instance syncing beyond native automation, there are also dedicated sync apps available on the Atlassian Marketplace.

If you'd like help setting up the automation rules or configuring the cloned project workflow, just let me know—I'd be happy to share a step-by-step guide!

If this explanation helped clarify things, feel free to mark this response as Accept Answer so other community members with the same question can find it easily! 🚀