Clarification on app.connect in Forge manifest and revenue share rates eligibility

[maciejkabala]

Hi, according to the article, to qualify for Forge revenue share rates, the app must:

• Only use Forge modules (no Connect modules)
• Use Forge authentication (OAuth 2.0)
• Use Forge UI (Custom UI or UI kit)
• The app may use Forge remotes

I’d like to clarify whether using the app.connect section in the manifest still qualifies the app for revenue share rates. For example:

app:
  connect:
    key: XXX-YYY-ZZZ
    remote: connect
    authentication: jwt

remotes:
  - key: connect
    baseUrl: "https://example.com"
    operations:
      - compute
      - fetch

Does including this configuration affect the app’s eligibility?

We’re currently migrating our Connect apps to Forge and want to understand if we’ll need to remove this Forge–Connect link in order to qualify for the revenue share rates.

[SeanBourke]

Hey @maciejkabala,

Thanks for the question. The connect.app.key will be required longer term to ensure that your Forge app can be linked to the existing Connect app or modules; this will be something which will have to persist.

In a more simple lens, your app should not:

1. Declare any connectModules (this includes things like ui extensions, webhooks or lifecycle events)
2. Declare any connect scopes (these contain connect in their definition, such as read:connect-jira)

Once your app has achieved this, it should also no longer require the app.connect.remote and app.connect.authentication, as there are no underlying scopes or modules.

[maciejkabala]

Hi @SeanBourke, thanks for the clarification.

Just to make sure I fully understand — if our Forge app includes the app.connect section and declares Connect scopes (such as read:connect-jira), would it still be eligible for the Forge revenue share rates, or would that automatically disqualify it?

I want to be certain before we proceed with our migration.

[SeanBourke]

Hey @maciejkabala,

The declaration of Connect scopes would be the problem here.

[jhazelwood]

The scopes are an issue, and you typically can’t use the scopes anyway without some kind of JWT authentication which means you need a lifecycle handler declared under connectModules anyway.

[scott.dudley]

Hi Sean/James,

Regarding the Connect scopes being disqualifying for the Forge revenue share:

Is there any chance of apps being able to retain Connect scopes for some limited time, but still allowing those apps to be billed as Forge? (Like by extending this leniency through, say, the end of Connect support?)

The main benefit would be to take advantage of the automatic inheritance of Forge permissions from the wider Connect scopes without forcing admin upgrades, with the latter being a big pain point.

A lot of vendors will be rushing to submit upgrades on Jan 1 to avoid taking a revenue hit, and I suspect that a number of these migrations will be technologically premature.

This idea does not seem like it would create a problem with an elevation of privilege (since the end users already consented to the wider Connect scopes). If it were not for the revenue share change, vendors would also likely have outfitted their app with whatever other constraints were required to allow them to continue to use the broader Connect scopes (like having an active do-nothing Connect module or whatever).

I think this would still meet Atlassian’s goal of moving vendors over 100% to Forge, so could this be a workable compromise?

Scott

PS: Similar to the CLI’s messages about “this app qualifies for RoA”, it would be really nice if the CLI would also report in an authoritative manner “this app [qualifies/does not qualify] for the Forge revenue share”…ideally, long before Jan 1. Or maybe it already does (I admit that I haven’t updated it in the last month).