Hybrid stakeholder notifications in Jira Product Discovery: combining watchers and automation emails

[#1]

Summary

In Jira Product Discovery (JPD), people in custom people fields (for example Stakeholders, Project sponsors) cannot be reliably addressed via the standard notification scheme. In many setups this means important project partners do not receive updates about changes or comments on ideas/issues.

You can solve this by using JPD automation in two layers:

1. Licensed JPD users in the stakeholder field are automatically added as watchers → they receive standard Jira notifications.

2. Unlicensed people in the stakeholder field instead receive targeted emails on relevant events (comment, description change, status change) → nobody is missed, and no duplicate notifications occur.

---

Background

Jira Product Discovery is used to manage ideas/initiatives together with project partners and stakeholders. Typically, these stakeholders are maintained as people fields in Product Discovery – from a business perspective this is the “single source of truth” for who is involved. In our daily use, people started to report: “I’m listed as a stakeholder, but I don’t get any notifications.” 

Tests with real ideas confirmed it: updates were made, but no notifications were sent to the people in the stakeholder fields, unless they were manually added as watchers. But this only worked with licensed Jira users.

The core problem

During analysis the following became clear:

• Custom people fields are not 100% usable in the standard notification scheme.

• There seems to be no native mechanism to automatically notify all people from a people field on changes.

• At the same time, the stakeholder population in JPD is often mixed:

  • internal, licensed JPD users

  • external or occasional users without a JPD license

That creates a typical conflict:

• Watchers work well – but only for licensed users.

• “Extra email via automation” also works for unlicensed users – but will easily create duplicate notifications for licensed ones.

So the challenge was: How can we notify all stakeholders reliably, without spamming licensed users with duplicates?

The solution

Step 1: Quick win – automatically add stakeholders as watchers

The first pragmatic idea is a simple workaround:

• Trigger: When the content of the Stakeholder field changes

• Action: Add all stakeholders as watchers.

Effect:

• Licensed stakeholders immediately get Jira’s standard notifications.

• Unlicensed stakeholders remain “silent” (they cannot be added as watchers).

This solves only half the problem: it covers licensed stakeholders but leaves unlicensed ones out.

Step 2: Acknowledge reality – many stakeholders are unlicensed

In many organisations there are numerous stakeholders without a Jira/JPD license (management, external partners, business sponsors). Therefore “watchers only” is not sufficient.

Desired behaviour: If a stakeholder does not have a license, they should receive an email with a link to the idea/issue when relevant changes happen (description changes, new comments, status transitions, etc.).

Step 3: Avoiding duplicate notifications

If you simply “send an email to all stakeholders” and licensed stakeholders are also watchers, licensed stakeholders receive the automation email and the Jira watcher notification → double notifications and frustration.

Therefore you need a way to differentiate stakeholders. You might not be able to directly check “has JPD license?”, but you can often use groups as a proxy. Typical pattern: One or more groups contain JPD/Jira Software users. You can treat membership in one of these groups as “licensed user”.

Step 4: Final rule design – hybrid of watchers + email

The productive solution works as a hybrid:

A) When a stakeholder is added

• If stakeholder is licensed (recognised via group membership):
  → Add as watcher
  → Receives standard Jira notifications

• If stakeholder is not licensed:
  → Cannot be added as watcher
  → Will be notified via email based on events (see B)

This ensures that licensed users rely on Jira’s native watcher mechanism, while unlicensed stakeholders are handled separately.

B) On relevant events: email to unlicensed stakeholders

Define which events should trigger notifications for unlicensed stakeholders. Typical triggers:

• Changes to the description

• New comments

• Status changes (e.g. Discovery → Validated, In progress → Done)

For each trigger, send an email only to stakeholders who are not in the JPD license groups.

Example email texts

• Description changed

  Subject: [{PROJECT_KEY}] ({ISSUE_KEY}) {TITLE}
  
  “The description of issue {TITLE} has changed. Have a look here for potential updates: {LINK}”

• New comment

  Subject: [{PROJECT_KEY}] ({ISSUE_KEY}) {TITLE}
  
  “A new comment was added to issue {TITLE}. Have a look here for potential updates: {LINK}”

• Status change

  Subject: [{PROJECT_KEY}] ({ISSUE_KEY}) {TITLE}
  
  “The status of issue {TITLE} has changed to {NEW_STATUS}. Have a look here: {LINK}”

Outcome

• All stakeholders are covered (licensed and unlicensed).

• No one gets duplicate notifications.

• The model can be reused across multiple JPD projects that rely on stakeholder people fields.

Jira Product Discovery is designed for broad stakeholder collaboration – and many of those stakeholders are not licensed Jira users. At the same time, teams usually want:

• Transparency: updates must reach the right people.

• Signal over noise: avoid duplicate or noisy notifications.

• Scalability: no manual management of watchers or ad-hoc mailing lists.

This hybrid approach (watchers for licensed users + automation emails for unlicensed users) is:

• Technically simple (built on standard JPD automation).

• Organisationally realistic (respects mixed stakeholder populations).

• Reusable as a pattern across products and teams.

---

Feedback

Has anyone run into a similar challenge with notifying people from custom people fields in Jira Product Discovery? I’d be very interested to hear if there’s a more “native” or elegant way to achieve this without relying on custom automation logic (especially when mixing licensed and unlicensed stakeholders). If you’ve solved this differently – for example via notification schemes, smarter use of groups, or any JPD-specific features I might have missed – I’d really appreciate your insights or examples.

[Bill Sheboy]

Hi @Denis Paul 

Thanks for your article.  Yes, and...

One of the root causes of symptoms you describe is when Team-managed projects (TMP) were added with the People type field, several of the attributes such as emailAddress were not available to automation rules.  Here is one of the defects in JAC for that: https://jira.atlassian.com/browse/JSWCLOUD-27793

And, as Jira Product Discovery (JPD) builds upon TMP, the People fields brought that defect along.

Possible workarounds with automation rules are:

• adding a global, user-picker field instead of a People field as those are not limited in the user attributes provided to rules
• calling the REST API endpoint with the People field's accountId value to get the other user attributes.

Kind regards,
Bill