Feature - Approvals, Reviews and Attestation

sam · September 22, 2026, 7:41am

We have written about these features a few times already, in separate threads. They belong in a single post because they are tied to each other.

So this article tries to pull them together in one place, to give you something to start digesting. None of it is final, and that includes the naming. We wanted to show it anyway rather than wait until every detail is settled.

The loop

A document is drafted and approved, and approving it publishes a version. Publishing does two things by itself: it asks the audience to read and confirm the document, and it sets the date of the next review. When that date arrives the review runs. If the reviewer says the document is fine, a new review date is set and nothing else changes. If the reviewer says it needs changing, eramba opens a revision, that revision goes back through approval, and publishing it starts the loop again with a new version.

Settings

All three are configured in one place: Settings → Workflows, Reviews & Attestation. Three tabs, one Save button. The big news here is that we have also moved the notification settings into this form, so you choose what you want to be notified about while you set the module up.

Whoever sits in the GRC Contact field can raise or withdraw an approval request. Whoever sits in the Policy Reviewer Contact field can approve or deny it. You can add a custom role or any existing group. Admins can always do both. If nobody responds within the number of days you set, the request is denied automatically.

The same two-role idea applies to reviews: one role owns and closes them, the other provides feedback.
Review Schedule: either every document in the section follows the same rhythm, or each document carries its own date. Every item must have a future review scheduled.

Attestation asks a group of people to read a published policy and confirm they understood it. You pick the audience and how often they are reminded. It cannot run without Workflows, because attestation is attached to a published version, and it needs the Policy Portal, because that is where people confirm.

Approvals

A published document is not edited, it is revised. The action is called Revise Document and eramba is explicit: you get an editable copy, and the published document does not change until the revision is published. Anyone reading the portal in the meantime still sees the approved text.
Step one records the approval and the approver’s comment. Step two schedules the next review. Step three summarises both. You cannot approve a version and forget to schedule its review.

Reviews

A review sits as Scheduled until its date, becomes Overdue if nobody starts it, and can also be started early. Once started it is a short conversation between two roles: the reviewer writes feedback in a thread, and only then can the owner record a decision.

Two outcomes, and they lead to genuinely different places. Document is fine schedules the next review and the document carries on. Document requires changes opens a revision automatically, so the next time you look at the document it is already waiting to be edited and resubmitted. You do not have to remember to act on your own review.

While a review is running the document cannot be revised. It is either being reviewed or being changed, never both.

Attestation

Every published version starts its own attestation round. The audience is invited by email, reminded until they confirm, and their confirmation is recorded against that specific version.

Which means publishing version 2.0 does not inherit the confirmations from version 1. Everyone is asked again, because the document they agreed to is no longer the document that is published. From the reader’s side it is a portal with the documents they need to read, showing the approved text, the owner, the version, and when it was approved.
The evidence comes out as a CSV: one row per invite, reminder and confirmation, with the person, the date and the version.

Activity log

The Activity Log on each document is grouped by version.

Inside a version you get who changed what, field by field, with the old text struck through and the new one beside it. You also get who asked for approval and what they said, and who approved it and what they said. The version selector above the document does the same for the text: pick version 1 and you see the text as it was approved, not as it is now.