All features
Feature library
Real features from SaaS products built with CraftHQ.

Sign-in

Users & access

Customers & imports

Files

Review & records

Platform

Feature breakdown · built with CraftHQ

PlatformNotifications

Email & in-app notifications

Whole-team time at this build's pace

Estimated ~19 h

2 people incl. the product owner, requirements to merge

Estimate at this build's pace, not a measurement of this feature

Users are kept in the loop, and a single configuration setting controls whether customer-facing operational email is sent.

Size: ~23 FP · Proxy estimate; an in-house count, not independently checked. Range 13 to 28. · How we counted 23 FP

How long a feature this size usually takes

Whole-team time — this build vs a typical team

~23 FP · FP × 6.8 to 9.4 h (ISBSG 2023)

Whole-team time at this build's pace2 people incl. the product owner, requirements to merge
~19 h11 to 23 h

Estimate at this build's pace, not a measurement of this feature

A typical team, whole lifecycleRequirements to release · middle half of 512 comparable projects (Java, Agile), ISBSG 2023
~156 to 216 habout 4–5.5 person-weeksmedian ~182 h
grey band = a typical team, middle halfhatched = our whole-team estimate

Both figures are whole-team time over the whole lifecycle, so they compare like for like. Ours is this build's pace — about 0.8 hours per function point across the whole build (two people, including the product owner, with requirements and review time). The industry range is an ISBSG project-level figure applied to one feature, so it is indicative.

Workflow

How it moved through the workflow

Select a stage. The build shipped, so every stage is complete; a person approved the merge.

Request

Keep users in the loop automatically, and give the company one control over the operational mail that goes out from every point in the product, without ever blocking sign-in mail.

Questions

Two decisions went to the business before building: whether an assignment change is notified by email or in-app, and whether one configuration setting governs operational mail while security mail stays exempt.

Approved

The product owner signs off the breakdown by moving the story into the approved state, and the build runs against that reference.

Definition of ready

The questions are answered.
The acceptance criteria are testable.
The size is estimated.
The scope is checked for splitting.
The product owner has signed off.

Building

CraftHQ's build agents write the code and the tests together, run as a loop; a failing check halts the work until it passes.

Checks

Three checks run on every pull request: one on the product owner's machine as CraftHQ builds, one on the engineer's machine before review, and a code-quality scan in CI. Merging is gated by the CI check passing and a person's approval, enforced by branch protection.

Review

An engineer reviews the pull request and merges it.

Merged

The pull request is merged to main after a person approves it. Nothing merges without that approval.

Definition of done

Every acceptance criterion is checked; where a scenario has a dedicated test it is cited, and where it was verified by review that is stated.
The three checks are green.
A person approved the merge.

Breakdown

The feature breakdown

Business first, then the engineering view. Tab through it.

Overview

The gap it closes

Chasing customers by hand is slow, and mail can go out from many points in a product with no single control over it.

Who uses it

All users receive notifications; a single configuration setting controls whether customer-facing operational email is sent.

User story

As a staff member, I want customers reminded and notified of changes automatically so that work keeps moving without me chasing by hand.

Examples

Example 1

A customer has outstanding work. A reminder is sent automatically, so the staff member does not have to chase it by email.

Example 2

The delivery setting is set to suppress. Customer-facing operational mail is not sent, while one-time codes and password-reset links still go out, and in-app notices still appear.

Dependencies & risks

Depends on

A delivery service for email, mail templates, a notification store for in-app notices, and a reminder job.

Risk & mitigation

Operational mail could go out when it should not, or the control could accidentally block sign-in mail. Reduced by a single configuration setting over customer-facing operational delivery, with security mail (one-time codes, password resets) always exempt, plus a per-flow invite-suppression flag.

How it works

Simplified diagrams of the parts involved, the steps of one request, and where it runs.

Architecture

People
Any userreceives notices
Your app
Delivery settingoperational mail only
Delivery servicerenders and sends email; security mail is always sent
Notification storein-app notices
Reminder jobchases outstanding work
  • 1allow or stop operational email
  • 2send reminders
  • 3email (operational, plus security mail outside the control)
  • 4reads in-app notices
Simplified.

Sequence

Recipienta user
App serverraises an event
Configuration settingoperational mail only
Delivery servicerenders a template
Notification storein-app notices
  • 1an operational event wants to notify
  • 2allowed, so send; security mail always sends
  • 3deliver the email
  • 4write the in-app notice
  • 5read in-app notices
Simplified.

Infrastructure

Client (untrusted)
Web appthe notifications panel
Your app
App serverauthenticates, pins the tenant, raises events
Background workerreminder job and sending
Databaseper-tenant isolation, notification store
External services
Email deliveryoutbound email
  • 1read notices, set controls (authenticate + tenant check)
  • 2queue reminders and mail
  • 3write in-app notifications
  • 4send allowed operational email, and security mail always
Simplified.

Acceptance criteria

Each scenario is written as a Gherkin spec. The Engineering tab shows the test that covers each one, or notes where it was verified by review.

@platform @notifications

Feature: Email and in-app notifications

  As a staff member

  I want customers reminded and notified of changes automatically

  So that work keeps moving without me chasing by hand



  The product sends in-app notifications and emails. A single configuration setting governs customer-facing operational mail across every email site and defaults to suppress; security mail (one-time codes and password resets) always goes out, and an assignment change notifies both the old and the new owner in-app.



  Background:

    Given notifications can be sent in-app and by email



  Rule: A single configuration setting governs operational email, but never security mail



    Scenario: The setting suppresses operational mail at every email site

      Given the delivery setting is set to suppress

      When any part of the product would send a customer-facing operational email

      Then no operational email is sent from any email site



    Scenario: Security mail is sent even when operational mail is suppressed

      Given the delivery setting is set to suppress

      When a user needs a one-time code or a password-reset link

      Then that security mail is still sent

      And the user is not locked out



    Scenario: In-app notices still appear when operational mail is suppressed

      Given the delivery setting is set to suppress

      When an event raises an in-app notice

      Then the recipient still sees it in the in-app panel



  Rule: An assignment change notifies both owners in-app



    Scenario: A reassignment notifies the old and the new owner

      Given an item is reassigned from one owner to another

      When the assignment changes

      Then an in-app notification goes to the old owner

      And an in-app notification goes to the new owner



  Rule: Reminders and invites are sent, with limits



    Scenario: A reminder is sent for outstanding work and stops on completion

      Given a customer has outstanding work

      When the reminder runs

      Then the customer is reminded

      And no further reminder is sent once the work is complete



    Scenario: Invites are suppressed by a per-flow configuration flag

      Given the invite-suppression flag is set

      When a user would be invited by email

      Then the invite email is not sent

    @edge-cases



    Scenario Outline: Where each notification is delivered

      Given a "<event>" occurs

      When notifications are sent

      Then the delivery is "<channel>"

      Examples:

        | event | channel |

        | an assignment change | in-app only |

        | a customer invite | email |

        | a reminder | email |

        | a one-time code | email |

Questions

Questions raised in planning, each with the decision taken.

Should an assignment change be notified by email or in-app?

Assignment changes happen often, so email could flood inboxes; an in-app notice reaches the owners without the noise.

AIn-app only, to both the old and the new owner. · recommended
BBy email as well as in-app.
Decided: In-app only (option A).

Should there be one configuration setting over all outgoing mail, and does it also stop sign-in mail?

Mail is sent from many points in the product. One control is useful, but if it also stopped one-time codes and reset links, setting it to suppress would lock every user out.

AYes to one configuration setting over operational mail; security mail (codes, resets) is always sent, independently of it. · recommended
BOne control over everything, including sign-in mail.
Decided: One configuration setting over operational mail; security mail is exempt (option A).

How we sized it

A function point measures what the software does — its inputs, outputs, lookups and the data it stores — regardless of language or how many lines it took. Each counted item is weighted by complexity: a user input counts 3–6 points, an output or report 4–7, a lookup 3–6, data the feature owns 7–10, and data read from elsewhere 5–7.

  • The notification store this feature owns
    Data the feature owns
    10
  • Send an email
    Output or report
    5
  • Set delivery controls across the product
    User input
    4
  • Show in-app notifications
    Lookup
    4
  • Total
    23
23 function points (range 13–28). IFPUG-style count: each user action, lookup, output and stored data set, weighted by complexity. Technical plumbing is excluded, and a data store is counted once in the feature that owns it.

Components touched

Delivery service

Sends email through one service. A single configuration setting governs customer-facing operational mail across every email site; security mail (one-time codes, password resets) is always sent, independently of it, so the setting cannot lock users out.

Mail templates

The templates for invites, reminders and change notices.

Notification store

Holds in-app notifications, including the assignment-changed event to both owners. In-app notices are delivered from the store and are not affected by the email configuration setting.

Reminder job

A background job that reminds customers of outstanding work and stops once the work is complete.

Invite-suppression flag

A configuration flag that stops invite emails when set.

Data touched

Notification storewrite

In-app notifications and their read state.

Mail templatesread

The templates the delivery service renders.

Delivery settingread

The configuration setting (operational mail only) and the invite-suppression flag.

Security decisions

  • A single configuration setting governs customer-facing operational email across every email site, so it can be stopped in one place.
  • Security mail (one-time codes, password resets) is always sent, independently of the configuration setting, so the switch can never lock a user out of signing in.
  • An invite-suppression flag prevents invite emails when set.

Subtasks

  • A delivery service with one configuration setting over operational mail and an always-on path for security mail.
  • Mail templates for invites, reminders and change notices.
  • A notification store with the assignment-changed event to both owners.
  • An invite-suppression configuration flag.

How each scenario is verified

  • Notifications are sent in-app and by email
    Verified by review of the notification delivery path.
  • The configuration setting stops operational mail but not security mail
    A test that the configuration setting stops operational mail across email sites while one-time codes and resets still go out.
  • A reminder is sent for outstanding work and stops on completion
    Verified by review of the reminder path.
  • Invites are suppressed by a flag
    A test over the configuration setting and the enqueue gate.

Notes

  • An assignment change is notified in-app only (a product decision), so routine changes do not go out by email.

Risk tier

Logic A person approves every merge. This is a Logic-tier change; it carries automated tests for its rules.

Start here

Want this on your backlog?

Get a free baseline report on one repository, or scope a 3-month pilot measured against what your team’s work costs today.

Measured from your own git history
Every pull request tested before review
A person approves every merge
Get a baseline reportScope a 3-month pilot
Next feature: In-app help tips →All features