How should you structure stakeholder data?
Start by naming who or what you follow, what each observation records, and how the records relate across time. A person, an assessment response and a program enrollment are different things. Keep those distinctions clear before deciding what a row in a form or report should contain.
Use this reference when your course asks you to connect people, organizations and recurring evidence. Choose the pattern relevant to your question; you do not need to complete a separate course or adopt every pattern. You will produce a small record map to test before building a form.
The four patterns below are a teaching framework, not an exhaustive list of database designs. They help program, research, customer-experience and partner teams describe their requirements without needing to begin with technical terminology.
Four common patterns
| Pattern | Main question | Keep distinct |
|---|---|---|
| A · One person over time | What changed for this person? | Person, enrollment and dated observations |
| B · Several contributors | Who observed what about the same subject? | Subject, response, role and assessment round |
| C · Multiple programs | What can we report across programs? | People, programs, enrollments and measure definitions |
| D · Partner network | What did each partner report this period? | Partner, submitter, period and submission version |
These patterns can coexist. An organization may follow individuals over time, collect feedback from several people about them, and report across a partner network. Choosing a main reporting question helps you start; it does not mean every other entity must be flattened into a single record.
Separate the person from the observation
A person record identifies the person within the authorized workflow. An observation records something at a particular time: an assessment, check-in, attendance event or outcome. One person can have many observations. Each observation needs enough context to explain what it means.
For example, a satisfaction score without a date, question version or service context can be difficult to compare. Keeping it on the right contact is necessary for an individual history, but it does not settle whether two scores measure the same thing.
Before collecting, complete three sentences:
- We follow a person, organization, program, event or another defined entity.
- Each new observation describes a specific activity, response or reporting period.
- The observation connects to its subject through a documented identifier or relationship rule.
Do not use a name alone as proof that two records describe the same person. Names can change or be shared. Define how new records are matched, how uncertainty is flagged and how a mistaken link is corrected. Collect only the identity information needed for the agreed purpose.
Pattern A: follow one person over time
A training team may want to connect application, attendance, completion and later employment check-ins. A service team may need intake, support notes and follow-up. The continuing person record provides a route through the history; each event still needs its own date and meaning.
Test a participant who joins two programs, changes contact details and misses one follow-up. Can the team identify the two enrollments without creating a duplicate person? Does a missing response remain unknown rather than becoming a negative outcome? Can staff distinguish when an event happened from when someone entered it?
The main checks are identity, comparability and reproducibility. Continue later with following people across years and analyzing longitudinal data.
Pattern B: several people describe one person
A leadership program may collect self, manager and peer feedback about the same participant. A support service may receive observations from staff and family members. The subject of a response is not necessarily the respondent.
Record the subject, assessment round and respondent role as appropriate to the design. Where respondent identity is retained, separate it from the information readers are permitted to see. An identified confidential response is not an anonymous response. Do not promise anonymity if the system or context can identify the contributor.
Test two peers and a manager describing the same participant. Their responses should remain distinct, even when a report compares role groups. An average should not erase disagreement. Small groups and detailed quotations need disclosure review because a role or described event may reveal the contributor.
Use the multi-rater lesson for this pattern and the AI-access lesson before allowing retrieval of sensitive comments.
Pattern C: report across multiple programs
A program record and a participant record answer different questions. One person may attend more than one program, while each program has many participants. Preserve those relationships and the definitions used in each program instead of assuming similarly named fields are equivalent.
The King Center’s published customer story describes bringing pre- and post-survey evidence into one analyzed view across seven programs. It illustrates the operational value of organizing feedback across programs. It does not establish that every program used identical measures or that combining the data proves causal impact.
For your own workflow, test a person enrolled in two programs. A program-level participation report may count two enrollments; an organization-level reach report may count one distinct person. Label the unit and reconcile the difference. Neither total is automatically wrong.
Continue with reporting across programs. Agree shared definitions before interpreting a combined result.
Pattern D: a network of partner organizations
A network may collect recurring member returns while allowing each partner to see its own submissions. Agree a small shared core for the intended comparison, while preserving useful local questions and other evidence sources. One identical questionnaire is not a prerequisite. The organization record, reporting period, submitter and local program are separate concepts. Several people can submit on behalf of one partner, and one person may work with more than one organization.
Test two authorized users from the same partner and one from a different partner. Check which submissions each can view, edit and export. Then test the network-level report: does it distinguish missing submissions from zero activity, and comparable measures from local-only measures?
Decide coverage from the operational or research question. Collecting a return from every partner may be appropriate for accountability, but an invitation to everyone still does not guarantee a complete response. Do not label a sample invalid merely because it is smaller than the full network.
Continue with member-network collection. The offline collection lesson addresses another practical constraint when contributors cannot reliably connect.
Practice: map a partner update
Use fictional Partner P-024. The Q3 form reports 40 completions, the attendance file has 42 rows, the financial attachment is labeled Q2, and a transcript mentions transport problems. Start by mapping what each source describes—not by putting every value into the partner’s name field or assuming each row is a different person.
| Record | What it represents | Context to retain |
|---|---|---|
| Partner | The organization supplying evidence | Partner ID and approved organization details |
| Quarterly submission | One return for a reporting period | Partner ID, Q3, submitter, version and review status |
| Attendance evidence | Source rows whose unit must be checked | Program, dates, source file and person/event identifiers if authorized |
| Financial document | An uploaded report with its own period | Source ID, Q2 label, upload date and mismatch review |
| Transcript | A conversation offered as supporting context | Partner, conversation date, permission and cited passage |
The Q2 document can remain attached to the partner while being marked outside the Q3 financial-report requirement. Its arrival date should not overwrite its reporting period. The attendance file may contain visits or repeated entries; inspect its unit before comparing 42 rows with 40 people completing.
Now add a second quarter and a second submitter. The partner remains P-024; the submission and reporting period change. Ask a colleague to find the approved Q3 version without knowing which staff member uploaded it. That is the test of the structure.
What if a person belongs to several programs?
Use a relationship record when the relationship has its own meaning. Enrollment can connect a person to a program and retain start date, exit date, status and cohort. A single “program” field on the person may be insufficient when several enrollments overlap or change over time.
This is a common many-to-many modeling problem. Microsoft’s database guidance describes using a junction table to represent such relationships. You do not need to implement SQL to use the principle: tell the system designer that the relationship itself needs to be recorded and tested.
The same reasoning applies to raters, partner memberships and service assignments. Choose the level of detail needed for the work. Do not retain sensitive identities merely because the model can store them, and do not discard a necessary relationship because one flat spreadsheet is easier to draw.
Five questions to test before building the form
- What does one row mean? Identify whether it is a person, response, event, enrollment or submission.
- Can the relationship repeat? Test more than one program, quarter, rater or authorized submitter.
- Which dates matter? Separate event time, reporting period, submission time and correction time where relevant.
- Who can see what? Test the subject, contributor, local manager and central reviewer separately.
- What will the report count? Distinguish people, enrollments, responses, events and organizations.
Use a few deliberately difficult sample records: a duplicate contact, a repeated submission, an incomplete date and a changed relationship. Save the expected result for each test. This makes a product demonstration or configuration review specific enough to learn from.
If the structure fails, revise it before scaling collection. Existing data can sometimes be linked or reorganized with adequate identifiers and provenance; it is not true that identity can never be repaired later. But reconstruction has limits, and uncertain matches must not be presented as facts.
Use this planning prompt
Help us map records for [workflow and decision]. From the supplied forms and example files, list the entities, observations and relationships. State what one row means in each source. Identify candidate IDs, dates, reporting periods and repeat relationships, but do not assume matching names identify the same person. Flag ambiguous units, missing links and access questions. Propose a small test set with expected outcomes. Do not invent source fields or claim the model guarantees anonymity.
Review the proposed map with staff who collect and use the data. In a configured Sopact workflow, test the actual contact, submission and analysis records against this map. The valuable result is a structure the team can explain, not a complex diagram nobody maintains.
Watch the connected-record explainer
Watch the video · 2 minutes 34 seconds. See why responses, comments and files need their record context. Use this lesson’s worksheet to translate the idea into your own entities and relationships. Browse the video library.
Frequently asked questions
What does “record shape” mean in this lesson?
It describes what the workflow follows and how observations relate to it: one person over time, several contributors describing a person, multiple programs, or a partner network. It is a planning framework, not a formal database standard.
Is a person record the same as a survey response?
No. A person can have many responses or events. A response needs its own context, such as date, question version and reporting period, even when it is linked to a continuing person record.
Can we use more than one pattern?
Yes. Preserve the relevant entities and relationships. For example, people can join multiple programs and receive observations from several contributors. The main reporting question helps prioritize the design, not eliminate the other records.
Should raters be stored only as attributes?
Not necessarily. Where the approved design requires it, retain distinct responses and appropriate relationships to subjects, roles and assessment rounds. Decide separately whether contributor identity is collected or disclosed.
How do we avoid double counting across programs?
Define whether the report counts distinct people, enrollments or events. Preserve the links needed to calculate each unit and explain why an organization-level person count may differ from summed program participation.
Can we change the structure after collecting data?
Sometimes, with adequate identifiers, source context and a controlled migration. Test reconciliation and retain uncertain matches for review. Earlier planning reduces reconstruction work, but not every change requires rebuilding everything.
Does linking records guarantee anonymity?
No. A linked record may be identifiable, even without a displayed name. Define the collection purpose, access and disclosure rules, and distinguish anonymity from confidentiality before promising either.
What should this lesson produce?
A short record map showing the entities, observation units, identifiers, repeat relationships, relevant dates, access questions and expected report counts. Test it with a few realistic edge cases before scaling collection.
Related practice: manage question changes
Bring your record map to the related lesson on question changes and versioning. You will decide which changes preserve comparability and which need a new version or a break in the series.
Lesson reviewed September 12, 2026. Partner P-024 and the practice records are fictional. The King Center reference is drawn from its published Sopact customer story.