# RFC-83: Live Docs & Pages in Confluence Cloud

**URL:** <https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495>\
**Category:** Request for Comments (RFC)\
**Tags:** confluence-cloud, rest-api, atlassian-connect, forge\
**Created:** [February 5, 2025, 12:04am UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495 "2025-02-05T00:04:33Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![DavidMichelson](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DavidMichelson](https://community.developer.atlassian.com/u/DavidMichelson)\
**Post date:** [February 7, 2025, 9:30pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/21 "2025-02-07T21:30:50Z")

</div>

**API update**

Hi all! I’m happy to share that all API updates listed in the RFC (that were not marked as “under consideration”) are now AVAILABLE in all EAP & Developer Canary Program sites for testing. Please do leverage the API updates and let us know if you have any feedback.

Cheers,  
David

---

<div class="post-metadata">

**Author:** ![BorisBerenberg](https://avatars.discourse-cdn.com/v4/letter/b/f0a364/32.png) [@BorisBerenberg](https://community.developer.atlassian.com/u/BorisBerenberg)\
**Post date:** [February 10, 2025, 8:58pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/22 "2025-02-10T20:58:00Z")

</div>

> [@scott.dudley](#):
>
> Will the subtype be supplied via AP.context.getContext() (or is it already)?

@DavidMichelson any chance you could respond to this one?

---

<div class="post-metadata">

**Author:** ![DavidMichelson](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DavidMichelson](https://community.developer.atlassian.com/u/DavidMichelson)\
**Post date:** [February 10, 2025, 9:57pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/23 "2025-02-10T21:57:09Z")

</div>

Thanks for highlighting @BorisBerenberg

Also tagging @scott.dudley as the original asker

> [@scott.dudley](#):
>
> Will the subtype be supplied via AP.context.getContext() (or is it already)?

At this time, we are not considering adding this for Connect. But, as mentioned in the RFC, we are considering making subtype available in the Forge context.

---

<div class="post-metadata">

**Author:** ![BorisBerenberg](https://avatars.discourse-cdn.com/v4/letter/b/f0a364/32.png) [@BorisBerenberg](https://community.developer.atlassian.com/u/BorisBerenberg)\
**Post date:** [February 10, 2025, 10:12pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/24 "2025-02-10T22:12:29Z")

</div>

Thanks for letting us know. I recognize that Connect is “dead”, but I ask that the team reconsiders this position. There are still too many issues for us to adopt Forge within the timeline described in the RFC. This means that customers will have subpar experiences with this feature because we can’t adapt our apps to this change. I don’t think it is in either vendors or Atlassian’s interest for customers to have a bad experience when consuming this new functionality.

---

<div class="post-metadata">

**Author:** ![Corentin](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/corentin/32/50121_2.png) [@Corentin](https://community.developer.atlassian.com/u/Corentin)\
**Post date:** [February 11, 2025, 9:16am UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/25 "2025-02-11T09:16:00Z")

</div>

@DavidMichelson

We use a configuration macro: A macro to specify app behavior on sections of the page when receiving a page update webhook.  
We currently are not displaying this macro in “View” mode, but are displaying it in “Edit” mode.  
I like the idea of reducing the macro to an icon, but I fear that our app is not recognizable enough and would like to keep the current display ( App name + Summary of settings in a few words ) when users are editing a regular Confluence page.

---

<div class="post-metadata">

**Author:** ![scott.dudley](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/scott.dudley/32/53884_2.png) [@scott.dudley](https://community.developer.atlassian.com/u/scott.dudley)\
**Post date:** [February 11, 2025, 2:40pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/26 "2025-02-11T14:40:34Z")

</div>

> [@DavidMichelson](#):
>
> > [@](#):
> >
> > Will the subtype be supplied via AP.context.getContext() (or is it already)?
> 
> At this time, we are not considering adding this for Connect. But, as mentioned in the RFC, we are considering making subtype available in the Forge context.

Hi @DavidMichelson

To underscore Boris’s point, I do understand that Atlassian has a “no new features on Connect” policy. Putting the above position into perspective, Atlassian is effectively rolling out a new feature (Live Docs) that it is forcing Connect apps to adopt, and yet the tools to support that feature are proposed to be constrained to the Forge platform.

Existing Connect apps are still invoked on Live Docs pages: most existing extension points still work, Connect content and macros are rendered, webhooks are still sent, and so on. But Live Docs pages are different from regular pages, so some apps will break in various ways. If apps cannot tell if they are being displayed on a Live Docs page or not, they cannot even disable themselves in the contexts where it would make sense.

The message Atlassian is sending here is: “We refuse to allow Connect vendors to be able to even _identify_ which pages are Live Docs and which are regular pages”.

I argue that if Atlassian is changing one of the foundational pieces of content that is handled by apps, Atlassian needs to make at least bare-bones information available about this content type to all frameworks that it currently supports (which includes Connect).

As Boris pointed out, suppose that an existing vendor has an app that only really works with non-Live Docs pages. Live Docs is coming soon, but the Forge platform features required to actually move the app to Forge will not be delivered until much later. This amounts to “we will break your app until the platform team gets around to delivering Forge prerequisites in a year”.

I understand that “nothing new on Connect” is the new mantra, but with this in mind, is including the correct context information in AP.context really an extreme amount of work?

In passing, I also wanted to say “thanks!” for your active involvement in this and related RFCs. It’s great to see Atlassian proactively communicating with the community, responding promptly during the lifetime of the RFC, and iterating the idea in ways that have a positive impact on the ecosystem. Although I do not always agree with every decision (such as is the case in this comment), I still think that having such a tight feedback loop is great. Your participation here would be a great model for other Atlassians in future RFCs.

---

<div class="post-metadata">

**Author:** ![LukasGotter](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/lukasgotter/32/43672_2.png) [@LukasGotter](https://community.developer.atlassian.com/u/LukasGotter)\
**Post date:** [February 11, 2025, 3:37pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/27 "2025-02-11T15:37:13Z")

</div>

I think this is not a good approach. And a terrible naming.

- Separating Live Pages from Publish-Mode Pages is confusing and will not help in any way I can think of
- Using Live Docs vs. Pages is absolutely not saying anything, and will confuse people, search engines and AI further down the line because it will be mixing things up with Google Docs

Instead:

- Pages are Pages, and can have two modes: **Live** and **Versioned**. Default can be Live to onboard new users who come from Google Docs etc. faster.
- When publishing the page, simply ask the User if they want to Live Edit or they want to “Publish Version 1” and “make edits in Draft mode before they become visible to all users”.

Here is the idea visually, obviously the UI can be improved to have this as a Toggle!

 ![Screenshot 2025-02-11 at 16.32.06](https://global.discourse-cdn.com/atlassiandeveloper/original/3X/7/8/78c6859527a2130b8056704ac622f1eb183b3a27.png)

What do you think?  
What made you come up with a separate Name and a Separate Content Type? What advantages would that have?

Cheers, Lukas

---

<div class="post-metadata">

**Author:** ![DavidMichelson](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DavidMichelson](https://community.developer.atlassian.com/u/DavidMichelson)\
**Post date:** [February 11, 2025, 6:00pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/28 "2025-02-11T18:00:41Z")

</div>

> [@lwonnacott](#):
>
> From this, I have a couple of requests:
> 
> - Would it be possible for us to listen for the “Done Editing” event?
> - Would it be possible to minimise the size of the container once the user has finished editing the content of the bodied macro? (This would be useful for our multi-macro model, where only the first macro of the group renders the content, and the other macros remain hidden)

Hi all - I wanted to call out these feature requests for bodied macros. Are there any other developers who use bodied macros that have any thoughts on these feature requests as well?

---

<div class="post-metadata">

**Author:** ![DavidMichelson](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DavidMichelson](https://community.developer.atlassian.com/u/DavidMichelson)\
**Post date:** [February 11, 2025, 6:02pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/29 "2025-02-11T18:02:27Z")

</div>

@LukasGotter Thank you for your feedback @JackGraves as well. We primarily landed on our current direction based on feedback from customers in our Early Access Program. I will share your feedback with the rest of the team, and as we move into further Beta stages we will continue to monitor feedback on this direction.

---

<div class="post-metadata">

**Author:** ![DavidMichelson](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DavidMichelson](https://community.developer.atlassian.com/u/DavidMichelson)\
**Post date:** [February 11, 2025, 8:53pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/30 "2025-02-11T20:53:10Z")

</div>

@Corentin and @marc

Theoretically, would the suggestion to supply subtype via AP.context.getContext() also solve for your use case (utilizing `output.type`)?

---

<div class="post-metadata">

**Author:** ![Corentin](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/corentin/32/50121_2.png) [@Corentin](https://community.developer.atlassian.com/u/Corentin)\
**Post date:** [February 12, 2025, 10:51am UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/31 "2025-02-12T10:51:08Z")

</div>

@DavidMichelson

No, unfortunately, static macros are strictly server rendered: We render a block of HTML and cannot execute Javascript. The output type must be provided to the request to `<baseAppURL>/renderMacro`

See: [https://developer.atlassian.com/cloud/confluence/modules/static-content-macro/](https://developer.atlassian.com/cloud/confluence/modules/static-content-macro/) specifically the url property.

---

<div class="post-metadata">

**Author:** ![marc](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/marc/32/39047_2.png) [@marc](https://community.developer.atlassian.com/u/marc)\
**Post date:** [February 13, 2025, 4:08pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/32 "2025-02-13T16:08:58Z")

</div>

Yes, I agree with @Corentin . We can’t use AP. , because the static content macros can’t execute javascript.

---

<div class="post-metadata">

**Author:** ![DavidMichelson](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DavidMichelson](https://community.developer.atlassian.com/u/DavidMichelson)\
**Post date:** [February 13, 2025, 5:53pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/33 "2025-02-13T17:53:38Z")

</div>

@marc @Corentin Thank you for your continued feedback. I much better understand your request.

For Atlassian-native macros, we have in principle tried to maintain a consistent experience while editing no matter whether a user is editing a Live Doc or a Page. To put that in “output.type” terms, for Atlassian-native macros we would only need to know whether output.type = preview OR display, we wouldn’t need some “live” option, as no matter whether a user is editing a Live Doc or Page, the experience will be the same.

Do you think this a principle that is possible to strive for in your apps? IE - would it be OK if your apps only ever knew if the user was in an “editing” state or not (e.g. output.type = preview OR display) - regardless of if it was a Live Doc or a Page? This would also be consistent with Forge which today has “isEditing” boolean parameter that is only either true or false instead of an output.type parameter.

---

<div class="post-metadata">

**Author:** ![Corentin](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/corentin/32/50121_2.png) [@Corentin](https://community.developer.atlassian.com/u/Corentin)\
**Post date:** [February 14, 2025, 2:56pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/34 "2025-02-14T14:56:09Z")

</div>

This is not ideal, but we can live with this decision.  
We would display the same macro in live and preview mode.

---

<div class="post-metadata">

**Author:** ![DavidMichelson](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DavidMichelson](https://community.developer.atlassian.com/u/DavidMichelson)\
**Post date:** [February 14, 2025, 5:50pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/35 "2025-02-14T17:50:24Z")

</div>

Hi Developers - I wanted to check in and see if anyone had any other feedback on the [**Extension Point Modules** section](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495#p-194645-extension-point-modules-15).

@scott.dudley How would you feel if we shortened the “default off” period from 6 months to 3 months?

---

<div class="post-metadata">

**Author:** ![scott.dudley](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/scott.dudley/32/53884_2.png) [@scott.dudley](https://community.developer.atlassian.com/u/scott.dudley)\
**Post date:** [February 14, 2025, 7:12pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/36 "2025-02-14T19:12:06Z")

</div>

> [@DavidMichelson](#):
>
> @scott.dudley How would you feel if we shortened the “default off” period from 6 months to 3 months?

My first question would be, what concrete problem is being solved by turning everything off by default? For example, are there known problems with existing apps? On the other hand, if this is just a deprecation period to check a box for an internal requirement, I believe that earlier versions of this RFC already have already effectively given vendors notice.

For me, it doesn’t really matter: I will push out the descriptor change to add what is needed. Other vendors have users stuck on old versions of app manifests which they cannot force-upgrade, so their apps will be automatically turned off in these areas for whatever period is decided.

Figuring out how many existing apps have known problems when enabled (as implied by my question above) would help answer the question of: “Which option causes the least disruption?”, which I assume is the goal. In other words, if auto-disabling for some period creates more problems than just leaving enabled, the choice should be clear.

---

<div class="post-metadata">

**Author:** ![DavidMichelson](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DavidMichelson](https://community.developer.atlassian.com/u/DavidMichelson)\
**Post date:** [February 18, 2025, 5:59pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/37 "2025-02-18T17:59:56Z")

</div>

Hi developers!

I have updated the **Discuss** date to continue through the end of this week, until Friday February 21. (Previously, it was until today, Tuesday February 18).

---

<div class="post-metadata">

**Author:** ![NiloufarVafaei](https://avatars.discourse-cdn.com/v4/letter/n/5fc32e/32.png) [@NiloufarVafaei](https://community.developer.atlassian.com/u/NiloufarVafaei)\
**Post date:** [February 20, 2025, 11:44pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/38 "2025-02-20T23:44:00Z")

</div>

> [@DavidMichelson](#):
>
> ### Live Doc & Page States
> 
> We recommend ensuring that your app functions well across all states that Live Docs and Pages can be experienced in:
> 
> - Editing a Live Doc
> - Viewing a Live Doc
> - Editing a Page
> - Viewing a rendered Page
> 
> Also continue to consider permissions scenarios around who can edit / view Live Docs, these continue to exist in Live Docs (e.g. a user may have view-only permission of a Live Doc).

Can an admin update permissions through the space settings? Are these states accessible through the [REST API](https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-space-permissions/#api-spaces-id-permissions-get) as well?

---

<div class="post-metadata">

**Author:** ![DavidMichelson](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DavidMichelson](https://community.developer.atlassian.com/u/DavidMichelson)\
**Post date:** [February 21, 2025, 5:49pm UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/39 "2025-02-21T17:49:54Z")

</div>

Hi developers, I’m happy to share that the changes outlined under [Connect Webhooks / Forge Events](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495#p-194645-connect-webhooks-forge-events-11) in the RFC are now available for sites with Live Docs (which includes all sites in the Developer Canary Program). Please do give them a try!

---

<div class="post-metadata">

**Author:** ![DavidMichelson](https://avatars.discourse-cdn.com/v4/letter/d/d9b06d/32.png) [@DavidMichelson](https://community.developer.atlassian.com/u/DavidMichelson)\
**Post date:** [February 22, 2025, 12:31am UTC](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495/40 "2025-02-22T00:31:58Z")

</div>

@NiloufarVafaei

> Can an admin update permissions through the space settings?

Live Docs have the same permissions capabilities as Pages! There are space level permissions that can be updated the same as Pages.

> Are these states accessible through the [REST API](https://developer.atlassian.com/cloud/confluence/rest/v2/api-group-space-permissions/#api-spaces-id-permissions-get) as well?

These states are not available through REST API.

[Previous page](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495.md?page=1)

[Next page](https://community.developer.atlassian.com/t/rfc-83-live-docs-pages-in-confluence-cloud/88495.md?page=3)
