I am exploring the ability to share access to views in Align with stakeholders that are not regular users of Align, but would benefit from the ability to see certain areas.
These individuals would not benefit from taking up a licensed spot, but we would like to share visibility on the regular.
I tried this by creating the External User role with what I understood as Read-Only access. However, when tested, an individual with this level of access was still able to manipulate the data (change ranking, add data, change fields, etc.)
I am looking for some help to solve the following issues:
@Jayme Burkhalter It is possible to create/modify a System Role and set permissions accordingly so it is only able to view information. For pages that have the ability to edit info, there will be additional toggles that can be disabled to prohibit these abilities. In addition, it is important to not add them as a member to a Program. Doing so, inherently gives them the ability to change the prioritization of the Backlog and make changes to the Program Board. Instead, you would want to only add them as a member to the Portfolio.
Something to clarify, though, is that this will still utilize a license. Some users have more responsibility with entering info in the tool where others are more the receiver of the information being entered. You're still providing them access to Jira Align to view information and get value out of the data that is being entered in the tool. The only user type that does not count as a license is the integrated user. This is defined as an agile team member that is not a team lead (Product Owner or Scrum Master) and uses the integrated team tool as their primary tool. These users are typically created in Jira Align automatically via the integration with a system role that is set in the connector settings. They will rarely log into Jira Align, if at all. They have extremely limited access with what they can see in Jira Align if they do happen to log in.
Thank you so much @Rae Gibbs !!
Follow up question: will adding them as a member to the Portfolio enable capabilities at the Portfolio level? Again, looking for strictly read-only. Most of these individuals will not be trained on Align as users in any capacity.
Can you please explain more about the Integrated User and point me in a direction to find out more about setting this up? This sounds a lot like what I might be looking for!
As a follow-up to Jayme's question above, regarding the integrated user privileges, a customer this morning asked whether amending their 'team member' user role to allow for more read only access would alter the status or convert it to a licensed user role? In the customer's Jira Setting-Jira Setup, the default user role=team member and the default team role=developer.
They are having similar needs for individual team members, that work primarily in Jira, to be able to see certain information that does not integrate with features or is stored in their capabilities presently.
I'd really like to gain some more insight for how to better accommodate this type of scenario.
This is exactly what I am trying to solve for.
My Jira teams still need to see contextual information above a feature which is sync'd in Jira as an epic. I want them to be able to see the capability and epic above the feature so they can see broader context but they DON'T need to be able add or change information, just see it.
I was thinking about turning on some of the capabilities in the Team Member role type to enable this. Hoping this is the easy solve for the problem as I don't want to have to buy a JA license for all my developers.
@Jayme Burkhalter @Chris Gargiulo @Susan Scott Let me see if I can address all of your replies in a single response. It might be best if I first better explain the concept of integrated user. Normally the integrated user system role is a role that is specific to only this type of user. The actual name of the System Role in Jira Align may vary. I've seen variances in customers' instances like "Default", "Integrated User" and "Team Member". This role is set in the Jira Connector as the System Role to assign to users that get added to Jira Align via the integration.
Users will automatically get provisioned in Jira Align via this method if they are assigned to an issue in a Jira project that is integrated via the Jira Connector.
Most of the time, these are going to be people that are on agile teams like testers, developers, etc. The permissions that are set for the role being used for the integrated user is VERY limited. This is NOT based on read only versus edit permissions. It means they have limited access to only what they may need as a team member. There are some primary features that a team member would need that is not available in Jira. This access does NOT go beyond the Program level and is very limited at the Program level. This includes the Program Board and Features. At the team level, access is also granted to the Team Room, Team Meetings, Backlog, team level work items (objectives, stories, defects and tasks) and some Team Reports.
If the integrated user system role has permissions that grant access beyond the aforementioned access, those users would no longer be considered integrated users and would be deemed as licensed users. We understand that there are some features in Jira Align that team members would use on a regular basis that are not available in Jira, hence why some exceptions have been made mostly at the team level with the exception of the Program Board and Features at the Program level. However, anything beyond that is going deeper into the tool and offering even more value that Jira Align offers. For that reason, usage is charged for licenses. So just to be clear, even if you are providing view only access to other options in the tool, this is still beyond the scope of an integrated user and that would result in those users being considered licensed users as opposed to integrated users. Integrated user does not mean read-only access.
For those team members that are interested in understanding the work they are contributing to, a custom field can be created in Jira to pass over higher level information in a text format. We have a "Why" button in Jira Align that can be mapped over with those details to Jira. Here is an article with some more information around this.
Regarding adding users to portfolio versus program...there is another article to reference that explains this a little more. To answer your question, adding them to the portfolio as opposed to the program actually restricts abilities. Adding them to the portfolio will NOT provide them with any additional capabilities outside of the permissions that are set with their System Role.
I'd also like to add that Jira Align is not the most intuitive tool and requires some level of enablement. Supplying a user with a login without training is going to generate a ton of questions as they will not understand basic navigation, what's available or the value that is to be gained by most of the views. I bring this up as a caution to help prevent overhead that may generate for those that are providing the internal support for your organization.
Thanks @Rae Gibbs I appreciate the quick response to this question group and the thoroughness you provided. It makes sense and also gives me a clear understanding of what defines a licensed user vs. a true integrated user and the reasoning behind allowing the specific views/access by the integrated user too. Thanks again.
@Rae Gibbs - as a follow-up to your extremely helpful overview of integrated users, what about team-level users that want to ONLY use Jira Align for their team-level work? Meaning, they don't have an equivalent Jira project they are sourced from. Instead, they are added to Jira Align directly with the same role as the integrated users would have (i.e. access to managed team-level items). As I understand it, the integrated user role is not a read only role but rather a team-level access role which would allow users to create stories, work in sprints, etc. Would these users then be considered fully licensed users because they don't work in an integrated tool? Or would they be considered an integrated users because they have the same role as integrated users?
Thanks @Rae Gibbs - I would like to point out however that putting developers and testers in a little box reduces their ability to contribute to how something is built as it as prevents them from seeing in the next quarter+ what might be useful context of how they design and build something. In my experience developers and testers are just as creative as product managers and product owners if they are allowed to peer above the top of their stories. Feature level really helps, but in large scale organisations, they need to see context the next level up, for us that is at the portfolio epic or capability level - we have capabilities turned on at the solution level and it is critical that all dev teams can 'see' the content as well as click through to user flow designs, solution designs etc. Without them being able to see this content I have to replicate it at a feature level.
In principle the answer would be you could sync with Jira one level above the feature/epic - I want capabilities and features created in JA, but my teams need access to context and links.
We agree that team members understanding the value they are contributing to is important. I would highly suggest exploring the Why Details to see if this meets your needs. This can be viewed in both Jira Align at the Story and Feature level as well as synced over to Jira. This provides details of the parenting of information several levels above the feature level in a text format in Jira. The Why button in Jira Align presents a prettier interface with the cascading information.
The article I previously shared has more details and also links to one of our knowledge base articles with even more info. If you explore this and feel your team members still need more, then that would result in purchasing licenses for them.
The why is great for context but it doesnt solve the issue i have when we have documents, designs, etc 'attachments', use cases, etc that are held at the level above - if I then have 5 features that break that down from the capability above - i have to replicate everything - right now we are going to try a 'hack' which is creating a common feature to hold this stuff that everyone can see
@Susan Scott Integrated Users CAN log into Jira Align - to view/edit TEAM level ONLY.
I.e. User need to edit/delete update a story attachment that is held only in Jira Align (since attachments do not pass in the integration) The user can log into Jira Align (single click from the Jira Align link on the issue in Jira- when using SSO) and edit the story, attachment, sprint etc. based on the user permissions set for the default integration role in the Jira Integrations (admin) screen in Jira Align.
If you are using the OOTB "Default" role - that role has permission to only view updates (aka Feeds) on work itesm at the team level. If you are using the OOTB "Team Member" role - these users can update sprint status, stories, defects, impediments, dependencies, assign and create tasks and create impediments as well as see the Team room - to name a few permissions.
If you are using the OOTB "Default" role - Team Lead, Scrum Master, or Product owner - due to their ability to edit more items at the Program level (and above) that role would consume/require a license.
Hope that helps. As @Rae Gibbs mentions the roles in Jira Align, especially the OOTB roles can be very confusing, often times considered hard to use/understand. It does take an experienced consultant/Solution Architect to successfully marry your needs, processes to the appropriate role/licensing needs.
Feel free to reach out. I'd be happy to assist 1:1
I get it but I think Atlassian are missing the point - team members don't need editing rights but they do need context/read rights - I think the integrated Jira role should be able to at least access information in the next level up, for me that is the capability otherwise I think you are 'dumbing down' the teams.
This is the fundamental issue with Jira that I thought Jira Align would solve. Obviously I can solve it with more licenses, but that seems OTT.
Hi Everyone, I appreciate the dialog!! Unfortunately I am no closer to an answer than when I began. Though I would eventually benefit from conversations around Team level access, I am more concerned with read-only visibility for individuals like Sponsors, Planners, Directors, etc. These people are key to the overall process, especially as it relates to intake of new proposals, prioritization and approval of new work within the existing approved portfolio, but they absolutely do not require a full blown license for Align. Many of these individuals do not even regularly utilize JIRA let alone Align. I can see expanding licensing in the future when Align becomes a more widely used tool as we scale, but this is simply not the case in the MVP stage of our implementation. That however, does not remove the need for stakeholders to be able to access the data within Align and see it while someone such as myself drives a prioritization and approval ceremony.
Before Align, we would share dashboards and roadmaps in Jira which could be accessed for read-only purposes by non-users of JIRA. How can we achieve the same level of sharing using a bigger, better tool? This looks to be a major gap!
Unfortunately, the short answer is those folks would need a license. The omission of having a license is not based on view only. One of the default System Roles we create a lot of times with customers is a View Only role to give access to the exact functional roles that you mention. You can provide them view only access by setting the permissions accordingly for their System Role and adding them only as a member to the Portfolio. Anyone who utilizes this role will be considered a licensed user.
There are 2 requirements here:
1. As @Jayme Burkhalter says - non-regular users who need to see information - typically management or stakeholder types - using a license for these types of users is expensive - not being able to give them read only access creates overhead because you then have to figure out how to do reporting outside of the tool
2. Team level Jira users who use Jira day to day but need to see information or click on links in JA about what they are building - and the Why button is NOT the answer - using a license for these types of users is very expensive and then I'm wondering what is the point of Jira except as a bridge to downstream dev tooling - not being able to give them a bit more access creates overheads e.g. I have to have a separate place to put the context, the document links, etc, my JA users become the bottleneck for contextual information held in the level above which describes the outcome creating overhead on them to provide the visibility which ends up in emails mostly and then you are having conversations outside of the application
If the objective is to force us to buy more licenses you are on the right track
If the objective is to enable the connection from strategy to execution and an ecosystem to build the right thing and build the thing right then you are creating a wall which is breaking the ecosystem
(Or, What to expect when you’re expanding.) Once you've completed your Jumpstart, or your initial assessment of Jira Align, you'll start to think about how you can roll it out to the rest of your e...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events