Confirmed. The two import paths check for duplicates differently. We need to agree on which behaviour is right before fixing it, because each option has drawbacks:

1. Look for duplicates among all participants, whoever owns them (what you expect)

• A user can find out whether a person exists in the central database, even one they're not allowed to see. Entering a name and email is enough to check.
• The user gets a "duplicate" message and nothing else. The existing participant stays invisible to them, the survey participant isn't linked to it, and their data isn't saved anywhere they can see.

2. Look for duplicates only among the user's own participants (current CSV import)

• The same person can appear several times in the central database, once for each user who imports them.
• Participants that were shared with the user but belong to someone else are not found either, so they get duplicated too.

3. Look for duplicates among participants the user can see (owned + shared)

• No hidden data is revealed, and duplicates within what the user can see are prevented.
• Your scenario would still create a second record, because the admin's participant isn't shared with the new user.

I would go with option 3 for both import paths. What do you think?

PS : I have only one client (very old; he has hired developers for years now) using Particpant.
He wants to share the participants with all teams. We don't have such an option?

I really think the good solution for starting is 3. Look for duplicates among participants the user can see (owned + shared) : more complex SQL here.