Duplicate organisations created when multiple colleagues sign up independently

[Joe-Heffer-Shef]

Problem

Multiple colleagues from the same NHS Trust can independently create separate Organisation records with the same (or nearly the same) name, because organisation creation has no duplicate check and there is no way for a user to join an existing organisation instead of creating a new one.

How it happens

1. A user at an NHS Trust signs up and creates an organisation (e.g. "Sheffield Teaching Hospitals NHS Foundation Trust").
2. Before they get around to inviting their colleagues, one or more of those colleagues also sign up independently and each create their own organisation with the same or a very similar name.
3. The result is several distinct Organisation rows in the database that all represent the same real-world Trust, each with only one member.

Impact

• Each duplicate organisation is a completely separate Organisation object (see home/models.py), so:
  • Users in different duplicate orgs cannot see or share each other's Project/Survey data, even though they belong to the same real organisation.
  • Invitations sent by one colleague only add members to their organisation, not to the others.
• The app currently has no organisation switcher — a user only ever sees their first associated organisation (User.organisation_set.all() is used without any selection UI, e.g. User.projects_iter() in home/models.py). If a user ends up in more than one organisation (e.g. after a manual merge, or if they were separately invited into two of the duplicates), they cannot choose or even see the "other" organisation from the UI.
• There is currently no admin/staff tooling to detect or merge duplicate organisations. The only workaround today is manual: a staff member identifies the duplicates and deletes the redundant Organisation rows directly.

Current workaround

Redundant organisations are currently being cleaned up manually (identified and deleted) on an ad-hoc basis when noticed. This is not scalable and risks data loss if a redundant org has already accumulated projects/surveys/members before it's spotted.

Root cause

• Organisation.name (home/models.py) has no uniqueness constraint and no fuzzy-duplicate check at creation time.
• There is no join-existing-organisation flow — the only path into an organisation is either creating a new one or being invited by an existing member, so a user with no invitation has no way to discover and request access to an org that already exists for their Trust.

[Joe-Heffer-Shef]

Possible approaches

Some notes on the three directions raised, based on the current code:

1. Searchable orgs + "request to join" (remove auto-org-creation on signup)

• Add 'join existing organisation' workflow for users without an invitation #674

Worth noting: signup today isn't actually auto-creating orgs from invitations — SignupView (home/views/auth.py) is invitation-gated and joins a new user to the inviter's org via ManagerSignupForm. The duplicate-org vector is really the standalone create flow: OrganisationRequiredMixin (home/mixins.py) sends any user with zero memberships straight to OrganisationCreateView (home/views/organisation.py), which calls organisation_service.create_organisation(name=...) with whatever free-text name they typed — no search, no duplicate check, no way to instead find and request access to an existing org.

So the fix here isn't "remove auto-creation on signup" so much as: insert a search/select-existing-org step before OrganisationCreateView lets someone create a new one. A "request to join" would need a new request/approval model (who approves? presumably an existing ADMIN of that org) plus notification — we already have InviteMemberForm / AddExistingMemberForm (home/forms/) as a template for the approval side, so this is mostly "invitation flow in reverse."

Biggest open question: exact/fuzzy name matching for NHS Trusts. Organisation.name has no uniqueness constraint at all (home/models.py), and Trust names have enough variation ("Sheffield Teaching Hospitals NHS Foundation Trust" vs "STH NHS FT" vs "Sheffield Teaching Hospitals") that a naive iexact search will miss most real duplicates. We'd likely want trigram/fuzzy matching (Postgres pg_trgm + TrigramSimilarity, if we're on Postgres) surfaced as "did you mean one of these?" during org creation, rather than a hard block.

2. Allow users to join multiple orgs

• Allow users to join multiple organisations #675

Smaller change than it looks: OrganisationMembership already has unique_together = ["user", "organisation"] and nothing at the DB level stops multi-org membership — the one-org-per-user behaviour is enforced entirely in application code, via can_create (organisation_service, checks memberships.count() == 0) and via User.projects_iter() / organisation_service.get_user_organisation(), both of which just do user.organisation_set.first().

So multi-org support needs:

• Dropping/relaxing the can_create zero-membership gate (or keeping it just for creating new orgs vs joining existing ones)
• Replacing every .first() org lookup with an explicit "active organisation" concept (session-stored current org, most likely) — projects_iter() and get_user_organisation() are the two call sites I found, but there may be template-level assumptions too
• An org switcher in the UI, which doesn't exist today in any form

This is probably a prerequisite for approach 1 anyway (a user who already has an org still needs to be able to join a colleague's), and is arguably the least risky of the three since it's additive rather than a data migration.

3. Org merge tool

• Org merge tool: management command to merge duplicate organisations #676

Most valuable for the existing backlog of duplicates, least valuable long-term unless 1/2 also ship (otherwise new duplicates just keep accumulating). A merge would need to:

• Reassign Project/Survey FKs from the losing org to the winning org
• Reassign or de-dupe OrganisationMembership rows (a user in both orgs would collide with unique_together)
• Decide what happens to survey responses/evidence tied to the losing org's projects — these presumably shouldn't be re-scoped silently without an audit trail, given the audit-event work that's gone into org membership changes recently (MEMBERSHIP_REMOVED event, feat: wire MEMBERSHIP_REMOVED audit event into organisation service #637)

Given the "current workaround" section already describes doing this manually today (delete redundant orgs), a merge management command scoped to admin/staff use (rather than a self-service UI) seems like the pragmatic first cut — lower blast radius, and it's the kind of one-off/staff-tooling operation that fits the existing SAR export console pattern rather than needing new end-user UI.

Suggested sequencing

If tackling this in stages: (2) multi-org membership first since it's additive and unblocks the others → (1) search-before-create with fuzzy matching to stop the bleeding on new duplicates → (3) merge tooling (as a staff/management-command feature) to clean up the existing backlog once orgs can safely absorb members from elsewhere.

1. Allow users to join multiple organisations #675
2. Add 'join existing organisation' workflow for users without an invitation #674
3. Org merge tool: management command to merge duplicate organisations #676