Skip to main content

Mapping Specificity

Updated over 2 weeks ago

When data is mapped from Bloomerang Fundraising to a third-party program, certain things take priority over others according to rules of specificity. Mappings are created for each item type (form, event/package, restriction/sub-restriction, classification, category, store category/store product). We determine what to map based on how specific a mapping is. If we don’t find a mapping for the most specific item in a transaction, we move up the line and look for a less specific mapping until we find a match. If we don't find a match, we'll use the default values.

For Bloomerang Fundraising (least specific to most specific):

  • Form

    • Event

      • Package

    • Restriction

      • Sub-restriction

For peer-to-peer (least specific to most specific):

  • Form (peer-to-peer campaign)

    • Classification

      • Restriction (if a classification DOES exist)

      • Category (if a classification DOES exist)

    • Restriction (if a classification does NOT exist)

    • Category (if a classification does NOT exist)

    • Store Category

      • Store Product

An example of specificity affecting mapping for a peer-to-peer campaign would be if someone registered for a classification and a category - the category would take priority in the export over the classification since it is more specific.

The items in yellow in the diagram below are viewed as parent objects, with the green objects within them being the more specific child objects. The stand-alone items for peer-to-peer do not have more specific objects within them.

mceclip0.png
Did this answer your question?