Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Is there any way to set up a strictly read-only access in Align?

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:

  • create a strictly read-only role for non-licensed users to see data occasionally
  • better understanding of the toggles in the Role area.
    • setting a role to have visible access, but lack the ability to manipulate the data
    • this is unclear- toggle to turn on visibility should not mean access to change the data

3 answers

2 accepted

1 vote
Answer accepted
Rae Gibbs Atlassian Team Jun 29, 2021

@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!

Thanks again!

@Rae Gibbs 

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.

Like # people like this
Rae Gibbs Atlassian Team Jun 30, 2021

@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.

Like # people like this

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 Atlassian Team Jul 01, 2021

Happy to help!

@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?

Rae Gibbs Atlassian Team Aug 16, 2021

@Michael Stewart Sorry for the delay in response. The System Role for integrated users is only for those that are coming over via the connector as a user from another team tool such as Jira or ADO. They do not require the purchase of a license for team-level access in Jira Align because they are already charged a license for equivalent access in their team tool. For people interested in using Jira Align at the team level that do not live in another tool, those users would be considered licensed users and would be assigned a corresponding System Role with appropriate permissions. If they desired to view information beyond the team level, this would not be restricted because they are already paying for a license. It would just be at the discretion on the customer's side as to how much access they would want to give these users in the tool.

0 votes
Answer accepted

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

Rae Gibbs Atlassian Team Jul 02, 2021

Understood.  For that level of access, you would be looking at having to purchase licenses for them.

Tina Behers Community Leader Jul 02, 2021

@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

Hi - everything well understood at feature and story level, its the levels above that.  Thanks for input.

Like Tina Behers likes this
Tina Behers Community Leader Jul 05, 2021

Any access above that does require a Jira Align license.  

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.

Like # people like this
Tina Behers Community Leader Jul 05, 2021

If you only need them to be able to view the capability detail info, that can be easily solved with the “why” integration mentioned above. Additional fields from the capability can be integrated with a custom integration (using the API) as well. 

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!

Rae Gibbs Atlassian Team Jul 06, 2021

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

Like # people like this

Thank you @Susan Scott 

This is an issue, Atlassian.  I dont plan to train my whole enterprise on the ins and outs of USING Align, but there are very real use cases where I need to be able to show them what's happening.  They need to at least be able to look in the window, if they are not allowed into the room.  

Planners: should be able to see the Enterprise Room when they are trying to plan their proposals according to strategy.  if they cannot see what this beautiful tool has to offer, we have to recreate it in a second system.  As you can imagine, this is not ideal.

Executives/Directors: we are desperately trying to give them the tools to prioritize according to value and strategy.  They dont need the ability to do all the things like voting and scoring and ranking yet, we have a ways to go before they are ready for that.  But we would like them to be able to look at how proposals stack up against their strategy on their own.  They wont use the tool 99% of the time, this does not justify a whole license!

Stakeholders: Need to see the workload.  We have people positioned to manage the workload, but these people should be able to see what is there.  If we are shouting about transparency in agile delivery, we need to open the view to the right people.  

@Tina Behers and @Rae Gibbs I appreciate your insight on the WHY card, but this does not solve the issue.  I agree with you, Align is VERY complex and we dont want untrained fingers in the pot, trust me!! :)  I am still learning as one of my companies SMEs on JIRA/ALIGN, i dont have the capacity to train outliers.  But shutting out access to view is problematic. If there is some configuration that I am missing, please direct my course, but so far, I am not finding a solution.  Truly appreciate this dialogue however, love to see others with the same issues.

Like Danielle Favreau likes this

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events