When data is mapped from Qgiv 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 Qgiv (least specific to most specific):
- Form
- Event
- Package
- Restriction
- Sub-restriction
For peer-to-peer (least specific to most specific):
- Form (peer-to-peer event)
- 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 event 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.
