How 'person detection' works when a form is submitted
In this article
Detecting just a mobile/cell number
Detecting with other data
Examples
There are several places where ChurchSuite will attempt to intelligently detect whether someone is an existing contact or child when personal data is submitted through a ChurchSuite form. Person detection takes place for:
- Form submissions made through a public form page
- Event sign-ups made through an event page
- Group sign-ups made through a group page
- Donations made through Donate via SMS
Detecting just a mobile/cell number
If only a Mobile/Cell number is provided, for example, through Donate via SMS, a Contact or Child will be matched if there is exactly one person within the Address Book or Children module with that mobile/cell number. If there are multiple people with the same mobile/cell number, no definitive match is made.
Detecting with other data
Person detection applies to contacts in the Address Book and children in the Children module and requires an exact match against the Last Name that is stored in those ChurchSuite modules.
In addition to an exact match on Last Name, the following fields are examined for exact matches:
| Collection | Field | Specific To |
| Name | First Name | - |
| Formal Name | - | |
| - | ||
| Spouse Email | Contact | |
| Parent/Carer Email | Child | |
| Mobile | Mobile | - |
| Spouse Mobile | Contact | |
| Parent/Carer Mobile | Child | |
| People | Spouse ID | Contact |
| Parent/Carer ID | Child |
ChurchSuite compares the supplied data from the form against all contacts and children who have an exact match on Last Name, with priority given first to matches on contacts and then to children. Once all contacts with matching Last Names have been compared, if there is a single contact with an appropriate match percentage, they are considered to be a definitive match. If there are multiple contacts with the same match percentage, the system will 'fail safe' and not match any of them. If no contact matches are detected, the matching process undertakes the same tests for children.
Examples
Consider the following data already in ChurchSuite:
| Contact John Smith thesmiths@hotmail.com 07970 123 456 |
Spouse Jane Smith thesmiths@hotmail.com 07999 987 654 |
Child Sally Smith thesmiths@hotmail.com No child mobile |
Scenario 1
| Collection | Field Data | Match |
| First Name | J | No unique match |
| Last Name | Smith | Multiple matches |
| thesmiths@hotmail.com | Multiple matches |
In this scenario, the data matches both John Smith and Jane Smith; as a result, ChurchSuite will "fail safe" and not identify a match for either.
Scenario 2
| Collection | Field Data | Match |
| First Name | Johnathan | No unique match |
| Last Name | Smith | Multiple matches |
| Mobile | 07970 123 456 | Unique match |
While still using the same ambiguous First Name and Last Name combination as in Scenario 1, the addition of the mobile number (which is considered a unique attribute) enables a reliable match with John Smith as the person, even though the First Name isn't an exact match.
Scenario 3
| Collection | Field Data | Match |
| First Name | Sally | Unique match to the child |
| Last Name | Smith | Unique match to the child |
| Mobile | 07999 987 654 | Unique match to the child's Parent/Carer |
Sally Smith is an exact match based on the First Name and Last Name, along with the addition of the Parent/Carer Mobile.
Scenario 4
| Collection | Field Data | Match |
| First Name | Harley | No unique match |
| Last Name | Smith | No unique match |
| Mobile | 07999 987 654 | Unique match to the child's Parent/Carer |
Ordinarily, a unique Mobile is determined as a match for Jane or Sally, but the ambiguous First Name means we "fail safe" and do not match for either.