New in Read & Confirm: a "My Confirmations", and re-confirming after a page changes

[#1]

Hi everyone,

Read & Confirm for Confluence is an app I build at MiddleCore, and it launched earlier this year. Since then I've added a handful of things, so I wanted to share an update on where it is now. Rather than list the features flatly, I'll walk one confirmation request through its whole life: how it gets assigned, where people find it, and what happens when the page changes underneath it.

1. Assigning a confirmation

From the dashboard, + New creates a confirmation request on a page. You pick who needs to confirm:

• Specific users — assign named individuals. Each gets a confirmation record and a notification (a footer comment that mentions them). The creator is excluded, so you don't notify yourself.
• All viewers — anyone who opens the page is asked to confirm; their record is created the first time they actually view it.

You can add a deadline and a short message. On creation, the confirmation macro is embedded on the page automatically, so the Confirm button appears right where people are reading. Set a deadline and the default reminders (7 days and 1 day before) come along too.

2. My Confirmations — where recipients track what they owe

Most of the dashboard is built for the person running a rollout. My Confirmations is the other side: a personal inbox in the left sidebar for the people receiving requests.

It gathers every request you're a target of, across all pages, in one place:

• Pending first, sorted by deadline, with confirmed items at the bottom
• A running Pending / Confirmed count
• Each row shows the page, whether you were individually assigned or caught as a viewer, the deadline, and when you confirmed

One honest caveat: for viewer-type requests, a row only appears once you've actually opened that page. Pages you've never visited won't show up here — we surface what we can verify, not what we can't.

3. When the page changes — Reset and Re-confirm

Now to that last stage. A confirmation really answers: did this person acknowledge this version of this page? So Read & Confirm records the page version each person confirmed.

When the page is edited after confirmations exist, the creator sees a Page updated notice on the request, with three choices:

• Reset confirmations — send everyone back to pending to re-acknowledge the new version
• Update all to latest — treat the existing confirmations as still valid for the new version (no re-confirm)
• Keep current — dismiss the notice without changing the confirmations

There are two ways people end up re-acknowledging:

• If you Reset, everyone returns to pending and sees the Confirm prompt again on the page — a clean fresh round.
• Or, without a reset: once someone has confirmed and the page then changes, their embedded macro marks that confirmation outdated ("You confirmed v1. Page is now v2.") and shows a Re-confirm button.

This is manual and creator-controlled — you decide when an edit is big enough to warrant a fresh round. (It isn't an automatic recurring re-confirmation on a schedule; that's a separate idea.)

Why it's built this way

The three steps share one foundation:

• Confirmations and notifications all stay inside your Atlassian environment — Forge-native, no external servers
• Notifications reuse Confluence's own mention system, so follow, mute, and email rules keep working
• Every confirmation is tied to a specific page version — which is what makes Reset and Re-confirm meaningful rather than cosmetic

I'd be curious how this maps to your world:

• For re-acknowledgment, where's your line — what size of edit is "big enough" to reset?
• Does a personal inbox match how your end users actually look for what they owe?

Marketplace listing: https://marketplace.atlassian.com/apps/1138072457/read-confirm-for-confluence