RFCs are 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!
Summary of Project:
- Publish: Sep 22, 2025
- Discuss: Oct 3, 2025
- Resolve: Oct 17, 2025
Problem
Customers need to collaborate with stakeholders external to their organisation, such as contractors, freelancers, agencies and customers. But to enable this today in Jira, a full license needs to be purchased for every user or anonymous access which lets any non-logged in person create, search or view work items, needs to be enabled. Furthermore, Jira data embedded or linked in other Atlassian products, such as Confluence or Trello, is not visible to guests in those products.
In order to remove this barrier to external collaboration in Jira, we will be enabling free guest access, through an experience similar to free guests in Confluence. As part of this, we need to decide how free guests in Jira should have access to Apps.
Proposed Solution
User experience
- Free guests in Jira will be able to be added to a site and then invited to a single Jira space* (both team-managed and company-managed, business and software).
- A space admin can assign either a “viewer - guest” or “collaborator - guest” space role to a guest (these roles will have a subset of project and issue permissions).
- Guests will have access to all views within the space they have been invited to, including the board, all work and work item views.
- Any data from other spaces, such as linked work items or cross project parents, will not be visible.
*Jira projects are becoming spaces, read more here Evolving Jira terminology: ‘Projects’ will soon be ‘Spaces’ . Any reference to a Jira space in this RFC refers to what was previously a Jira project.
Permissions guests will have access to (subject to change)
If a permission is not listed below, guests will not be eligible for this permission. The below list is subject to change as we continue our explorations.
Global:
- Make bulk changes only, all others excluded
Team managed:
-
Most Work on issues permissions
-
Excluding move any issue
-
Assign any issue is TBC
-
-
All Create issues permissions
-
All Collaborate on issues permissions
Company managed:
-
Most Space permissions
- Excluding manage sprints and service project agent
-
Most Issue permissions
-
Excluding archive issues and restore archived issues
-
Assign issues and modify reporter permissions are TBC
-
-
All Voters & watchers permissions
-
Most Comments permissions
- Excluding delete all comments and edit all comments
-
Most Attachments permissions
- Excluding delete all attachments
-
Most Time tracking permissions
- Excluding delete all worklogs and edit all worklogs
Please note that we wanted to share the details of this project for early feedback. Some decisions are still open and are yet to be finalised. These include:
- License packaging for free guest access e.g. paid user to guest ratios, inclusion in free and standard plans etc.
- Whether a guest will be able to view and select global user pickers, such as Assignee.
- Whether other fields will be hidden from guests, due to security reasons, such as Labels or Components.
Impact on Apps
- Similar to Confluence, guests will not be part of the licensed user count on the customers Jira instance and so will not be charged for app usage.
- We are proposing that by default, free guests will not have access to Apps. This is different to Confluence which enables access by default. We are proposing this deviation to:
- Mitigate the risk of data leakage (mainly from other spaces) to guests.
- Enable App developers the ability to enable guest support and experience changes (if desired), on their own timelines (but we are open to feedback on this decision to default off).
- We will create a new condition so that individual Apps can enable guests to access their products (see details below).
Affected modules - Forge
UI kit and custom UI modules:
The following modules will be blocked for guest users unless explicitly allowed:
- Issue Panels:
jira:issuePanelmodules will not be displayed - Issue Actions:
jira:issueActionmodules will be blocked - Issue Glances:
jira:issueGlancemodules will not be shown - Project Pages:
jira:projectPageandjira:projectSettingsPagemodules will not be accessible - Global Pages:
jira:globalPagemodules will not be accessible
Macro and Content modules:
- Custom Content: UI components (view, edit, list) will be blocked
All other modules not listed will continue to function normally for guest users.
Affected modules - Connect
The following modules will be blocked for guest users unless explicitly allowed:
- Web Items, Web Panels, Web Sections: UI elements will not be displayed
- Dialogs: Dialog UI elements will be blocked
- General Pages: Custom pages will not be accessible
- Custom Content: UI components (view, edit, list) will be blocked
All other modules not listed will continue to function normally for guest users.
No action required for many Apps
If you don’t want to support guest users, no action is required. Your app will continue working normally for all paid users and will be automatically blocked for guests.
How you will be able to enable guest access for your App
Forge
Option 1: using display conditions (recommended)
Add the isJiraGuest display condition to your Forge app manifest to allow guest access:
modules:
jira:issuePanel:
- key: my-issue-panel
title: My App Panel
resource: panel-resource
displayConditions:
- condition: isJiraGuest
invert: false
Inverting the condition
To explicitly block guest users while allowing regular users:
`displayConditions:
- condition: isJiraGuest
invert: true
Complex conditions
You can combine guest conditions with other display conditions using logical operators:
displayConditions:
- and:
- condition: isJiraGuest
invert: false
- condition: entity_property_equal_to
params:
entity: issue
propertyKey: my-app-enabled
value: "true"
Option 2: using context in runtime
The context.user.isJiraGuest property will be available in your Forge app’s runtime context, allowing dynamic decisions:
Custom UI (React):
import { view } from '@forge/bridge';
const App = () => {
const [context, setContext] = useState(null);
useEffect(() => {
view.getContext().then(setContext);
}, []);
if (context?.user?.isJiraGuest) {
// Handle guest user experience
return <GuestUserInterface />;
} else {
// Handle regular user experience
return <FullUserInterface />;
}
};
UI kit:
import { useProductContext } from '@forge/ui';
const App = () => {
const context = useProductContext();
if (context.user.isJiraGuest) {
return (
<Text>Limited functionality for guest users</Text>
);
}
return (
<Text>Full functionality for licensed users</Text>
);
};
Connect
Option 1: using Connect conditions (recommended)
Add the is_jira_guest condition to your Connect app descriptor to allow guest access:
{
"modules": {
"webItems": [
{
"key": "my-web-item",
"location": "operations-top-level",
"name": {
"value": "My App Action"
},
"url": "/my-action",
"conditions": [
{
"condition": "is_jira_guest",
"invert": false
}
]
}
]
}
}
Inverting the condition
To explicitly block guest users while allowing regular users:
"conditions": [
{
"condition": "is_jira_guest",
"invert": true
}
]
Option 2: using Context Parameters
A new user.isJiraGuest context parameter will be available in all app URLs, allowing runtime decisions:
// Example: Check guest status in your app
if (AP.context.getContext().user.isJiraGuest) {
// Handle guest user experience
showLimitedFeatures();
} else {
// Handle regular user experience
showFullFeatures();
}
Best practices for App developers
If you choose to support guest users, please ensure that:
- Proper authorization checks are implemented - verify the user’s project access before showing any data.
- Data is scoped appropriately - only show information from spaces the guest has access to.
- Consider guest-specific UX - Guests will have limited functionality (see list of permissions a guest is eligible for above), so we recommending reviewing experiences your Apps offer for this new user type in Jira.
Migration from Confluence patterns
If your app already supports Confluence guests using user_is_external_collaborator, the patterns are very similar:
// Confluence pattern
"conditions": [
{
"condition": "user_is_external_collaborator",
"invert": false
}
]
// Jira equivalent
"conditions": [
{
"condition": "is_jira_guest",
"invert": false
}
]
Technical resources
- Connect Conditions Documentation (will be updated with
is_jira_guestdetails) - Context Parameters Documentation (will include
user.isJiraGuest) - Forge Display Conditions Documentation (will be updated with
isJiraGuestdetails) - Forge Product Context Documentation (will include
user.isJiraGuest) - Forge Security Overview
- Confluence Guest Access RFC (for reference)
Asks
- We are eager for your feedback on the proposed experience and solution outlined above:
- How might we improve the enabling experience?
- Is defaulting to off the ideal?
- Are there other modules where your App shows data to a Guest that we haven’t identified?
- Is the information above sufficient to identify the impact of this change?
- We plan to run an EAP with customers in late Jan/early Feb 2026. Closer to this time, I will post an update, including an option for Apps to sign-up to be a part of our EAP.
