RFCsare a way for Atlassian to share what we’re working on with our valued developer community.
It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.
Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!
Publish : 30 September 2023
Discuss until: 15 October 2023 31 October 2023
Resolve by: 16 October 2023 1 November 2023
Problem
Decentralised identity and fragmented accessmanagement : Today partners face this issue of distributed profiles and segmented access with Atlassian. This disjoint user experience across different interfaces like Developer Console for building and managing Forge apps and Marketplace for listing apps has prompted us to delve into a unified access model. As a first step towards this, we are getting feedback on enhancing the management of roles and permissions in Marketplace partner portal. Today, our partners can oversee their roles and permissions using the “Teams” segment of their Marketplace partner account and there are limitations in the current setup.
Lack of clarity and granular access: The current system presents roles in a way that lacks precision. Today, the process of adding a team member involves selecting permissions and associating them with roles that function more like labels (for example, “Migration,” “Sales and Approval”) rather than effectively assigning distinct roles with designated permissions. Additionally, partners can’t provide team members granular access for example at an app level etc. This limitation obstructs their ability to ensure that team members only have access to the resources necessary for their tasks.
Mandatory role assignment: The current system enforces the compulsory assignment of a role when partners add team members, which the Atlassian team uses for specific communication purposes. This can be problematic for partners who may prefer team members to be in the system without being contacted by Atlassian for particular functions or processes. Consequently, partners are experiencing challenges maintaining accurate and relevant contact database in our systems.
Administrative challenges: In the current system, we have the limitation to assign permissions and roles to only one user at a time. Also, managing permissions for each team member individually can be a time-consuming process which could lead to inefficiencies when assigning or changing access levels for a large number of users.
Proposed Solution
Unified Experience: We are looking at unifying the Partner’s / Partner Org’s Identity across the Marketplace partner portal and Dev Console, which you need access to streamline your build-to-list journey. As a first step towards creating this partner identity model and to overcome the limitations discussed above, we are introducing a Role-based access control (RBAC) in Marketplace. With this change, managing access for your team becomes more streamlined, less frustrating and easily scalable while adhering to the industry’s compliance standards and best practices. Key enhancements are listed below.
Role clarity with granular permissions: We’re introducing a curated set of predefined roles for admins to assign team members roles with granular access levels easily. These Atlassian pre-defined roles will be organised around specific functions, offering a more precise delineation of associated responsibilities and better comprehension of the permissions associated with each role. Additionally, roles can now be specified at a granular level for apps. For example, each role and its associated permissions can be individually linked to specific apps from your list, providing increased security and granular access management.
Here is the list of the new roles that we are proposing:
Streamlined role assignment: With the enhanced system, you can simultaneously assign roles to multiple individuals. Furthermore, you’ll have the flexibility to select multiple roles that best suit each team member.
Nominating partner contacts: We will introduce a new approach for adding contacts as partner POCs for communication with Atlassian, enabling Atlassians to connect with right partner contacts efficiently. While the exact process is still in the planning stages, we will aim to resolve the current challenge of including team members as mandatory partner POCs under various labels like ‘Migrations’, ‘Support and approval’ etc.
These enhancements aim to provide a more robust and flexible system, ultimately optimizing your experience with roles and permissions management.
Migration Plan:
After we have feedback and we have timed this at our side, to ensure a smooth transition for your organisation, we will aim to migrate your current team members from the roles and permissions section of the Marketplace portal to our new system. This way, you can seamlessly adapt to the new experience with minimal effort, without disruptions in workflow during the process.
Team members with multiple permissions assigned in the current experience will be assigned multiple roles. For example, if an existing team member has permissions to manage pricing and view sales reports, they will be provided two roles - “Pricing Specialist” and “Data Analyst”.
Asks:
We welcome any feedback you have regarding this RFC, but we’re particularly keen on gaining insights into the following:
Your feedback on the proposed problem statement and the solution approach
Your feedback on the mapping of roles and permissions
Your feedback on the names assigned to the roles
Is any role not included in our suggested list that would benefit your team? If so, what particular functions would these roles perform, and what set of permissions would be necessary?
Please separate Promotions from Pricing. They’re 2 different roles for us. Our Customer Experience and or Marketing will handle promotion management. However pricing is handled separately and under much more planned efforts (ie it’s done much more deliberatle and controlled). Combining these 2 roles is quite worrisome for us.
While this is being done - it would be awesome for the Sales reports and usage reports to be broken down much much further. If the downloading of data could be restricted - it would be awesome (with an audit trail). If also, the amount of data available to a normal user (think GDPR - most folks don’t need to see people’s emails etc) could be reduced - it would be awesome!
Your feedback on the proposed problem statement and the solution approach
I was only facing the “Mandatory role assignment” issue, so the general proposed problem wasn’t something we needed resolved at Requirement Yogi.
Your feedback on the mapping of roles and permissions
Neither good nor bad.
However, the presence of “predefined roles” is a difficulty, because companies all have a different process. Another possibility is to have a list of permissions, and marketplace vendors will just tick whatever is necessary for each member. Most vendors only have a dozen people in contact with the Marketplace, so it’s a good way of granting permissions.
If you really want to accompany vendors, then you can let vendors define roles which best suit their company.
Concerning contact points for each topic, it is better if it is a separate option, titled “Contact point for … : [ multiselect dropdown for users, if unselected, then the global-admin applies ]”. So administrators clearly understand who will be contacted, rather than navigating to everyone’s profile.
Your feedback on the names assigned to the roles
We’ll get used to anything, don’t worry. I can’t wait to assigning various titles of “specialists” to junior developers - anyway, discussing on names is bikeshedding.
Is any role not included in our suggested list that would benefit your team? If so, what particular functions would these roles perform, and what set of permissions would be necessary?
YES, TWO:
A simple developer should be able to do a release, and nothing else! It is especially important because everyone has, or should have, a CI tool which builds reproducibly, and this tool should be the user doing the release. The Manage App Details is an extremely wide responsibility, and not only that, but there is no traceability on it, therefore I can’t even control whether a developer modified the app listing! As opposed to it, adding versions has an history (literally), eventually immutable, which is a good path to SOC2 and to ensuring that in the most cataclysmic event where a team member performs a malevolent release, they can be sued (of course only if the intent was malevolent). Therefore, I would like to see a “Publish versions” permission (and all the rest of the permissions regarding app listing management up to sales figures will be given to my marketing team).
Since you can only request Parter Portal access after adding the person on the Marketplace, then I can suggest having an “Access to Partner Portal” checkbox. Also, obviously we lecture our employees a lot about it, but employees are not sufficiently informed that this PP falls within the scope of the NDA, so the process to access this little PP is probably missing [exagerated version] a large Apple-style dialog with a 72-page contract to sign when accessing this PP for the first time, or at least a warning that access is granted under the scope of your employer’s NDA. I diverge, but it’s always considerations that fall under the scope of none of the normal processes, that become weaknesses.
I agree with Daniel on both of his points. Promotions and Pricing are two completely different areas. Promotions are a lot lower level risk than pricing changes.
I’d also like some of my staff to have access to reports like churn but not transactions.
I agree with Daniel and Paul, promo codes and pricing should not work together.
I have an additional feedback:
We have a generic account for our Analytics automation, so far this account only had the “View sales reports” and “View sales reports” permissions.
We had to grant the ‘Manage promotions’ permission to this account in order to create a “Promo code” analytics dashboard (to track pomo codes usage).
This is annoying because we don’t want to generate promo codes with this account; we need read-only access.
Could you split this permission into two: ‘Promotions read-only’ and ‘Promotions read-create,’
OR give the ability to read promo codes to the ‘Data analyst’ role?
I have comments but I want to make sure my interpretation of the new roles is verified before I say more. Are you saying that permissions will become part of the role? Today, an admin is given permissions by default, but I can give someone an Engineering role and give them permission to create/manage promotions. In the future, assigning someone as the Pricing Specialist will be the only way to assign permissions for promotions (as an example), is that what you are proposing?
Moving to RBAC could be a positive outcome, if the existing Role based communication system is managed and improved at the same time.
What’s the Role based communication system? That’s the SHADOW communication system that enables teams across Atlassian to reach out and contact the correct person within each Marketplace Partner when communication is critical. Please consider the importance of this system, regardless of whether it exists by design or by accident.
In other words, Roles and Permissions are used for several purposes today. And these purposes are very different. They need to be separated and perhaps several solutions are required to fulfill them.
Roles are used to identify key contacts within the Partner for communication.
Permissions are used to determine who has access to do what in the marketplace account.
How Roles are used today (from my experience)
Roles
Roles are assigned to a user
There is no connection between a Role and a Permission (today)
Roles are used (Shadow communication system) to indicate who Atlassian is to contact within the Marketplace Partner for critical communication
Example: a user assigned the Engineering role is automatically flagged as someone to contact when there is an engineering issue
Example: a user assigned the Security role is automatically flagged as someone to contact when there is a security issue
Example: a user assigned the Migrations role is automatically flagged as someone to contact when there is a migrations issue
Example: as user the Primary role is the top of the food chain if all other communication attempts fail, or if the communication is outside of existing defined Roles
Etc.
Teams throughout Atlassian use Roles to great effect and it is a real system (intentional or not).
There are unintended consequences of Roles in the Shadow communication system
Specifically, every user is required to be assigned a role and this causes problems in the Shadow communication system because Atlassian contacts everyone who has the role, not just those who need the communication
Example: assume many engineers are provisioned into the marketplace account because there are many apps and each app has a unique engineer responsible for its deployment. If there is critical engineering information to be shared from Atlassian to Partner, that information should go only to those specified to receive the communication, not to every user provisioned as Engineering; in the current system it goes to everyone with the Role.
A hack is required in order to manage this communication. The hack is to assign only the key engineering contacts to the Engineering Role; all the remaining engineers are assigned to the Marketing role. Why the Marketing role? We deem it the least important, thus use it as the “generic user” (sorry marketing).
How broadly do we use this hack? We find it necessary for every Role and all users
Users from every internal organization are assigned the Marketing Role: Customer Support, IT Admins, Automation Systems, Sales, Engineering, Marketing, Product, and more.
This hack enables us to clearly specify who is responsible and thus who should be contacted by Atlassian, as opposed to who is provisioned into the account to get a specific job done but isn’t necessarily the owner.
If the existing Role system were to change, Atlassian would need to consider how to replace the existing Shadow communication system; this system delivers the following communications (and more)
ECOHELP tickets
Security tickets
Cloud Fortified notifications
And more
How are Permissions used today (from my experience)
A thought exercise is how we think about the marketplace account. The Atlassian Marketplace is the shopping mall. Each Partner has a store inside the shopping mall. The store is the Marketplace Account, it is our storefront. Next, each storefront is of different size (depending on the size of the Partner and the number of apps). At scale, some organizations require many people to work in the storefront, but not all those people are managers or executives. Therefore, there needs to be policies in place to ensure that the storefront is secure and meets all the local and international operating standards. This is where Permissions are needed.
Permissions
Permissions enable users to perform certain tasks (or groups of tasks) in their organizations marketplace account
Example: Manage app pricing enables a user to edit the pricing of apps
Example: Manage promotions enables a user to create/manage promotion codes
There are no Shadow processes connected to Permissions that I am aware
There are many permissions that could be improved through the creation of more granular permissions, breaking the permissions down to base elements
Examples
Admin - Does admin need to be all access? What about separation of duties? Does all access work against SOC2 or ISO27001? Also a lot depends on the definition of Admin. Is it the traditional Jira definition, someone who does basically everything in managing the account, or is it an IT Admin, someone who provision users in and out of the marketplace account but doesn’t manage it? Those are two very different admins and both use cases are required today.
Listing Specialist - Does the Listing Specialist need access to every app? What if there are many apps (100’s) and the specialist is only responsible for three? How does this support separation of duties and is there any impact to SOC2 or ISO27001?
Engineering - It could be useful to assign engineers to specific apps. (This could help with Shadow communication.)
There is potential for improvement with every permission. Granularity is important, please consider separation of duties and compliance standards (i.e. auditing).
This is a lot. My intent is to share the challenges we face daily when it involves Roles and Permissions. Please feel free to reach out to me and the others here who took the time to reply. We want to help you improve the marketplace accounts.
One thing we really need is separation between sales reports and license reports. Why?
Because I want to give our support team access to license information so that they can provide better support, but I do not want them to have access to transactions and sales reports.
Pricing data is highly sensitive, so why not keep it separate from the rest? A pricing specialist won’t always be the same person as the sales representative."
Is it possible to include a permission only for uploading new app versions?
Looking at all the replies here, I think it is safe to say that the best way forward with permissions & access management of Marketplace vendor pages is to allow vendors to create their own roles and assign permissions to match their own process.
I doubt that it will be possible to create fixed roles that will satisfy all the different needs from vendors.
More detailed feedback from Adaptavist will likely follow, but +1 from me for custom roles.
“Release manager” seems a notable role omission here, which should be app scoped and only allow publishing new app versions/release notes. Ideally the ability to make an app version private/public too.
Some teams have the full process automated so a bot user would handle things, others manually release via the UI.
We have dozens of engineers that are empowered to self-serve their product releases, right now this has to be managed either by granting each engineer broad marketplace access, or by using shared credentials in a password manager.
Our current challenge revolves around the need for a role that grants access solely to license details, such as customer names, license IDs, entitlement numbers, and other pertinent information found within the license section or even the feedback section. However, this role should not extend to viewing transaction and sales data. The matter is that our support team often requires access to license details and customer history when handling raised tickets. We know that we can automate data export to another using an API but still, we would like to have these details in just one place.
Thank you for sharing your feedback with us. We’ve taken your suggestions into consideration, and here’s our plan of action:
Pricing and Promotions Role:
Point noted. We’re proceeding with the separation to ensure clear and distinct functionalities.
Granularity on Sales data and Usage data roles:
We recognise the need for this ask. However, this will require some internal exploration to identify the feasibility given the increased complexity with the new granular App data control. We will get back with more information on this.
Regarding the query about data accessibility for a “normal user,” could you kindly provide further information? Specifically, we’d like to understand which data is being referred to and what criteria define a “normal user.” Is this related to the ability for a team member within your org. to see other team members and their information on the system?
@Yamuna For us the need to view pii is limited to our support team for when they’re verifying a license or if they need to reach out to the customer. For our marketing team - they’re interested in all of the other information, but can’t really make use of the pii (they’re not allowed to use the email for marketing emails). So in order to to minimize data leakage etc - it would be awesome to contrain the data shapes that are available to folks.
Thank you so much for taking the time to provide us with your valuable feedback.
We understand your suggestions on introducing custom roles. I would like to highlight that we have granulated the permissions to role mapping in such a way that - largely each role is mapped to a single permission. This provides you the flexibility to allocate the necessary roles to any team member, enabling you to define their functional capabilities. This approach promotes uniformity across the marketplace and helps with easier migrations now as well as in future. While we don’t have custom roles in place today, we’ll certainly explore this possibility in upcoming iterations.
Thank you for offering this valuable feedback on Atlassian contacts process. We’re actively working on refining this process, and we will pass this suggestion on to our Designers.
Regarding Role titles - while the names haven’t been finalised yet, we’ve duly noted your input.
We will further explore your feedback and get back on the additional role for ’ Publishing Versions ’ and capability for ’ Access to Partner Portal checkbox’
I’m sorry, but what does this even mean??
Sometimes I feel like Atlassian is just making up reasons to justify continuing on the already chosen path instead of actually changing course.
I have yet to discover a single RFC from the Atlassian Marketplace team in which you actually made a different decision based on RFC feedback.
@PremankuChakraborty will you be sharing your next steps based on the feedback provided? As you can see, there is interest from the community to provide examples of how Roles/Permissions are used across a wide array of Marketplace Partners of vary degrees of size and scale. I’d be happy to discuss if you want to learn more about Tempo’s challenges in this area (which are represented through all the comments).
Thank you for the valuable feedback. We will indeed be separating the 2 roles - pricing and promotions.
For the second ask, this is slightly tricky. Given that we have introduced granularity with App level data, breaking down data roles further would bring in complexities. We will look into the feasibility of this suggestion and get back.
)