Please be aware that there is a list of test cases available that need to be passed before moving to production - please contact the support team to get the latest version.
- Registration of club
- Updating club information
- Updating status of club (active/ inactive)
- Registration of stadium (if included)
- Updating stadium information (if included)
- Updating status of stadium (active/ inactive) (if included)
- Registration of player without duplicate
- Registration of player with national duplicate
- True positive
- False positive
- Registration of player with international duplicate
- True positive
- False positive
- Update of player details (name, date of birth)
- Update of registration details (change of level, amateur-> pro)
- Registration of referee, coach, organization official (if included)
- Registration of futsal/ beachsoccer player (if included)
- Adding registration to person (existing player also becoming a referee/ coach) (if included)
- Updating a registration status of a person (active/ inactive)
- Merging two persons (if supported by national registration system)
- Unmerging two merged persons (if supported by national registration system)
is integrated with SDK for ConnectID & Service Bus |
|
| system credentials (clientID & secretKey) are generated and known to Pilot |
| Pilot knows FIFA ID of the Member Association |
| SDK authenticates with ConnectID Service using system credentials |
| Pilot is able to ask another MA for Person details via Service Bus |
Pilot is able to reply with Person details when asked by another MA Note that every MA who is already part of ConnectID can ask for person details. In the rare case that MA wants to block someone, it needs to be implemented on the client side by checking Sender FIFA_ID. | |
| Public certificate is generated and uploaded to a certificate store |
| Private certificate is generated and saved locally |
| FIFA ID is added to a data model for a person |
| FIFA ID is added to a data model for an organization |
| FIFA ID is added to a data model for a facility |
| users & passwords are generated to be able to access Admin Console |
| [future] provide IP range that will be allowed to contact ConnectID | |
| business error handling (e.g. MA tries to add registration which is already there for another MA) | |
| technical error handling (e.g. service is not available) | |
first registration process is integrated with ConnectID |
|
| Pilot can generate FIFA ID for a person and save it in FMS |
| Pilot should integrate with Force Registration method (for false duplicate handling only) | |
| FMS allows to run an international duplicate check with ConnectID, display the results and perform a duplicate resolution (no Service Bus) |
| recommendation: FMS allows to run an international duplicate check with ConnectID, display the results and perform a duplicate resolution (with Service Bus) |
| decision from MA needed: do the international duplicate check synchronously (part of the registration process) or asynchronously (separate process e.g. reconciliation process like in Norway) |
| MA supports the scenario when a person wants to register but know their current FIFA_ID | |
changing registration is integrated with ConnectID |
|
| Pilot can add a registration to an existing Person |
| Pilot can modify a registration for an existing Person |
| Pilot can inactivate a registration of an existing Person |
| Pilot can modify person's date of birth |
| Pilot can modify person's name |
| FMS allows to run an international duplicate check with ConnectID after the person data (date of birth and/or name) is updated | |
| Pilot handles conflict situations, e.g. changing the registration of a different MA |
| recommendation: handle merged persons |
|
|
initial quality check & first migration |
|
| NDA is signed allowing to share persons' personal data |
| full export of the persons' information from FMS has been processed by a deduplication tool (data quality check) |
| processing results has been discussed |
| Member Association assigns a person responsible and cleans the data / removes duplicates | |
| First-time migration process has been discussed and agreed for all entities |
| Pilot implemented support for the first-time migration. Mandatory:
Rest is optional but it should be agreed when to load them. Note that due to legal limitations, players cannot be assigned to clubs. ConnectID can only store information that player is a member of a certain MA. |
| date for going LIVE has been agreed between the MA, FIFA and Making Waves |
| Pilot should have a system connected to PRE-PRODUCTION for running acceptance testing, first time load test, etc. |
| recommendation: Pilot to have a development/test system connect to BETA | |
organizations |
|
| can register a club |
| can update a club |
| recommendation: can merge a club |
| recommendation: can look up a club ID by name and/or address | |
| recommendation: split a club | |
| recommendation: handle merged clubs | |
facility |
|
| can register a facility (e.g. Stadium) |
| can update a facility |
| recommendation: can look up a facility ID by name and/or address |
others |
|
| MA prepared the list of test scenarios to verify the integration |
| acceptance tests have been performed |
| optional: run the test first-time migration on a separate environment made out of PROD to find the number of international duplicates | |
| initial first-time migration has been performed on PRE-PROD environment |
| Pilot supports storing person's history (registrations history) in their FMS |
| establish threshold for matches filtering when searching for duplicates | |
| registration windows are known and communicated (periods of higher load in ConnectID) | |
| requirements for the size of messages to be sent through Service Bus are known and agreed |