Sign up for Confluence Full Page module EAP

[VickyHu]

By signing up for this Early Access Program (“EAP”), you acknowledge that use of the Confluence Full Page App module is governed by the Atlassian Developer Terms. The Confluence Full Page App module is considered “Early Access Materials”, as set forth in Section 10 of the Atlassian Developer Terms and is subject to applicable terms, conditions, and disclaimers.

Summary of project:

The Confluence Full Page module aims to enable developers to build fully custom, chromeless app experiences within Confluence Cloud, hosted directly on Forge. This offering is a key step in Atlassian’s strategy to empower partners and customers to build sophisticated, enterprise-grade solutions directly on the Atlassian platform. This post explains our current solution including some high-level technical designs and guidelines. We’re looking for feedback to make sure we build the best possible solution. As we continue to develop this solution, the information outlined below may evolve over time.

To join this Early Access Program, please complete the Forge EAP sign-up form.

Who are we solving for?

Customers

This initiative is designed to support enterprise customers who require branded, full-screen solutions without Atlassian navigation or branding.

Partners

This initiative provides partners with more UI flexibility for their solution.

EAP solution overview

Forge Full-page apps for Confluence can be built by configuring a confluence:fullPage module in the App manifest.yml. Learn more here.

Viewing full-page apps

Right now, there is no easy way (like a button) to open a Confluence full page app. App builders must make the URL themselves to view or test their app. This is a temporary limitation for full page apps in Confluence.

Confluence full-page apps will have the following base URL structure:

https://<site-host-name>/wiki/full-page/<app-id>/<environment-id>

• site-host-name: the base URL of the Atlassian site with Confluence installed, e.g. my-org.atlassian.net
• app-id: The Forge app ID of the app in UUID format
• environment-id: The ID of the environment that the Forge app is deployed to in UUID format

Any subsequent URL segments are managed by the Forge app through the bridge createHistory API.

Known Limitations

1. Forge Modals have not been made available.
2. Many features exposed by the Forge bridge SDKs have not been made available. Feedback is welcomed regarding use cases for existing and new bridge capabilities.

Feedback

We welcome your thoughts on this EAP and, in particular, would greatly appreciate your feedback on the following questions:

1. What are the best use cases for the Full Page UI?
2. What additional types of components would add value to a full page experience for you?
3. What new and existing features of the Forge app SDKs would help you build your use case?

We look forward to your feedback!

[jens]

Hi @VickyHu,

thanks for the RFC, it’s great to see Atlassian is working on fullscreen mechanisms in Forge

In our connect apps we use fullscreen modals and - ignoring the first limitation for now - I was wondering how we would include product context such as spaces, pages, custom content entities in the URL / forge bridge context (view.getContext). Or is that an example for limitation #2?

Without such context I think we could use that module only for very generic views like a getting started page etc.

[shushen]

Hi @VickyHu,

This is exciting, thanks for sharing the EAP.

Would it be possible to make this full page module to be de-coupled with Confluence? A use case we’d like to see is in combination with Cross-Context apps, this full-page module would provide the UI entry point for our customers to work with both Jira and Confluence. Currently we have two separate apps listed on Marketplace, one for Jira and the other for Confluence, and we would very much like them to be combined and have a seamless cross-context experience for the customers.

Ideally:

• The URL would have no wiki component, e.g., https://<site-host-name>/full-page/<app-id>/<environment-id>
• The full-page module can be discovered/navigated from the “Customized application navigator” on the top menu of the site (i.e., where /wiki/admin/application-navigator allows admins to add new items, and in this case, enable/disable the full-page modules if they wish). This location appears to be a logical point of entry for cross-context apps:
  
  

Looking forward to seeing this EAP evolves!

Thanks,
Shu

[shushen]

On Forge bridge, we’d very much like to see the Data Loss Prevention (DLP) APIs being exposed as a (say) requestDLP in Forge bridge API.

This fits into our cross-context app use case, where the app would call the DLP APIs to configured Atlassian Guard settings that applies to both Jira and Confluence (e.g., classification levels). This feature request currently has an outstanding ECO work item: https://jira.atlassian.com/browse/ECO-953.

[JulianWolf]

Thanks for the update @VickyHu ! We’d love to use this functionality. Apparently our site needs to be allowlisted first.

Two things came to mind:

I think the module should allow the partner to change the title of the window (via manifest.yml or a bridge method) and maybe even the fav-icon so that users know that they are on a subpage of Confluence when looking at their tab.

Also, we’d like to leverage this functionality to offer a fullscreen macro editing experience in apps like draw.io. Is it planned that the full-page module supports this use case, maybe by the ability to cross-reference a full-page module as the macro editor?

Best,
Julian

[KrzysztofBogdan2]

Hello,

1. The URL problem

I think it is non-user friendly URL: full-page/<app-id>/<environment-id>.

full-page in URL is information about data presentation format.
This is not how URL should be designed.

Usually http headers are they best way to request data in required format, for example:
Accept: application/json

In this case there is no way to do that.
So query param would be second choice, something Confluence api already does, for example:
/wiki/api/v2/blogposts/{id}?body-format=atlas_doc_format

but still I have no idea why you need information about page size in URL:
full-page/<app-id>/<environment-id>,
medium-page/<app-id>/<environment-id>,
small-page/<app-id>/<environment-id>

What does it matter in URL?

what would make more sense?
https://{instane-url}/wiki/app/{cool-short-key-from-module}

example:
https://{instane-url}/wiki/app/approvals

Of course there would be problem if 2 apps would have similar key.

There are few ways to solve that.

For example:
https://{instane-url}/wiki/app/{url-friendly-app-name}/{cool-short-key-from-module}

Also you already have Global Page: https://developer.atlassian.com/platform/forge/manifest-reference/modules/confluence-global-page/

Why not adding a config option about how to display this page (with navigation option?):

  confluence:globalPage:
    - key: key-global-page
      resolver:
        function: global-page-resolver
      title: Cool
      navigation: hidden

2. External Share app use case - Anonymous access

With our External Share app - it would be perfect place to show data to external user.
App should be capable to read full URL and be mounted in nested paths:
https://{instane-url}/wiki/app/{url-friendly-app-name}/{cool-short-key-from-module}/dynamic-path-1/dynamic-path-2/dynamic-path-3?customAbc=1&customZXC=2

[RonnyWinkler]

Hi @VickyHu,

thanks for sharing the idea for building a chromeless full page feature for Forge apps.

I have a question about the known limitation regarding the Forge Modals you’ve mentioned: does this mean that it is currently not possible to open a Forge Modal from within the new Full Page module or are you referring to also support a chromeless full screen mode for Forge Modals later?

If it is the 2nd then that’s what we are looking for. In this case we would be interested in more details how it would work. Currently, I can’t really grasp how the new Forge module could solve this requirement (e.g. why should the URL change when a user opens a modal dialog?).

In case the limitation is referring to opening a Forge Modal from within the Full Page module then this new module, unfortunately, won’t be a helping in our Connect to Forge migration. We are looking for a solution to FRGE-557. This means there is a possibility to have a full screen and chromeless modal Custom UI dialog in Forge that is also available for the configuration of macros. I explained it in more detail in a comment to that ticket. Allowing devs to make the existing Forge Modals chromeless would already be a good first step for us and is probably easy to achieve on your side.

[AndreaSerra]

@RonnyWinkler

In case the limitation is referring to opening a Forge Modal from within the Full Page module then this new module, unfortunately, won’t be a helping in our Connect to Forge migration. We are looking for a solution to FRGE-557. This means there is a possibility to have a full screen and chromeless modal Custom UI dialog in Forge that is also available for the configuration of macros. I explained it in more detail in a comment to that ticket. Allowing devs to make the existing Forge Modals chromeless would already be a good first step for us and is probably easy to achieve on your side.

This is exactly what we need!

Hoping to see some progress as well on FRGE-557 soon - even that first step of making existing Forge Modals chromeless would make a significant difference for teams in similar situations.

[VickyHu]

Hey Everyone!
Thanks so much for the interest in this EAP! I just wanted to clarify a few things.

1. This full page module will evolve to allow developers to create standalone app experiences that operate independently without a licensed Atlassian product such as Confluence or Jira
2. The use case many of you have mentioned about full page modals will be released as a separate Confluence UI feature and is currently in progress. The estimated timeline is Q2FY26 for release. Please follow this public roadmap item to get updated.

Sorry for any confusion as these are both providing full page experiences! Appreciate the individual feedback around use cases and needs for a full page independent app experience. We’re currently compiling and reviewing your feedback and will reply individually soon.

[HanLe]

Hello Atlassian developers!

Just a small announcement for everyone who has signed up for Confluence Full Page module EAP:

If your ticket status is In Progress, this means that the module has been enabled on your site! Your ticket status will move to Done only after the EAP is completed.

Thank you everyone.