Niel here, Associate Product Management Intern at Atlassian.
My team is working on some new improvements to web triggers in Forge. We’re aiming to make sure all apps with web triggers have a path to our Runs on Atlassian (RoA) badge.
Quick reminder, Runs on Atlassian is a Marketplace badge designed to help customers identify apps that a) do not transmit data outside of the Atlassian Cloud and b) provide data residency.
Keen to meet with Forge developers who have apps with web triggers, or developers who are planning to use web triggers, to better understand use cases.
I would love to hear about:
What sort of data is being sent
Why this data is important to the app
The impact some of our ideas might have on these apps
I’m happy to chat either here in this thread, or you can schedule some time with me to chat on Zoom: Forge Web Trigger Chat
our app is based in Jira Cloud. We could need WebTriggers to somehow offer an external API to read/write entities into Forge store, trigger internal app updates or update values in Forge Custom Fields just because there is no other way for customers to send or update data from automation external systems even a DC migration requires somehow an update request in our app. What I personally don’t like at all, is the fact, that WebTriggers are open to anyone. The vendor has to implement their own authentication. I would at least like to require the normal Atlassian authentication and would like Atlassian to take care of all authentication within Forge even for WebTriggers as an “external API”. This would help us a lot more and allow us to offer proper APIs in some way.
Hi @Niel-Reitmann ,
I hope this message finds you well. I’d like to clarify how Forge web triggers relate to RoA. Please don’t misunderstand me - I’m simply looking to understand this relationship better.
As I see it, web triggers provide content that is strictly defined in the permissions section of the manifest.yml. If an app doesn’t facilitate data egress, the web trigger wouldn’t be able to send any information to a third party. Essentially, a web trigger acts as a type of invocation function, callable not only from the front-end but also from other applications. Naturally, the web trigger can only return data that the app has access to and that has been explicitly prepared by the developer.
Many apps actively use web triggers for a variety of purposes. Two of the most popular use cases are:
Cross-application communication:
Web triggers are often used to send messages between apps, including cross-application scenarios. Currently, there aren’t any direct alternatives to this functionality. Perhaps, in the future, we’ll have something like cross-app events or listeners, but for now, this capability is still under development.
REST-like endpoints:
Web triggers can serve as REST-like endpoints, facilitating communication between external users or applications and the content within our app.
I hope this sheds some light on how Forge web triggers operate and their significance. Let me know if you’d like to discuss this further or need more details!