Engagement: Announcements & Recognition (ENG)
Module code ENG · Release R2 · Packaging Plan tier (Professional+) · Requirements
FR-ENG-*,BR-ENG-*in the PRD and BRD
1. Overview and scope
ENG is a small module with a high retention payoff. It provides announcements targeted at audiences with read receipts and acknowledgements, recognition between colleagues and from managers, a company wall with reactions, and automatic celebrations (birthdays, work anniversaries, new joiners).
Out of scope: surveys and pulse checks (later), points redeemable for rewards (later, with a partner), performance reviews.
2. Learned from the reference product
Source: Spryple analysis, §4.2, §13 and §21.9.
- [Observed] Announcements have topic, title, publish from and to, description; Submit (Published) or Save as Draft; status-driven actions (Published → edit/view/stop; Completed → republish) (SP-ENG-01).
- [Observed] Rewards & Recognition in the HCM app: send to a peer with a recognition type and message; Sent and Received lists; a count report per type (MOB: HCM).
- [Observed] Recognition types include Birthday, Outstanding, Job Well Done, Congratulations and Performance-based; messages come from a template with a 145-character limit (§21.9).
- [Inferred] There is no audience targeting, read receipt, reaction or public wall (§13).
3. Our design decisions
| ID | Decision [Proposed] | Reason |
|---|---|---|
| D-ENG-01 | Announcements target an audience rule (locations, departments, designations, employment types, or everyone) evaluated at publish time and stored as a snapshot. | Branch-specific notices; auditable reach. |
| D-ENG-02 | Optional "acknowledge required" with tracking and reminders. | Policy updates need proof of reading. |
| D-ENG-03 | Recognition types are tenant data with optional manager-only types and a public or private visibility. | Flexibility; some recognitions are personal. |
| D-ENG-04 | Celebrations are generated daily from EMP data, respecting an employee opt-out for birthdays. | Privacy for date of birth. |
4. Domain model
5. State machines
6. Key business logic
publish(announcement):
audience = employees matching rule on publish date (EMP job assignment)
store resolved_count ; fan out via NTF (in-app always, push and email per settings)
if ack_required: schedule reminders at +2 and +5 days for those not acknowledged
recognise(from, to, type, message):
require from != to ; require length(message) <= setting.max_message_length
if type.manager_only: require from is in to's management chain
limit per sender per day (anti-spam)
7. Configuration
| Setting | Type | Default | Description |
|---|---|---|---|
announcement.default_channels | array of string | [IN_APP, PUSH] | Delivery channels |
announcement.ack_reminder_days | array of integer | [2, 5] | Reminder schedule |
recognition.max_message_length | integer | 280 | Message limit (reference uses 145) |
recognition.daily_limit_per_sender | integer | 5 | Anti-spam |
recognition.default_visibility | enum | PUBLIC | PUBLIC or PRIVATE |
celebrations.kinds | array of string | birthday, anniversary, new joiner | Generated kinds |
celebrations.birthday_opt_in | boolean | true | Employee must opt in to show birthdays |
8. Screens by persona
| Persona | Web | Mobile |
|---|---|---|
| Employee | Wall (announcements, recognitions, celebrations), acknowledge, send recognition, my recognitions | Same |
| Line manager | Team recognition summary | Recognise team |
| HR manager | Announcement composer with audience preview, read and acknowledgement tracking, recognition types | — |
9. Events
| Event | Consumers |
|---|---|
eng.announcement.published | NTF |
eng.announcement.acknowledged | RPT |
eng.recognition.sent | NTF (recipient and their manager) |
eng.celebration.generated | NTF |
Consumed: emp.employee.joined (welcome post), emp.job.changed (audience accuracy).
10. API surface
| Resource | Main operations |
|---|---|
/v1/eng/announcements | CRUD, POST /:id/publish, POST /:id/stop, POST /:id/ack, GET /:id/reads |
/v1/eng/recognition-types | CRUD |
/v1/eng/recognitions | POST, GET sent and received, POST /:id/reactions |
/v1/eng/feed | GET wall |
Detailed in API endpoints.
11. Permissions
| Permission | Scopes | Default roles |
|---|---|---|
eng.announcement.manage | ORG, LOCATION | hr_manager |
eng.announcement.read | SELF | employee |
eng.recognition.create | SELF | employee |
eng.recognition_type.manage | ORG | hr_admin |
eng.report.export | ORG | hr_manager |
12. Reports
| Report | Contents | Reference |
|---|---|---|
| Recognition counts by type and employee | Sent and received | [Observed] MOB: HCM |
| Announcement reach | Audience, read, acknowledged, pending | [Proposed] |
| Recognition network | Cross-team recognition share | [Proposed] R4 |
13. Release and priority
| Capability | Release | MoSCoW |
|---|---|---|
| Announcements with audience and read receipts | R2 | Must |
| Acknowledgement tracking | R2 | Should |
| Recognition with types and wall | R2 | Should |
| Celebrations | R2 | Could |
| Reactions | R2 | Could |
14. Open questions
- Should recognitions be visible to everyone in the tenant or only within the location by default? Default is tenant-wide public.
- Do we moderate wall content (profanity filter, HR removal)? A basic filter and HR removal are proposed.