Background

Today email notification templates (subject, sender, HTML/text body, Slack body) are customizable in Message templates, but there is only one set of templates per instance. Every approval, regardless of its purpose, sends the same wording. Customers running multiple distinct approval scenarios cannot tailor the message to each one.

Concrete driver: a customer runs three different kinds of approvals. Each needs different email content while still carrying the approve/reject action buttons, and they need to control which content is used per project, not globally.

Goal

Let administrators define multiple named notification profiles (each a complete set of email templates) and choose which profile is used when an approval is created, while keeping today's single set as the always-present Default.

Business value

• One product can serve different audiences/scenarios with appropriately worded notifications (compliance tone for emergency changes, lightweight tone for routine sign-offs, etc.).

• Templates can be aligned to specific projects/teams instead of a one-size-fits-all instance-wide wording.

• No disruption for existing customers: those who never create a profile keep exactly today's behavior.

Functional description

Notification profile

• A profile is a named, complete set of notification templates, equivalent in scope to today's Message templates.

• There is always a built-in Default profile, equal to the templates used today. It cannot be renamed or deleted.

• Administrators can create additional custom profiles, rename them, and delete them.

Managing profiles (Message templates page)

• A profile selector is added above the existing template selector. The page always shows it (even when only Default exists).

• A custom profile is created inline via a "+" control, with a pre-filled unique default name that the admin can accept or change.

• A selected custom profile can be renamed (inline) or deleted (with a confirmation step).

• Each custom profile shows its id next to its name in the selector, so admins can copy it for use when creating approvals via the REST API. (Id is shown only here, on the Message templates page.)

• Switching profiles reloads the editor with that profile's templates.

• A new custom profile starts by inheriting all templates from Default; the admin only overrides the specific notification types they want different. A clear message communicates this inheritance, and overridden types are visually marked.

• When Default is later edited, custom profiles automatically pick up those changes for any notification type they have not overridden.

Choosing a profile when an approval is created

• A profile can be assigned at the approval definition level, so all approvals of that type use it (this is how the three approval-type scenarios get distinct content).

• A profile can also be chosen at creation time across every way an approval can start: from a work item / page, from a Jira workflow transition, from Automation, and via the REST API (using the profile id shown on the Message templates page).

• The profile selector/option only appears when at least one custom profile exists for the instance; otherwise Default is always used and nothing changes for the user.

• The profile is chosen at creation only; it is fixed for that approval afterwards.

• If no profile is chosen at any level, the approval uses Default.

Acceptance criteria

1. With no custom profile defined, the product behaves exactly as today everywhere (no profile selectors shown, Default used).

2. An admin can create, rename, and delete a custom profile from the Message templates page; Default cannot be renamed or deleted.

3. Each custom profile's id is visible next to its name on the Message templates page and can be used as the profile id in the REST API.

4. A new custom profile shows Default's content until specific notification types are overridden; editing Default afterwards updates non-overridden types in custom profiles.

5. An admin can assign a profile to an approval definition; approvals created from that definition use it.

6. A profile can be selected when creating an approval from a work item/page, Jira workflow, Automation, and the REST API, but only when at least one custom profile exists.

7. The selected profile determines the wording of all emails for that approval, while approve/reject buttons remain present and functional.

8. Deleting a custom profile makes any definitions/approvals that referenced it fall back to Default, with no errors.