Admin role management: All members are space admins with full permissions to manage apps and team membership.
Developer Console integration: Manage spaces, apps, and team members, and use the space switcher to navigate between spaces.
App assignment and management: Assign existing non-marketplace apps to the appropriate developer space in the console. Marketplace apps are already linked to the developer space matching the marketplace partner account name.
CLI support: Updating the CLI to version 12.5.0, you can create Developer Spaces and assign apps via the Forge CLI during forge create or forge register workflows. Run npm install -g @forge/cli@latest on the command line to install the latest version of @forge/cli.
App transfer (manual process): Transferring apps between spaces requires a support ticket for non-marketplace apps or following the Marketplace transfer process for Marketplace apps.
Important changes to Marketplace publishing
Publishing apps to the Marketplace will now work differently, and it’s important to review these updates:
The list of publishable Forge apps is now based on Developer Space membership.
All Forge apps must be linked to a Developer Space before they can be published to the Marketplace.
Only Developer Space members with the appropriate permissions can publish apps.
These changes align publishing and billing responsibilities with Developer Space governance and prepare for the upcoming usage-based pricing model.
If you publish apps to the Marketplace, review your current apps and confirm they are linked to the correct Developer Space.
Known limitations:
Only the Admin role is available for this release. Additional roles and permissions will be introduced in the future. For anyone interested in more roles, please see the Jira ticket for feedback : FRGE-1893: Developer Space Roles feedback
App transfer between Developer Spaces requires manual intervention.
Some advanced governance and reporting features are not yet available.
For more information, please refer the Developer Space documentation. We’re always looking to improve, please free to share any feedback you may have with us.
Beware that any admin added to the auto-created space for Marketplace Partners automatically gets admin permissions on the Marketplace account as well.
Hi @BenRomberg , yes, that’s part of the vision to unite both console and marketplace partner account in terms of roles and in the future w.r.t UX as well. An admin in developer space would be an admin in partner account and vice versa.
Partner accounts are essentially developer spaces. Hence we translated all partner accounts to developer spaces automatically and made the already existing admins in partner accounts, the developer space admins.
We will be making the docs and the experience clearer to reflect the same.
Partner accounts are essentially developer spaces. Hence we translated all partner accounts to developer spaces automatically and made the already existing admins in partner accounts, the developer space admins.
This assumption does not hold in ours or in many other partner’s cases. Let me explain why:
MPAC admins have permissions to edit payment/banking details which manages the outcome of fairly large $ amounts. Because of internal policy (this will also apply to any serious company that is ISO/SOC certified), only certain administrative individuals have full admin access which includes the ability to edit these sensitive details. Similarly, we no not want more than a few individuals to be able to edit pricing.
In my team, NONE of the people who have full admin in MPAC should also have admin in Developer Spaces and vice versa. Administrating developer spaces is something we envision developers should administrate, as they develop, monitor and release apps. It would also in some cases make sense for the developers to manage billing for the apps that they develop. This does not mean that the same individuals should manage payment info for payouts for app revenue.
In short, the way the current access management works in MPAC, there is in my organization zero overlap between the people who need admin in MPAC, and the people who we envision need admin in Developer spaces. We don’t need business people to control operative details about app development, and we certainly don’t need devs to manage financial details.
I’ll just give you my example. I’m the Product Marketer in my team. We have about a dozen of small apps and I have admin rights to the Marketplace, where I frequently make edits and changes to the details of the apps.
But I’ve never touched a line of code in my professional life and it would be extremely confusing to me to have access to a developer space where my contribution is absolutely 0.
Much more than that: giving me access to a Forge Developer Space breaks the principle of least privilege and would constitute a constant risk.
I really don’t understand this proposal. My perception right now is that this has come through so far without understanding that the orgs making apps have a clear separation of roles between those who manage the business and those who make the tech. Only founders and such may have access to both streams.
Here’s a little follow-up. One of the MPAC admin who got removed from developer spaces got completely removed also from the MPAC team. Then people who got added as admins in developer spaces got auto-added as admins in MPAC. Furthermore, it is very worrying that all the people who now got their privileges escalated cannot be de-escalated again… when added as admin in developer space, someone is automatically escalated as admin. Now when removing admin, they are not removed as admin from MPAC anymore, and we cannot edit their privileges from MPAC anymore. Looks like we’re stuck and have no way to restore the old state of privileges.
I want to clarify the functionality of developer space. All Marketplace partner accounts are developer spaces. This is the intended behavior and here’s how it works:
When a member is added or removed as an admin in one portal, it will reflect in the other.
Creating a developer space in console automatically creates a partner account in the marketplace, and vice versa.
A developer space admin gains admin access to the corresponding Marketplace partner account.
A developer space admin has viewer access to all Forge apps associated with that developer space in the console.
If developers prefer a different setup, we recommend not adding developer space admins and instead assign the roles individually at the Forge app level.
Developers should evaluate the marketplace team profile composition based on the changes applied and assign the right permissions to right team members.
We plan to introduce more roles in the developer space soon (e.g., viewer and developer) – FRGE-1893.
This behaviour will be clearly documented and highlighted in the user experience when adding developer space admins.
I understand that changes to access controls can have important implications. I shared an RFC where roles and permissions were communicated in advance.
We are working on communicating the implications across all touchpoints so that developers are fully aware before addition or removal of a team member in the developer space and partner account portals.
Please disconnect the Marketplace and Forge Developer space. Or introduce seperate administrators for Marketplace. Otherwise we’re really going to have to limit access to the Forge Developer space.
This is a huge problem for SOC-2 and ISO certifications.
We are not the same as an internal developer at a company and we have different needs.
Developer space and Marketplace management sound like two very different things, so having them coupled like this is quite unintuitive. I believe we should all aim to build things that don’t require users to read thorough documentation.
In our case, 2/3 of our Marketplace admins have nothing to do with our Forge app development. Having them as Developer space admins provides very little value, a Billing role would be more appropriate.
I fully respect the intention to unify account management, but it’s difficult to see how this is an improvement or a significant step towards a solution.
It would be valuable if the RFC served as the central place for collecting all feedback, including comments on granular roles. Right now, that input is being tracked in a Jira ticket instead.
I will discuss internally around the feasibility and timeline around creating two new roles: one dedicated solely only to Marketplace administration and another dedicated solely only to Console administration.
The Marketplace and Console cannot be disconnected, and the Developer Space Admin role can’t be changed.
In the meantime, I would appreciate the community’s feedback on whether these two new roles would serve as a suitable solution.
I previously ran an RFC, but this particular point did not come up at the time. I closed that RFC with a Jira ticket to ensure the discussion on roles remains open.
We are actively listening to feedback and will continue working on this. This thread will also remain open until we reach a fair and agreed-upon path forward.
This implementation violates the principle of least privilege and goes against Atlassian’s requirements that Platinum Marketplace partners be accredited for SOC-2 or ISO 27001. In our organization Dev Space admins are not Marketplace Account admins. These functions are separate, no overlap. You have created an insider threat attack vector that did not previously exist and for which there is no currently no defense. I strongly urge you to delay the launch of developer spaces until you close this attack vector. Security is job number one! Thank you.
Thank you for your feedback. We acknowledge the situation and have taken immediate action by rolling back all Developer Space–related changes in the console, CLI, and Marketplace partner account. While we conducted interviews and shared an RFC, we recognize that there are areas where we need to improve. We are committed to running a retrospective, strengthening collaboration with the community, and refining our approach. Once the necessary improvements are made, we will validate the concepts with developers and reintroduce the feature through a progressive rollout.
It is important to note that Developer Space remains a key construct, as it is the entity that will ultimately receive the monthly invoice for all Forge apps in the space that exceed the free usage allowance. Our priority is to ensure this concept is delivered in a way that is both clear and aligned with the needs of our developer community.
We will also be reaching out directly to impacted developers to provide support and guidance. In the meantime, for developers who have made changes to team structures or roles during this period, we kindly request that you review your team setup in the Marketplace portal and adjust it as needed to align with the previous configuration.
Thank you for your partnership and understanding as we work to improve this experience.
As someone who reviewed and participated in the associated RFC, somehow this design concept was completely lost on me. Obviously, the most critical problems with this design have already been thoroughly discussed in this thread. So, I won’t belabor them any further.
But I do have another question: Does this design infer a one-to-one relationship between developer spaces and Marketplace vendor accounts?
When I was commenting on the RFC, I had the idea in my mind that multiple developer spaces could be associated with a single vendor account. Was that not the intention? Is the only use case for creating multiple developer spaces to segregate public vs. private apps?
Hi @BryanGuffey_MHQ , based on the feedback, I adjusted the roles of Developer Space Viewer and Developer. For the Admin role, we didn’t receive explicit input through the Loom recording or the post, so we proceeded as planned.
We got the direction for the admin role now, we will work and get back.
Billing role is a different role to marketplace or console and will only focus on billing account that we will be providing for forge apps billing. Since this concept has multiple layers, I will plan to host a webinar on this topic.
Obviously, the most critical problems with this design have already been thoroughly discussed in this thread. So, I won’t belabor them any further.