App Building in Studio

[#1]

Hi Atlassian Admins! 👋

We're excited to share a new concept we've been working on - light weight apps built in Atlassian Studio.

Why are we doing this?

We know that teams often have small, individual productivity needs that don't justify a full app installation. These light weight apps bridge that gap - giving users the power to build quick solutions while keeping admins confident that security and governance aren't compromised.

What are these light weight apps?

Light weight apps are user-scoped apps that anyone can create and immediately use in Atlassian Studio. Think small productivity tools like custom dashboards, quick automations, or personal utilities that help you work more efficiently.

Key things to know:

- Built for you, by you - Create small apps that solve your specific workflow needs without waiting for admin consent or IT involvement.

- Private by design - Light weight apps operate entirely within your own user context. They don't appear in any Atlassian app surface visible to other users, so there's no impact on your colleagues' experience.

- Admin oversight without the bottleneck - Because these apps are sandboxed to the individual user, they don't require admin consent. This does not mean that these apps are not governed. Admins will still be able to control who can use this new feature and they can turn it off at any time if required.

Join Our Early Access Program (EAP)

We're looking for admins and their users to participate in our EAP! This is your chance to:

🧪 Test the feature - Try creating and using Lightweight Apps in your environment

🔒 Review admin controls - Admins, check out the visibility and governance tools available to you

💬 Shape the product - Provide direct input into how we develop this feature Whether you're an admin wanting to understand the controls, or a user eager to build your first personal productivity app, we'd love your feedback. How to participate

To join the EAP, please complete the enrollment form (google or JSM) and our team will be in touch with next steps.

Many thanks

Julia

[Rosivatz Kurt]

@Julia Daehne how will Forge developer spaces be handled in the EAP and if this becomes GA - are there already plans how costs / payment of the created apps running Forge bill be done?

[zoltanersek _outpostlabs_dev_]

This is a really interesting direction. As a Forge developer, my biggest question is where the boundary will be between lightweight Studio apps and Marketplace apps.

I like the concept of removing friction for personal productivity tools. One thing I'm curious about is whether these apps will expose the same Forge capabilities (storage, events, external APIs, etc.) or whether they'll intentionally have a more limited execution model.

[Suresh]

@Julia Daehne Instead of a GoogleDoc enrollment form , is it possible to provide Atlassian EAP form on https://earlyaccessprogram.atlassian.net/servicedesk/customer/portals so that request can be submitted easily and trackable?

Some companies (like us) restrict usage of GoogleDoc form due to data privacy.

[Matthew Martin]

Hi @Julia Daehne - this is an interesting direction, and I'd like to understand the governance model in more depth. We're an Atlassian Cloud enterprise (~20K seats) currently assessing Studio app building through our internal AI approval process, and the lightweight class raises questions our security assessment will need answered before we could enrol users.

1. "Private by design" describes visibility, but a user-scoped app presumably executes with the user's own permissions - meaning its data reach is everything that user can access, not just their personal content. Can you confirm whether that reading is correct, and whether any scoping narrower than "full user context" is available or planned?
2. Can a lightweight app declare egress to external systems? If so, what consent step applies, given no admin install occurs? For regulated enterprises, unconsented egress from user context is the difference between "enrol in the EAP" and "hard off".
3. On the admin controls: will the feature arrive disabled by default for existing tenants, and is the "who can use this" control group-based with the same limits as other Studio creation roles?
4. Will lightweight app creation and usage events be written to the organisation audit log? Invisible-to-colleagues shouldn't mean invisible-to-admins.
5. +1 to Kurt's question above on Developer Spaces and billing - for us this is the same question as governance. If Forge consumption for these apps bills to an individual's personal transaction account, that alone makes the class unadoptable at enterprise scale.

Happy to bring these into the EAP as structured feedback - controls of this kind decided before GA are far easier for enterprises to work with than retrofitted afterwards.

[Rune Rasmussen]

Our in-app access settings are quite open by design.
We would like to see this be Opt-In/turned off by default rather than Opt-Out/turned on by default.

[Josh]

Hi @Julia Daehne . Are you open to speaking with enterprise admins about this feature without necessarily participating in the EAP?

Ideally, admins could help guide on acceptable boundaries / guardrails to avoid this becoming a "shadow IT" feature that future Atlassians need to retrofit once it moves beyond an MVP.

- Built for you, by you - Create small apps that solve your specific workflow needs without waiting for admin consent or IT involvement.

Similar to @Matthew Martin - I have questions / feedback from an enterprise perspective.

- Private by design - Light weight apps operate entirely within your own user context. They don't appear in any Atlassian app surface visible to other users, so there's no impact on your colleagues' experience.

If admins aren't able to see what is going on within the broader platform, troubleshooting will become increasingly challenging. "Why did X happen when I was expecting Y?" would be really tough to answer if we don't have audit logs and a way to observe this.

This approach also limits promotion of value to more users. If admins saw that multiple users were building the same apps, we'd likely provide an enterprise-grade solution that could help even more users at a larger scale.

If users are building automations, couldn't that have "impact on your colleagues' experience" if they work in a shared space and the app is working on shared work items / content?

- Admin oversight without the bottleneck - Because these apps are sandboxed to the individual user, they don't require admin consent. This does not mean that these apps are not governed. Admins will still be able to control who can use this new feature and they can turn it off at any time if required.

It seems like you're envisioning the permission control at the user or group level; ideally there would be more granularity about what sorts of apps could be built, what products this feature is available for, and what spaces / instances they can interact with.

[Julia Daehne]

Hi @Josh yes happy to chat. You can ping me on jdaehne [at] atlassian [dot] com 

[Julia Daehne]

@Rosivatz Kurt great question. For EAP you probably want to align with testers on a developer space you create ad hoc. If you don't want to continue using the feature post EAP we can delete the created apps for you. 

In general we still need to finalise our designs on the developer space allocation for apps in Studio. Admin feedback in this chat, during EAP or in a separate meeting would be welcome 

[Julia Daehne]

Hi all, sign up forms are now available as google doc and JSM 

[Julia Daehne]

Hi @Matthew Martin , thanks for the questions. 

1. "its data reach is everything that user can access, not just their personal content" Yes, your understanding is correct 
2. "can a lightweight app declare egress to external systems?" Not for EAP, however we heard from some admin s that they would like to be able to whitelist specific egress domains. It would be interesting to hear your thoughts on this 
3. "will the feature arrive disabled by default". This is currently being discussed. 'Off by default' allows us to capture necessary admin consent (developer terms, possible future egress configuration) but it can also mean the feature is not discovered and remains off. As for user mgt we will not differentiate between standard Forge app users. 
4. "will lightweight app creation and usage events be written to the organisation audit log?" Yes the org audit log will show app logs for all apps incl these light weight apps
5. Developer Space: currently we are evaluating making the default developer space setting an admin feature. Any Studio built app would then be directed to that admin defined space. Keen to hear your thoughts on this as well 

[Julia Daehne]

Hi @zoltanersek _outpostlabs_dev_  , we will keep the feature set for light weight apps limited and therefore clearly distinct from a standard Forge app, ie broadly speaking read only scopes, no in-product experience, no app collaboration or sharing.

We want to make it easy and straight forward for users to create and use Forge apps but keep the feature set intentionally restricted so that admins don't have to worry about security.

[Rune Rasmussen]

@Julia Daehne On the on or off by default? question, if people not discovering the feature I would advise that Atlassian sorts out its frankly embarrassing inconsistency in how changes and new features are communicated instead.

On the one hand the feature is on by default.
Atlassians communication practices are shit and admins are caught unaware/off guard.
Those who have no problem with it just go on with their lives.
Those who do have problems with it now need to shift focus, figure out what the hell this is. It becomes another nail in the coffin. Another stone in the shoe.

On the other hand the feature is off by default.
Atlassians communication practices are still shit, but nothing's enabled so no one is caught unaware/off guard.
Those who want it will find it. They will be happy and go on with their lives.
Those who need control or restrictions will not be disturbed or be frustrated with Atlassian.

On the third hand Atlassian sorts out their communication practices.
Everything is communicated in the same way. Admins are informed about what's changing, when it is expected to hit their site(s), and when it has hit their site(s).
If the change is on by default

• Those who want it don't need to discover it. They already know.
• Those who need control/restrictions won't accidentally discover it. They already know, and can disable it in time.

If the change if off by default

• Those who want it don't need to discover it. They already know, and can turn it on when time comes.
• Those who need control/restrictions won't accidentally discover it. They already know.

And as an added benefit Atlassian now has their communication practices sorted out going forward.