Forge just fixed the oldest workaround in JSM portal apps

[#1]

Confession first. I build internal Forge apps that pull data from other enterprise platforms into Jira Service Management, and somewhere in that work lives the same workaround every portal app builder has written: the moment work moves to the background, the app stops being the customer and becomes a service account.

Not because anyone wanted it that way. Because portal-only users simply could not be impersonated outside a live session. So the scheduled job runs as the app, the follow-up comment posts as a bot, and the request history quietly tells a small lie about who did what.

This summer, the Forge changelog fixed it, in two quiet steps. June brought online impersonation for portal-only users. And now: offline impersonation for portal-only users. Your app can call asUser(accountId) for a customer account from a scheduled trigger or a queued job, no session required.

I read that entry twice to make sure it said what I thought it said. It does.

Why this is bigger than it sounds

Think about everything downstream of "who did this":

• The follow-up comment now belongs to the customer it was made for
• A background permission check now answers what this customer can see, not what an over-privileged service account can see
• A portal workflow can start in a click and finish an hour later without the identity breaking halfway

One sentence version: identity no longer depends on timing. The customer is the customer whether the code runs now or at 3 AM. If you have ever explained to an auditor why half a request's history is authored by a bot, you know exactly what this is worth.

If you build

Four things, straight from the changelog and manifest reference: declare the impersonation scopes as a map with allowImpersonation: true on each, call asUser(accountId) in your backend, use the offlineUserAuthToken mutation if you are on Forge remotes, redeploy. Then go check that your background actions surface properly in request history, because now they can.

Atlassian also built sensible fences around it: no offline impersonation on permission-requiring scopes like read:me, no impersonating deactivated users or people without access to the app. Least privilege is enforced by design, and honestly, that is the reason this feature can exist at all.

If you approve apps

One habit to pick up: read the manifest. Offline impersonation scopes are declared explicitly, which means the manifest is now the honest record of what an app can do while nobody is watching. An app asking for these scopes is not a red flag, it may finally be doing things correctly. The question worth asking is simply whether each scope maps to a customer-visible behaviour you actually want.

One familiar plot twist

The Forge security documentation still says impersonation cannot be used for customer accounts. The changelog says otherwise, and the changelog is right. That is the third time this year I have caught the docs trailing the product, so let me save you the confusion: when a changelog entry and a docs page disagree, believe the changelog.

While you are in the changelog anyway

Two more entries worth thirty seconds: Forge LLMs are now GA, so apps can build on Atlassian-hosted AI models including the latest Claude models, with a fair warning that model deprecation notice may run shorter than six months, so build AI features that survive a model swap. And Forge Containers closed its EAP ahead of a Developer Preview, so if you missed the program, the changelog is where the next chapter announces itself.

That is the whole story. A small changelog entry, a large fix to a very old lie, and a manifest-reading habit worth forming. If you have carried the service-account workaround in your own portal apps, I would genuinely like to hear what you will replace first.

Sources, all read 3 August 2026: Forge changelog, manifest permissions reference, Forge security overview.