Community resources
Community resources
Community resources
Page approvals in Confluence that can't go stale - meet Greenlight
Disclosure: I'm the developer of Greenlight, a new approvals app for Confluence Cloud. This post is about the problem it solves and the design decisions behind it. Questions and critique welcome.
The badge that lies
If your team reviews pages in Confluence (QA procedures, tech docs, HR policies, runbooks), chances are you've improvised approvals with labels, comments, or page statuses. All of these share one failure mode: the page changes, and the "Approved" badge stays. Whoever opens the page next is trusting a review that never covered what they're actually reading. That's worse than no badge at all.
Before writing any code, I read recent Marketplace reviews for approval apps in this category. In a June 2026 snapshot, 11 of the last 15 reviews for one established app were 3 stars or lower, and the same complaints came back year after year:
- the approved status surviving new versions of the page
- no simple way to lock a page after sign-off — as one reviewer put it, verbatim: "you should block rights to update a approved page!"
- workflow rules that any page editor can change
- notifications that need separate email setup, or don't arrive at all
- billing/licensing hiccups that can freeze the workflow
So I used that list as the spec for a small app, and tried hard not to add anything beyond it.
How Greenlight handles it
Greenlight is built around one approval rule: an approved Confluence page should stop looking approved as soon as its content changes.
It puts a status on the page byline: "Pending", "Approved", or "Changed after approval". Assigned approvers get an Approve button right there. The byline is intentionally boring: the status shows up where people already look.
The obvious way to build the auto-reset is to listen for page-update events and flip the status when one arrives. I didn't trust that, and a quick test before writing the real thing confirmed it: Confluence Cloud events can arrive late or out of order, so an event-driven badge can keep showing "Approved" on a page that already changed. (Live docs are the extreme case: there even the page version itself is reported with a lag of about fifteen minutes.) Greenlight doesn't use events for status at all. Every time the byline renders, it compares the page's current version against the version that was approved. If they differ, the status reads "Changed after approval". Because the check happens on every render, an edited classic page stops showing "Approved" the moment anyone next loads it: there is no code path that keeps a stale badge.
A side note from the same experiments: I wanted to let trivial edits through without resetting the approval, using Confluence's "minor edit" flag. Turns out Cloud doesn't really expose it: the REST field is read-only and always false. So any new version resets the approval. That annoyed me at first, but at least the behavior is predictable.
The rest of the complaint list, in order:
- Lock after approval (optional). Once a page is approved, Greenlight adds an edit restriction. Unlocking is one click, visible to everyone, and any edit after it requires re-approval. It's meant as a speed bump that stops the casual edit right after sign-off.
- Admins own the rules. Space admins decide who approves, whether one approval is enough or everyone must sign, and whether pages lock; page editors can't quietly change the approval process from the page.
- Native notifications. Approvers get a Confluence @mention, the bell they already check, so there's no email server to configure.
- Billing hiccups. If the subscription lapses, every status stays visible, and unlocking pages or turning approval off still works; only approving itself pauses.
Installing it changes nothing by itself, which matters if you admin a busy site: approval is off on every page until an editor turns it on for that specific page. And the optional lock is a plain Confluence page restriction underneath, so a space admin can always remove it from the page's restrictions dialog, with or without the app.
For the security-minded, Greenlight is built on Forge and carries the Runs on Atlassian badge. It has no servers of its own and sends nothing outside Atlassian, and data residency follows your site. You can verify that on the listing instead of taking my word for it.
What it deliberately is not
Greenlight is not a regulated-signature / GxP tool. Approvals here are workflow metadata, not legally binding e-signatures. It works on classic Confluence pages today; live docs are on the roadmap, and the honest reason they're not in yet is the same version-lag issue I mentioned above: on a live doc even a render-time compare would be trusting a stale version. I'd rather wait than support them badly. If you need multi-step review chains, conditional stages, or compliance reporting, the bigger suites do that and Greenlight doesn't.
Pricing
Free for sites with up to 10 users. Above that, a 30-day free trial, then per-user pricing: as of July 2026 it starts at $0.49 per user per month, and the per-user rate drops at larger tiers.
Try it / tell me what's missing
Greenlight is on the Atlassian Marketplace:
https://marketplace.atlassian.com/apps/1982391444/greenlight-page-approvals-for-confluence
If you run a review process in Confluence, app-based or improvised, I'd like to hear what it gets wrong. I'm especially interested in teams that currently use labels, comments, page statuses, or a heavier approval app, and only need the basics done properly. I'll use that feedback to decide what gets built next; live-doc support is currently at the top of the candidate list.