> For the complete documentation index, see [llms.txt](https://support.pears.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.pears.io/engage/partners/migrate-from-legacy/mapping-reference.md). # Mapping Reference What each legacy Partnership and Coalition field becomes in the Partners module, and what is deliberately left behind. This page describes what becomes what. The first sections apply to both legacy modules; the later ones cover what is unique to Partnerships and to Coalitions. ## How Legacy Records Are Grouped into Partners Records are collapsed into a Partner by a grouping key: * **Partnerships** — partnership name + primary site. The name is trimmed and compared without regard to capitalization, so the same partnership retyped with different capitalization still collapses into one Partner. * **Coalitions** — coalition name + organization. Coalitions have no site, so the site half of the key falls back to the organization the record was reported in. Every record sharing a key becomes one Partner, and each of those records becomes one Partner Report on it. **Where the Partner's own values come from.** A Partner has one name, one type, one site, one unit, and one comments field — but it may be built from four or five legacy records that disagree. The rule is that the **most recent record wins**, where "most recent" means the record covering the latest reporting period, not the record with the highest ID. A record for an older period can be created at any time — a late backfill, a bulk reporting-period edit — so record order alone would be misleading. Record ID only breaks ties between records ending on the same day. ## Start and End Dates Neither legacy module has a start or end date, so both are derived. * **Start date** is the start date of the earliest reporting period on any record in the group. * **End date** is left blank — meaning the partnership is ongoing — unless the partner appears to have lapsed. A Partner is treated as ended when its last recorded reporting period is followed by **two or more finished reporting periods** with no record of its own. The end date is then that last recorded period's end date. {% hint style="info" %} **TIP:** One missed period reads as a reporting gap rather than the end of a relationship — usually it just means the report is not done yet. Reporting periods that are still running, or have not started, are never counted toward the gap. {% endhint %} ## Partner Data One row per Partner. Values come from the most recent record in the group unless noted. | Legacy field | Workbook column | Becomes | Notes | | ---------------------------- | -------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Partnership / Coalition name | `partner_name` | Partner name | — | | Reported by (owner) | `reported_by_email` | Partner owner | If blank — the original owner was deleted — ownership falls to the person running the import. | | Type of Partnership | `partner_type` | Partner type | Coalitions have no type of their own; see [Partner type is inferred from the members](#partner-type-is-inferred-from-the-members). | | Please specify other type | `partner_type_other` | Partner type, other | Cleared on import unless the type is actually **Other**. | | *(derived)* | `start_date` | Start date | See [Start and End Dates](#start-and-end-dates). | | *(derived)* | `end_date` | End date | Blank means ongoing. | | Primary site or organization | `site_id` | Site | Coalitions use the placeholder site. | | Unit | `unit` | Owning unit | The Partner's permission-governing unit, distinct from each report's **Responsible Unit**. | | Comments | `comments` | Comments | Rich text is converted to plain text with light markdown formatting. | ## Partner Report Data One row per legacy record — this is the sheet that preserves the year-by-year history. | Legacy field | Workbook column | Becomes | Notes | | ----------------------------- | ------------------------------- | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Reporting periods | `reporting_period_ids` | Reporting periods | Past periods are accepted; importing history is the point. | | Program areas | `program_areas` | Program areas | Both current and past program areas are accepted. | | Unit | `unit` | Responsible Unit | Each record's own unit, not the Partner's. Records from different units on the same partner import as separately attributed reports. **Required.** | | Reported by | `reported_by_email` | Report owner | Falls back to the importing user if blank. | | Jurisdiction level | `jurisdiction_level` | Jurisdiction level | — | | Depth of relationship | `relationship_depth` | Depth of relationship | May be blank. A report with no depth imports fine but cannot be marked complete until someone fills it in. | | Intervention types + Comments | `comments` | Comments | The three intervention-type checkboxes and the record's comments are combined into one labeled block of text. | | *(derived)* | `has_assessments_to_report` | Assessments prerequisite | `1` when the record actually produced assessment rows. | | *(derived)* | `has_accomplishments_to_report` | Accomplishments prerequisite | `1` when the record has an accomplishment or a lesson. | ## Partner Activities and Report Activities Activities live on the Partner, and each one is then selected onto the report of the record it came from. Two legacy things become activities: | Legacy source | Activity type | Date | What goes in the notes | | ------------------------------------------------------------------------------------- | ------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Each **Meetings & Events** row | Meeting | The meeting's own date and time, converted to the exporting user's time zone | Meeting or event name, purpose(s), other purpose, number in attendance, and notes & accomplishments — each under its own heading | | Assistance received and provided (one per legacy record that recorded any assistance) | Contribution | The start of the record's earliest reporting period, because assistance carries no date of its own | Assistance received, other assistance received, assistance provided, other assistance provided | {% hint style="warning" %} **NOTE:** The legacy modules drew no distinction between a meeting and an event, so everything imports as a **Meeting**. If the distinction matters to you, change the `activity_type` cell to `event` in the workbook before importing. {% endhint %} {% hint style="warning" %} **NOTE:** An activity is only attached to a report when its date falls inside that report's reporting periods. An out-of-period meeting is still created on the Partner, but the link to the report is skipped rather than forced. {% endhint %} ## Report Assessments Partnerships have one assessment tool and result; coalitions have two. Each produces a row. * The legacy tool is matched by name against the list the Partner Reports assessment section accepts. A match carries straight over. * When there is no equivalent — most often for coalition-specific tools — the row falls back to the list's **Other** entry, and the original tool name is carried across in `assessment_tool_other`, so nothing is lost. * A legacy selection of **None** produces no row at all. * The assessment date is set to the start of the record's earliest reporting period, since the legacy evaluation carries no date. * `result` is **required**. If the legacy evaluation had no result text, the cell is blank and must be filled in before the import will succeed. ## Report Accomplishments and Lessons The new module has a single table with a type column where the legacy modules had two separate fields. * Accomplishments become a row with type `accomplishment`. * Lessons learned become a row with type `lesson`. **Partnerships only** — coalitions have no lessons-learned field. * The date is left blank; legacy records did not capture one. ## Report Action Plans Each action plan linked to a legacy record produces a link between the plan and the Partner, plus a selection of that link onto the report. * The legacy "no action plan" placeholder is skipped — the new module expresses "none" as no link at all. * A plan has to cover one of the report's reporting periods. If it does not, that row fails with a cell error rather than importing something the interface would not allow. ## Partner Sharing and Partner Uploads **Sharing.** Each legacy collaborator becomes a [sharing grant](/engage/partners/partner-permissions.md) on the Partner, carrying the same view or edit access. Because the same collaborator was re-added to every year's record, grants are deduplicated — one per person per Partner. The record owner's own automatic collaborator row is skipped on import, since owners hold full access anyway. **Uploads.** Files attached to legacy records are duplicated onto the new Partner. The originals stay attached to the Partnership or Coalition record, so nothing is moved out from under the legacy module. The same file attached to two years' records produces one copy, not two. Attachments move to the Partner, not to individual reports. ## Labeled Blocks Partners has fewer structured fields than the legacy modules in a few places, so several legacy fields are combined into one free-text column. Rather than running them together, the export writes them as labeled blocks, so where each value came from is still legible after the migration: ``` Assistance Received: - Funding - Volunteers Other Assistance Provided: Shared meeting space on Tuesdays ``` A block whose value is empty is left out entirely, so you will not see empty headings. This pattern is used for report comments, activity notes, and coalition-member notes. ## Partnerships Only — Links to Other Modules Legacy Partnership records could be attached to records in four other modules. Those attachments are recreated as [Partner links](/getting-started/getting-started/add-partners.md), each on its own worksheet. | Worksheet | Recreates the link to | | ------------------------------ | --------------------- | | **PSE Partners** | PSE Site Activities | | **Program Activity Partners** | Program Activities | | **Success Story Partners** | Success Stories | | **Indirect Activity Partners** | Indirect Activities | Two behaviors are worth knowing: * **Duplicates are merged.** Several years' records collapse into one Partner, so the same PSE Site Activity could be linked from three of them. The new structure holds one link per Partner and host record, so those rows are merged: the contributions from all of them are combined, and free-text "other" contributions are joined with semicolons in the order they were first written. * **Empty sheets are hidden.** If your organization never linked partnerships to success stories, that sheet is simply absent from the workbook. Coalitions had no equivalent attachments, so Coalition workbooks carry none of these sheets. ## Coalitions Only Coalitions share every sheet described above except the Partnerships-only link sheets, with four differences and two extra worksheets. ### Coalitions Have No Site Every Partner is required to have a site, and coalitions never had one. Coalition-derived Partners are therefore attached to a per-organization placeholder site named **Dummy Site**, which the export creates for your organization if it does not already exist. It is created only for organizations that actually migrate coalitions. This also affects grouping: since there is no site to group by, coalition records are grouped by name within the organization. ### Partner Type Is Inferred from the Members A coalition has no type of its own, but a Partner must have one. The type is inferred from the members of the most recent record: * **All members share one type** (and it is not **Other**) — that type carries straight over, with no "specify other" text. * **Members have a mix of types, no types at all, or only Other** — the Partner type is set to **Other**, and the "specify other" text reads "Imported Coalition with N partner types". {% hint style="info" %} **TIP:** This is one of the most likely things to want to change during review. The value is in the `partner_type` and `partner_type_other` columns on the **Partner Data** sheet and is safe to edit, as long as the replacement matches a type on your list. {% endhint %} ### Two Assessment Tools Instead of One Coalitions record two evaluations — the active engagement assessment and the SNAP-Ed influence assessment. Each becomes its own row on the **Report Assessments** sheet. Because the coalition assessment list and the partnership assessment list are separate, coalition-specific tools are the most common case of a tool falling back to **Other** with its original name preserved. ### Coalition Members Become CRM Contacts This is the largest structural difference. Coalition members have no equivalent in Partners; they become [contacts in the CRM](/engage/community-relationships/add-a-contact.md), linked to the new Partner. Members are deduplicated the same way Partners are — on member name plus member site within the Partner — so a member re-entered on every year's record becomes one contact, not five. | Legacy member field | Workbook column | Becomes | | --------------------------------------- | --------------------------------- | ------------------------------------------ | | Name of the Coalition Member | `name` | Contact name | | Member's site name | `external_organization_name` | The contact's organization, as free text | | Member's site address, city, state, ZIP | `address`, `city`, `state`, `zip` | The contact's address fields, as free text | | The coalition's unit | `unit` | The contact's owning unit | {% hint style="warning" %} **NOTE:** The member's site travels across as a name and address in text, not as a link to the Site record. The CRM's site link is deprecated in favor of those free-text columns, so this is the intended shape rather than a loss of fidelity — but it does mean the contact is not connected to the Site record in PEARS. {% endhint %} ### The Rest of the Member's Details Become an Internal Note Everything else recorded about a member is rolled into a single [interaction](/engage/community-relationships/create-an-interaction.md) on the contact, on the **Contact Interactions** sheet: * **What goes in:** sector of influence, other sector of influence, type of member, other type of member, and role and resources — each under its own heading. * **Type:** the interaction is filed as an **Internal use only** note, so it does not read as an actual conversation with the contact. * **Date:** the start of the earliest reporting period on the coalition record it came from, since a member carries no date of its own. * **Reporting periods:** the periods of the coalition record it was derived from — not whichever periods happen to be open when the import runs. Back-dated notes stay in the right bucket. * **Links:** the interaction is attached to both the contact and the Partner, so it counts in the Partner Report's contact-interaction statistics. A member with nothing recorded beyond a name produces no interaction row. ## What Does Not Carry Over Some legacy fields have no home in the Partners module and are deliberately left behind. The legacy records keep them, so nothing is destroyed — but they will not appear on the new Partner. | Not migrated | Why | | ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Custom data / custom fields | The new module's custom data is configured separately. | | **Complete** and **Verified** flags | The new reports have their own completion rules, which depend on fields the legacy records may not have filled in. | | COVID-19 / crisis impact | No equivalent field. | | "Receives SNAP-Ed funding" (Partnerships) and "Is a SNAC" (Coalitions) | No equivalent field. | | Copied-from lineage | The copy relationship between legacy records is not meaningful once they are collapsed into one Partner. | | Collaborator "is a contributor" flag and contribution description | Sharing grants carry the person and the access level only. | | Number in attendance as a structured field | Preserved, but inside the activity's notes rather than as its own column. | | The meeting / event distinction | The legacy module did not draw one; everything becomes a **Meeting**. | | The coalition member's site as a linked Site record | It becomes name and address text on the contact. | | Assessment tools recorded as **None** | The new module expresses "none" as no assessment row. | | The "no action plan" placeholder | Expressed as no link at all. |