... | ... | @@ -7,6 +7,7 @@ |
|
|
3. [Background Checks](#background-checks)
|
|
|
4. [inLeague System Access and Eligibility Rules](#inleague-system-access-and-eligibliity-rules)
|
|
|
5. [Youth Volunteers](#youth-volunteers)
|
|
|
6. [Merging Duplicate Volunteers](#Merging Duplicate Volunteers)
|
|
|
|
|
|
## Introduction to Volunteer Membership
|
|
|
|
... | ... | @@ -89,8 +90,7 @@ When Sterling completes the background check (usually within 24-48 hours), the r |
|
|
|
|
|
### System Access and Background Checks
|
|
|
|
|
|
You may assign coach, divisional, program-wide, or administrator access to any user in your region, but
|
|
|
inLeague users who do not have current background checks or who do not pass their background checks will have their access suspended. **inLeague Staff are unable to waive this requirement**.
|
|
|
You may assign coach, divisional, program-wide, or administrator access to any user in your region, but inLeague users who do not have current background checks or who do not pass their background checks will have their access suspended. **inLeague Staff are unable to waive this requirement**.
|
|
|
|
|
|
Volunteers who receive results other than **Green** will may retain some access depending on the result.
|
|
|
|
... | ... | @@ -99,3 +99,29 @@ Volunteers who receive results other than **Green** will may retain some access |
|
|
Volunteers under the age of 18 may sign up as referees. They are exempt from the background check requirement and automatically receive a risk status of **Blue** which allows refereeing but no other system role.
|
|
|
|
|
|
Youth referees who turn 18 during the season will need to return to inLeague and undergo a background check as soon as possible.
|
|
|
|
|
|
## Merging Duplicate Volunteers
|
|
|
|
|
|
inLeague presents a number of obstacles to the creation of duplicate users (and duplicate players) but ultimately does not forbid the existence of two people with the same name and date of birth. Duplicate accounts were more of an issue in the past during large data migrations from historical AYSO providers; these days, they are rare, but they do occur in two flavors with different resolution mechanisms.
|
|
|
|
|
|
1. **inLeague Duplicates** in which both accounts have the same AYSO ID (or no AYSO ID) and need to be merged on the inLeague side
|
|
|
2. **AYSO Duplicates** in which two distinct volunteer records with different AYSO IDs exist; or, the discovery of a user with a name like **Franklin_Dup-merged**
|
|
|
|
|
|
### inLeague Duplicates
|
|
|
|
|
|
Designate one record as the 'good' record. This is typically the record that is already in the correct family, or the record that has coaching or referee history. If neither record has any associated family or volunteer history, select the one with the most accurate or up-to-date information.
|
|
|
|
|
|
Select **User Search** and navigate to the user record of the "good" user. Select **Merge User** and then enter the name or email address matching the "bad" record (the one to be merged into the good one). The user merge utility will show the record you want to keep and then the record to be merged; confirm your selection, and all the volunteer history and financial transactions associated with the 'bad' record will be transferred to the 'good' one. The "bad" record will then be deleted.
|
|
|
|
|
|
### AYSO Duplicates where a user is already designated by AYSO as a duplicate (their name ends in -merged)
|
|
|
|
|
|
The **-merged** suffix on an inLeague user record occurs when the AYSO Association platform, Affinity, performs a merge on their side. It then updates the name of the "bad" record to append **-merged** or **Dup-merged**. If the inLeague user was tied to the "good" record, then this doesn't affect anything in inLeague and no action is required -- it is not noticeable that it happened. But if the inLeague user is tied to the "bad" record in Affinity, the user's name will show the **-merged** suffix.
|
|
|
|
|
|
The solution is to temporarily detach the inLeague user record from Affinity; correct their name and date of birth; and then re-attach the record to Affinity. This requires **registrar** or **system administrator** permissions.
|
|
|
|
|
|
1. In the user editor, select the **Reset Assoc. Data** button next to the user's AYSO ID:
|
|
|
|
|
|

|
|
|
2. A warning popup will appear indicating that this function is intended only to resolve duplicates. Select **I understand: Reset this record**.
|
|
|
3. The record is now "unlocked" and you can edit the user's name and date of birth. **Important:** Duplicates often occur because a user exists as both "Bob" and "Robert." It is essential that the user's full and legal name is used, and that the DOB is correct -- otherwise, a new duplicate will be created. **Edit the user record to remove the -merged suffix and make sure their first and last name are correct; if you aren't sure what they are, check Affinity, because inLeague should match what Affinity has.** Save the parent record after making the necessary changes.
|
|
|
4. To re-link the user with Affinity, navigate to their family profile from the **Family Profile** button in the user editor. The family profile will open in a new window; behind the scenes, it will submit the updated user record to Affinity and should match the "correct" one. Refresh the user editor and you should see their AYSO ID (and risk status, if applicable). |
|
|
\ No newline at end of file |