Updates to product events

:sparkles: UPDATED - Updated Jira and Confluence product events

We’re introducing product events for Jira and Confluence that have different names and provide more contextual information in their payloads. These replace the current product events that start with avi:activity:.

:construction: NOTICE - DEPRECATION Removal of avi:activity product events

With the introduction of the new product events, all current product events that start with avi:activity: are deprecated and will be removed on 23 February 2021.

If you have existing product event apps, you will need to update the event names listed in your manifest and the way you extract data from payloads. The pages for the new Jira and Confluence events include a mapping of old events to new events to help you migrate your product event apps.


thanks a lot for the update :slight_smile:

Will there be UserDeleted and GroupDeleted events soon? For my App I will need to set custom app permissions and would like to clean them up once a user or group gets deleted.

thanks :slight_smile:

1 Like

Thanks for the expanded payloads and additional events, though I’d appreciate a clarification on the underlying platform strategy and consistency:

The previous event schema (avi:activity:*) seemed to embrace the major industry trend towards “describing event data in a common way”, where a unified event envelope plus event type specific payload eases generic event routing and integration etc. (notably exemplified by AWS EventBridge and CNCF CloudEvents).

The new product specific events for Jira and Confluence now lack the envelope entirely (thus all contextual metadata), which requires additional code to retrofit a generic wrapper for consistent cross-product event handling, for no immediately apparent reason.

A more specific oddity seems to be the unification from avi:activity:commented:(page|blog) to avi:confluence:created:comment, which in itself might more accurately reflect the backing content model, only to be an immediate DX head scratcher due to the simultaneous introduction of avi:jira:commented:issue and avi:jira:mentioned:(issue|comment).

The partially severe and never reconciled UX and DX inconsistencies between Jira and Confluence (and Bitbucket for that matter) for semantically similar concepts have been a major long-time pain for Atlassian users and developers alike, so I’ve been hopeful that the cross-product Forge platform would imply strategic improvements in this regard.

I realize that platform strategy and consistency as such would be topics for a separate thread, but could you expand a bit on what motivated the changes at hand?


Hi @clouless,

There are no immediate plans to publish these specific events. We are working on putting a specific roadmap together on new event types to be able to provide more clarity on this, but user-related and delete events both have specific hurdles we need to overcome before we can publish them and as such are not currently high on the list.
I would be keen to hear how broad of an issue this though to see if we should prioritise this work.

Cheers, Sam.

Hi @sopel,

Thank you for your feedback, and I would be happy to share with you our thinking for this shift in direction. The previous generic event schema and it’s associated event source was chosen to be able to provide a relatively fast way to provide some level of product event support during the beta of Forge. It enabled developers to build apps based on this and provide us with valuable feedback on this capability. We actually received lots of constructive feedback on this and specifically ran a project to address them. This work is the result of that project.
Some of the key feedback we received was that the events didn’t contain enough contextual information and there simply weren’t enough of them. By shifting to this strategy, we feel like we are addressing this. By providing a product-specific event, we are able to provide much more context-specific data in them. The events are now sourced from the products themselves, instead of being aggregated and transformed into a single generic payload that was sometimes difficult to understand. By going product-specific it also enabled us to significantly increase the pace at which we are able to release new events as we no longer need to perform this step and can get them in the hands of our partners faster. We have big plans on how broad we want to support Forge at Atlassian and we needed a scalable solution to achieve this.

Hopefully, this answers your question, otherwise, I would be happy to discuss this further and drill into any specific requirements you would like to see in this service.


Ok cool :slight_smile: So in my case I would use the users accountId and the groupName to store specific permissions for my app. My app delegates some functionality to normal users based on their group membership or userName(accountId).
=> Buzzword: Delegated Administration
I think there are many other Apps out there that will have the same issue.
These Delete Events help cleanup those permissions.
For now I can live with cleaning up the deleted groups or users once I “stumble” upon them when e.g. an admin sets new permissions and the list contains a deleted user. But that is not a very clean way. Also if someone has granted permissions on group “team-awesome”. Then deletes this group in Jira. And half a year later someone again creates the group “team-awesome” => The group members will have permission to stuff they should not have because the App did not get a GroupDeleted event and a permission for that group might still exist. (I hope accountIds are somewhat unique and this problem is not so urgent there).
I hope this clarifies the need for those events :slight_smile:

1 Like

II thought I’d share my feedback on this a bit. Expanding event specific payload is a good thing as it gives apps more context about what is going on with the event. That said, I think there should be some common envelope information about what the event is and what triggered it. Your examples already show how to register a single trigger to receive multiple events. The problem is the app can’t tell which event type invoked the trigger and this may be important - especially if the event content varies by type. I suppose an option is to register a custom trigger function for each event but that could dramatically increases the api footprint of the app if it listened to many events.

1 Like

Thanks for the feedback @jeffryan. We are actively looking at solutions to this and how we can provide developers with this event context to identify the event type. The options we are considering at the moment include injecting this kind of information into the event payload itself, amending the context your function receives to include this, or moving to a similar model as CustomUI and providing support for resolvers eg. ( resolver.define('avi:confluence:created:page', ({ payload, context }) => { // Do something });. We may end up doing all three, and it’s just a matter of order and priority. But it’s good to know that this is something important to our community and we are focusing in the right areas.

1 Like

I think adding it to the context is a good approach since it really is contextual information about the event. Plus it won’t break your existing API. Thanks @SamPurchase

1 Like