⚿ NPS-GMP · INTEGRATION MODULE · COMPANION TO BA PROGRAMME · TRAINING USE ONLY
∫
Integration Data Mapping
Nexus BA Programme — Companion Module
Companion Module · NPS-GMP-INT-001

When two systems
need to talk

You have analysed the business problem, written the requirements, and designed the process. Now the BA's job gets technical — specifying exactly how data moves between systems, what transforms it, and what happens when something goes wrong.

CITIZENCONNECT → GRANTRACK GRANTRACK → FINLEDGER 4 WEEKS DATA MAPPING INTEGRATION STORIES
Why this module exists
Integration is where requirements go to die — unless the BA gets it right

Most BA training teaches you how to gather requirements from humans. Integration projects are different. When GranTrack needs to send payment data to FinLedger, there is no user to interview. The "stakeholder" is a system. The "requirement" is a field. And if the BA doesn't document exactly what that field contains, where it comes from, and how it's transformed — the developer guesses, the integration breaks, and 3,200 applicants don't get their grants processed correctly.

This module covers four things every BA on an integration project must be able to do: understand why integration exists as a business solution, read and write a canonical model, produce a complete data mapping document, and write integration user stories that actually specify the right behaviour.

The three logic types — the foundation of everything
Logic Type 1
Copy Value from Source
The source field value is written into the target field exactly as it is. No change, no calculation, no conversion.
applicant_email → email_address
Same value. Different field name. Direct copy.
Logic Type 2
Set to Fixed Value
The target field always receives the same hardcoded value. It does not come from any source field — it is a system default.
application_status → always "RECEIVED"
No source field. Always the same.
Logic Type 3
Special Logic
A transformation is applied — concatenation, conditional logic, value conversion, date formatting, or derivation from multiple fields.
OFFICE_CODE + '-' + GRANT_REF + '-' + SEQ
Three fields become one composite key.
The integration landscape — Nexus
Three systems. Two integrations. One BA.

On the Nexus programme, data flows between three systems. Your job is to specify every field at every handoff point.

Citizen-facing
CitizenConnect
Public portal
Week 1–2 →
Case management
GranTrack
Nexus core system
Week 3–4 →
Financial
FinLedger
Payment processing
Programme context In the main Nexus BA Programme, you identified that the manual re-keying between GranTrack and FinLedger adds 8–12 days to every approved application and consumes approximately 18,000 staff hours per year. This module is how you specify the integration that eliminates that delay — at the field level, with transformation rules, with acceptance criteria.
4-week programme arc
What you will learn — and produce
WeekThemeKey conceptsDeliverable
W01Why integration? Concepts & architectureHub architecture, canonical model, why a BA owns thisIntegration context document
W02The canonical model & field definitionsWhat the canonical model is, field presence, defining fields preciselyCanonical field definitions for GRANT_APPLICATION
W03Data mapping — all three logic typesCopy / Fixed / Special, transformation rules, the mapping documentComplete data mapping for CitizenConnect → GranTrack
W04Integration stories & change controlEvent-driven stories, happy/unhappy/error paths, version controlIntegration user stories with full acceptance criteria
SELECT WEEK
🔐 ENTER WEEK CODE:
🔐

Teacher Dashboard

Enter the facilitator password to access session guides, week codes, and character notes.

Incorrect password.

Facilitator Dashboard

Integration Data Mapping Module · Companion to Nexus BA Programme · Zoom · 90-min sessions

All week unlock codes

NPS-GMP-INT-001 · Integration Data Mapping Module · Companion to Nexus BA Programme · Fictional Scenario · Training Use Only