Object Comment Field

Business Requirements Document (BRD)

🧩 Object Comment Field

🔖 1.0

📅 Thursday, 18 June 2026

👤 Martijn Bruitsman, Peter Disselkoen, Bernard Bos

⚙️ Meltem Coroz

1️⃣ PURPOSE

This document defines the business requirements for the Object Comment Field Epic. It covers the ability for backoffice users to add, update, and delete comments on objects within GiroPro. A comment is stored with the authoring user, timestamps, and the comment text. Comment functionality will be available in the user interface and via the API. Comment functionality is implemented as a generic capability that can be attached to GiroPro objects.

Examples of objects that support comments include, but not limited to:

• Order
• Journal Entry
• CAMT.053 Transaction
• SEPA Transaction
• Backlog Item
• Employer (Arrangement)
• Cost Plan and Cost Record
• PSK Records

2️⃣ SCOPE

The Object Comment Field Epic covers the following functional areas:

• Adding, updating, and deleting comments on objects.
• Storage of comment text, authoring user, and timestamps per comment.
• Managing comments per object via the user interface and the API.

The following is explicitly out of scope for this Epic:

• Notifications or alerts triggered by comments.
• Mentions or tagging of other users within comments.
• Comment threading or replies.
• Approval on comments.

3️⃣ GLOSSARY

The following terms are used throughout this document:

• Label The party responsible for administering and managing the investor’s investments.
• Backoffice User A label employee with access to the GiroPro backoffice, authorised to create, update, and delete comments on objects.
• Object Any entity within GiroPro that supports the comment functionality.
• Comment A free-text entry placed on an object by a backoffice user, stored with the authoring user and a timestamp.
• Timestamp The date and time at which a comment was created or last updated.

4️⃣ FUNCTIONAL REQUIREMENTS

4️⃣1️⃣ Comment Management

Every object within GiroPro supports the ability for backoffice users to place comments. Comments are owned by the authoring user and are available in the user interface and via the API.

The following operations will be supported:

• Add Comment A backoffice user can add a comment to any object. The comment is stored with the authoring user and created timestamp.
• Update Comment A backoffice user can update their own comments. Updating a comment will update the last updated timestamp.
• Delete Comment A backoffice user can delete their own comments.
• Retrieve Comment By default comments are ordered descending by creation timestamp. The API will support alternative ordering options. All backoffice users with access to the object may retrieve all comments belonging to that object.

4️⃣2️⃣ Comment Data

Each comment stored on an object contains the following fields:

• Authoring User The backoffice user who created the comment.
• Create Timestamp The date and time at which the comment was created.
• Last Updated Timestamp The date and time at which the comment was last updated.
• Comment Text The free-text content of the comment.

4️⃣3️⃣ Retrieval via API

Full comment management is available via the API. All operations supported in the user interface — adding, updating, deleting, and retrieving comments — are equally available via the API.

4️⃣4️⃣ DATA MIGRATION

Existing comments present in the current system will be migrated to the new data model, provided they contain the required fields as defined in section 4️⃣2️⃣.

• Comments that contain all required fields will be migrated and linked to the corresponding object.
• Comments that do not contain the required fields will not be migrated.

5️⃣ BUSINESS RULES

The following business rules will be enforced by the system:

• BR-01 — Comments are user-owned
  • A comment is owned by the backoffice user who created it.
  • A backoffice user can only update or delete their own comments.
  • Users with administrator privileges may update/delete any comment.
• BR-02 — Comment requires all fields
  • A comment must contain an authoring user, a created timestamp, and a comment text.
  • Empty comments are not permitted.
• BR-03 — Timestamps are system-generated
  • The timestamps are set by the system at the moment of creation or update.
  • The timestamp is not editable by the user.
• BR-04 — Updating a comment updates the last updated timestamp
  • When a comment is updated, the last updated timestamp is updated to the moment of the update.
• BR-05 — Comments are available on all objects
  • Every object within GiroPro supports comments.
  • There is no limit on the number of comments per object.
• BR-06 — Comment lifecycle follows object lifecycle
  • If an object is deleted comments belonging to the object are deleted too.
• BR-07 — Comments visibility in the user interface
  • Comments are only visible within the applicable object form.
• BR-08 — Comments audit trail
  • All comment create and update actions are logged in the history service.