Feature breakdown · built with CraftHQ
Organisation profile & authorised contacts
Whole-team time at this build's pace
2 people incl. the product owner, requirements to merge
Estimate at this build's pace, not a measurement of this feature
Key contacts are captured once on the organisation profile and reused everywhere, instead of being re-keyed by whoever is signed in.
How long a feature this size usually takes
Whole-team time — this build vs a typical team
12 FP · FP × 6.8 to 9.4 h (ISBSG 2023)
Estimate at this build's pace, not a measurement of this feature
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
Capture the organisation's authorised contacts once on the profile, so every document or form uses the real contact instead of one re-keyed by whoever is signed in.
Questions
Two decisions went to the business before building: where the contact comes from, and whether and when the fields are mandatory.
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
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
Breakdown
The feature breakdown
Business first, then the engineering view. Tab through it.
Overview
The gap it closes
If each document or form captures its own contact, the same person is re-keyed again and again, and the versions drift apart.
Who uses it
The profile sits on the customer's own record. The customer's active mapped owner captures and confirms its contacts; an administrator reaches the route but is refused unless they are that mapped owner, and other staff roles see it read-only. Every downstream document or form then reads the contacts.
User story
As a staff member, I want the organisation profile to carry its authorised contacts so that any document or form uses the organisation's real contact, filled in once.
Examples
Example 1
A staff member sets the authorised contact once on the profile. A downstream form then shows that contact read-only, with a link back to the profile to change it.
Example 2
A profile contact is changed after a form that used it has been finalised. The finalised form keeps the contact as it was at finalisation; only drafts and later forms pick up the new value, so a past record is never rewritten.
Dependencies & risks
Depends on
The organisation profile and the downstream forms that bind to it.
Risk & mitigation
A live binding could rewrite a finalised document when the profile later changes. Reduced by snapshotting the contact into a form at finalisation; only drafts read the live profile.
How it works
Simplified diagrams of the parts involved, the steps of one request, and where it runs.
Architecture
- 1capture once
- 2save the contact
- 3read read-only
- 4record a reveal
Sequence
- 1save the contact on the profile
- 2store the structured fields
- 3open a downstream form
- 4read the contact
- 5the contact shown read-only
Infrastructure
- 1save and read the contact
- 2read and write the profile
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.
@customers @profileFeature: Organisation profile and authorised contactsAs a staff memberI want the customer's profile to carry its authorised contactsSo that any document or form uses the organisation's real contact, filled in onceThe customer's profile carries its authorised contacts, captured once and reused everywhere, instead of being re-keyed by whoever is signed in. The active mapped owner writes the profile; other staff see it read-only.Background:Given a customer's profile existsRule: Contacts are captured once on the profile and reused everywhereScenario: A downstream form uses the profile contactGiven an authorised contact is set on the profileWhen a downstream form is openedThen it shows that contact read-onlyAnd a link leads back to the profile to edit itRule: Core contact fields are required only when the profile is confirmedScenario: A draft is never blocked by a missing contact fieldGiven a contact field has not been capturedWhen the profile is saved as a draftThen the missing field shows a muted "not captured" noteAnd the draft is not blockedScenario: Confirming the profile requires the core contact fieldsGiven a core contact field is missingWhen a staff member confirms the profileThen the confirm is blocked until the core fields are filledRule: Sensitive contact details are masked, and only a permitted role may reveal themScenario: Revealing a masked contact is recordedGiven a contact's phone and email are maskedAnd a staff member has the reveal permissionWhen they reveal the contactThen the full values are shownAnd the reveal is written to the audit logScenario: A user without the reveal permission cannot unmaskGiven a staff member does not have the reveal permissionWhen they open the contactThen the phone and email stay maskedRule: A finalised form keeps the contact it was finalised withScenario: A later profile change does not rewrite a finalised formGiven a form was finalised using the profile's authorised contactWhen the profile contact is later changedThen the finalised form keeps the contact as it was at finalisationAnd only drafts and later forms show the new contact@edge-casesScenario Outline: Contact fields at confirmGiven a "<field>" is "<state>"When the profile is confirmedThen the result is "<result>"Examples:| field | state | result || core name | present | confirm allowed || core name | missing | confirm blocked || second-language name | missing | confirm allowed |
Questions
Questions raised in planning, each with the decision taken.
Should a document's contact come from the signed-in user, or from the organisation profile?
Taking the contact from whoever is signed in means it changes with the person; taking it from the profile keeps one real contact for the organisation.
Should the contact fields be mandatory?
Making them always mandatory blocks drafts; never requiring them lets an incomplete profile be confirmed.
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.
- Capture an authorised contactUser input4
- Edit or draft the contactUser input4
- Downstream forms read the contact from the profileLookup4
- Total12
Components touched
Structured contact fields
Name fields including an optional second-language name, a country code, a phone and an email, added as nullable columns in one additive change.
Downstream binding and snapshot
A draft form reads the contact live and read-only from the profile; at finalisation the contact is snapshotted into the form, so a later profile change never rewrites a finalised record.
Masked reveal
Phone and email are masked on screen by default; only a role holding the reveal permission can unmask them. A reveal auto-hides after 60 seconds and writes an audit row.
Write access
Saving, confirming, uploading or extracting on the profile is limited to the customer's active mapped owner; other roles, including administrators, are read-only.
Confirm gate
Requires the core fields only when the profile is confirmed; a draft is never blocked.
Data touched
Organisation profilewrite
Holds the structured contact fields, added as nullable columns.
Downstream formsread
Read the contact read-only from the profile.
Audit logappend
Records a reveal of a masked contact.
Security decisions
- Phone and email are masked on screen; only a role holding the reveal permission can unmask them, the reveal auto-hides after 60 seconds, and it writes an audit row.
- Saving, confirming, uploading or extracting on the profile is limited to the customer's active mapped owner; an administrator is refused unless they are that mapped owner, and other staff roles are view-only.
- A finalised form keeps a snapshot of the contact, so a later profile change cannot rewrite a past record.
- Core fields are required only at confirm, so a draft is never forced to carry contact data before it is ready.
Subtasks
- Add the structured contact fields as nullable columns.
- Keep a full name in sync for the downstream binding.
- Mask phone and email, with an audited reveal.
- Require core fields at confirm only; never block a draft.
How each scenario is verified
- A downstream form uses the profile contactTest that a downstream form reads the authorised contact from the profile.
- Confirming the profile requires the core contact fieldsTest over the confirm gate requiring the core fields.
- A draft is never blocked by a missing contact fieldTest that a draft saves with a missing field shown as not captured.
- Revealing a masked contact is recordedTest that a reveal of a masked contact writes an audit record.
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.