Customize fields in the Incident Summary card on Post-Incident Review (PIR)

[Svetlana Risteska]

When a Primary Incident is linked to a PIR in JSM, an Incident Summary card is rendered on the PIR issue, showing a fixed set of fields pulled from the Primary Incident: Incident created / ended, Ongoing incident, Time to resolution, Assignee, Priority, Responders, Affected services.

The problem: this set is hard coded — there is no way to add, remove, or reorder fields in the card. Custom incident fields important to review process (e.g. Severity, Customer Impact) cannot be surfaced here, and there is no configuration option under Project Settings → Work Types → Post-Incident Review to change this.

Ask: Is there any way to configure which fields appear in this card that I'm missing? If not, I'd like to raise this as a suggestion — teams should be able to tailor the Incident Summary card to match their incident tracking setup, just like field layouts can be customized on other work types.

Related: There is an existing feature request JSDCLOUD-12167 covering PIR template customization broadly, but it does not specifically address the Incident Summary card and the ability to configure which fields are pulled from the Primary Incident.

Has anyone found a workaround?

[Arkadiusz Wroblewski]

Hello and welcome to the Community @Svetlana Risteska 

There isn't a native setting to customize fields inside that built-in Incident Summary card because it's a hardcoded UI component.

You can use Jira Automation and "try" to pull smart values like Severity or Customer Impact from the original incident directly into the PIR description or sync them to custom fields on the PIR issue type.

That's all workaround I can think.

Best 

Arkadiusz 

[Svetlana Risteska]

Thank you for the clarification.

Yes — we’re seeing similar workarounds becoming increasingly common whenever fields can’t be exposed as native configuration options. Jira Automation can help bridge the gap, but they remain workarounds rather than a true solution.

A similar limitation is already captured in suggestions like JSDCLOUD-4328 (Add fields – view only in Customer Portal), where the proposed approach again relies on Forms to expose additional information to customers.

At the same time, this approach introduces growing complexity in both development and long-term maintenance of numerous automation rules. It also significantly increases the number of automation executions, which can add noticeable load to the system itself.

Hopefully, this will gain visibility as a broader topic worth considering for future enhancements toward more flexible, native field configuration in JSM.

[Arkadiusz Wroblewski]

@Svetlana Risteska 

Yes, I understand your concern. Please spread the word about this case and encourage people to upvote it to get more attention to it.

Best 

Arkadiusz 🤠