Define every field once — name, type, framework mapping, validation rules — so the same indicator means the same thing across every hospital, program, and year, without breaking historical records when it evolves.
In short: A System Administrator defines every field once in Sopact Sense — name, data type, the framework element it maps to, and validation rules — so "number of participants served" means the same thing in every program, every hospital, every year. Role-based permissions scope who sees which fields, every program's forms draw from that same shared dictionary instead of a one-off schema, and fields can evolve — renamed, rescoped, added — without breaking or reinterpreting the historical records collected under the old definition.
A System Administrator defines the organization's core data dictionary a single time in Sopact Sense: field name, data type (numeric, dropdown/categorical, narrative/qualitative, document), the framework element it maps to — a Theory of Change outcome, a Logframe indicator, an IRIS+ metric — and the validation rule that keeps entries clean. Once it exists in the dictionary, no program has to reinvent it.
Define a new field in our data dictionary: [FIELD NAME], data type [numeric / dropdown / narrative / document], mapped to [FRAMEWORK ELEMENT — e.g., Theory of Change outcome / Logframe indicator / IRIS+ metric], with validation rule [RULE]. Apply this definition across every program and hospital that uses this indicator.
Fields are scoped with role-based, granular permissions — restricted by program, hospital or entity, and data type (financial vs. narrative) — so Finance sees budget fields and Program staff see outcome fields, from the exact same dictionary. Nobody duplicates the schema per team just to control who sees what.
Scope [FIELD NAME] so only [ROLE — e.g., Finance] can see and edit it, and restrict visibility further to [PROGRAM / HOSPITAL]. Program staff should see the outcome fields for their program only, from the same shared dictionary.
Each program — grant, sponsorship, direct investment, RFP or non-RFP — pulls its intake and reporting forms from this shared dictionary instead of a one-off form. That's what makes a "housing stability" indicator collected by one hospital's program directly comparable to the same indicator collected by another hospital's program, instead of two fields that merely look alike.
Build the intake form for [PROGRAM NAME] at [HOSPITAL/ENTITY] using the fields already defined in our data dictionary — don't create new one-off fields for indicators that already exist, like [INDICATOR NAME].
When a new indicator is needed — a new compliance category, a new SROI input, a new funder requirement — the Administrator adds it to the dictionary. Configurable data workflows let a field evolve going forward — renamed, rescoped, added to a form — without breaking or reinterpreting historical records already collected under the old definition. Last year's data stays exactly what it was; only new data flows through the new definition.
Rename the field [OLD FIELD NAME] to [NEW FIELD NAME] and rescope it to include [NEW SCOPE], effective [DATE]. Keep all historical records collected under the old definition intact and correctly labeled — don't reinterpret past data under the new definition.
Sopact Intelligence Row uses the dictionary as the map for converting unstructured input — narrative responses, uploaded frameworks, PDFs — into structured, queryable fields. A grantee's free-text answer and another applicant's dropdown answer both land in the same defined field when they mean the same thing, instead of one becoming unqueryable prose and the other becoming a clean cell.
Read [UPLOADED DOCUMENT / NARRATIVE RESPONSE] and map it to the fields already defined in our data dictionary. Where the narrative answers a defined field like [FIELD NAME], populate that field — don't create a new, undefined one.
GRADE: green | Fully mapped | field has a type, a framework mapping, and a validation rule, and is correctly scoped; amber | Partially mapped | field exists but is missing a framework mapping or validation rule; red | Undefined | data is being collected under a label that isn't in the dictionary yet
Full audit logs and system activity tracking record every change to the dictionary — who added, renamed, or retired a field, and when. A compliance reviewer or auditor can trace not just the data, but the definitions behind it, back through time. That's a different, harder claim than most systems can make: most can show you what the data says today, not what a field used to mean two years ago.
API access exposes the same dictionary to finance, CRM, or data-warehouse tools, so "budget" in Sopact Sense and "budget" in a system like Workday resolve to the same underlying definition rather than requiring a manual mapping exercise for every integration. That's what makes the downstream payoff possible: the dashboards, SROI model, and compliance filings all resolve to the same field definitions used at intake. Nothing gets "translated" or reconciled between stages, because it was never a different field to begin with.
Expose our data dictionary via API so [SYSTEM — e.g., Workday, Snowflake] resolves "[FIELD NAME]" to the same definition Sopact Sense uses — no manual mapping exercise for this integration.
Lead. Don't let a program invent its own field. If an indicator already exists in the dictionary under a different name, map to it — a near-duplicate field is how "participants served" quietly becomes three different numbers across three hospitals.
Lead. Version the dictionary itself, not just the forms. Adding a new indicator or rescoping an old one should read like a changelog — what changed, when, and why — so nobody has to guess whether this year's number means the same thing as last year's.
Lead. Improve the definition, not just the one form. If a field grades Red because its dictionary entry is incomplete, fixing the form in front of you only patches one program — fix the shared definition so every program using that field inherits the correction.
A reviewer flagged [FIELD NAME] Red because its definition is incomplete — missing a framework mapping or validation rule. Update the data dictionary entry itself, not just this one form, so every program using [FIELD NAME] inherits the fix.
Lead. Let the audit trail answer the auditor's question before they ask it. Because every dictionary change is logged with who and when, "why does this field mean something different than it did in 2023" already has a documented answer — no reconstruction required.
It's a single, governed definition of every field an organization collects — its name, data type, the framework element it maps to (a Theory of Change outcome, a Logframe indicator, an IRIS+ metric), and its validation rule — used as the shared source for every program's intake and reporting forms, instead of each program defining its own schema from scratch.
In Sopact Sense, a System Administrator defines each field once with its type, framework mapping, and validation rule, scopes it by role, program, and entity, and every program's forms draw from that same shared dictionary. Sopact Intelligence Row maps unstructured narrative and document input to the same defined fields, and configurable workflows let a field evolve going forward without breaking or reinterpreting records already collected under the old definition.
Per-program spreadsheets let every team define "housing stability" or "participants served" slightly differently, so nothing is comparable across programs, hospitals, or years without a manual reconciliation step. A governed data dictionary defines each field once, centrally, so every program's forms — and every dashboard, SROI model, and compliance filing built on top of them — already resolve to the same definition with nothing to translate.
.png)
Open Sopact Sense, paste your program description, and put it to work.
Try in Sopact
