If you’re moving from another system, you can import your existing memberships rather than recreating them by hand. Each row in your file becomes one membership, linked to contacts (and optionally a payment) that you import too.

Before you start

  • You need importer:execute:import to run an import, and memberships:read:memberships to check the results. See the permission catalogue.
  • Create your membership types first. Each row names its type, and a row whose type doesn’t exist fails.
  • Your file needs an ID for each membership, and the source system’s IDs for its payer and members. If the memberships were paid by one-off payments, include each payment’s ID too.
  • Only free and one-off memberships can be imported. A row with no payment that can be matched is imported as a Free membership. To link a recurring payment, edit or recreate the membership afterwards.

New to the importer? Read Run an import first.

Import memberships with their contacts

  1. Open Data In and Out → Upload a file and upload your file.
  2. Under What to import, select Memberships and Contacts. Select Payments too if your rows reference one-off payments. Memberships are processed after contacts and payments, so they can be linked.

  3. Map the membership fields:

    Field What to map
    External Key Required. The membership’s ID in your old system, with the source platform’s name
    Membership Type Name Required. Must match a type’s name in ThirdSectorBee (capitals don’t matter)
    Payer (external ID) Required. The payer’s contact ID in your old system
    Members (external IDs, pipe-separated) Required. The covered people’s contact IDs, separated by pipe characters (see below the table)
    Payment (external ID) Optional. The one-off payment’s ID in your old system
    Start Date, Member Since Optional. A row with no start date starts today; with no member-since date it uses the start date
    Status Optional. Pending, Active, Lapsing, Expired or Cancelled; anything else is imported as Active

    For a membership covering two people, the members column holds something like 1001|1002.

  4. Use the same source platform name for the membership, contact and payment external keys. Payers, members and payments are matched under that platform only. They can come from this import or from an earlier one.
  5. Run the Pre-flight check, review, and start the import.

What happens to each row

  • The expiry date is worked out from the type’s expiry policy and the start date, and each membership gets a new membership number.
  • Importing the same file again doesn’t create duplicates: a membership whose external key was already imported is skipped.

A row fails, and is listed in the job’s errors, if it has no external key, no type name, a type name that doesn’t exist, a payer that hasn’t been imported, a date that can’t be read, or no members that can be found.

Check the results

Some problems don’t fail the row, so check your memberships after the import:

  • Members who can’t be found are left off. If one of a row’s member IDs doesn’t match an imported contact, the membership is still created with the members that do match. Compare the Members count on Memberships against your file.
  • A payment ID that can’t be found makes the membership free. If the payment wasn’t imported under the same platform, the membership is imported as a Free membership. Its Payment card will show Free membership as the linked payment.

For job progress and row errors, see Job statuses and errors. Importing from Donorfy brings memberships across too; see Import from Donorfy.