Domain Separation, Data Residency, and Parallel Development

Domain separation is not the right first answer for either requirement.

• Residency: Domain separation is logical segregation inside one instance and database. It does not create a separate physical data store. If the legal requirement is that German and French employee-relations data must remain in the EU, confirm where the Amsterdam instance and its backups, attachments, and support access reside. If they are already in the EU, the residency control is contractual, backup, and access governance, not a new domain. If they are not, the answer is an instance in an EU data center, not domain separation.
• Contractors: 400 contractors needing read-only access to a narrow IT service set is an access-control problem. Use roles, ACLs, user criteria, and a scoped portal experience. Domain separation would add administrative overhead and a separate domain for little benefit unless there is a true multi-tenant or admin-isolation requirement.
• Target architecture: One EU instance, a strong ACL and role model, separate catalog and portal visibility for contractors, and domain separation only if a business unit needs separate administration and data boundaries. Do not use it as a translation feature.

The collision is caused by one shared global update set and no release discipline.

• Stop parallel work in a single update set. Give each feature or developer a separate update set and define a merge and release owner.
• Move customizations into scoped apps where possible; scoped apps support delegated development and cleaner source control.
• Integrate the instance with source control and a CI/CD pipeline so changes are reviewed and deployed from a repository, not manually retrieved.
• Use separate development instances or sub-development instances for parallel work; promote through test and production.
• Add code review, a change freeze before go-live, and a release calendar.
• Keep update sets batched by feature and document dependencies. With 10 weeks left, do not attempt a full DevOps transformation; stabilize the release process first and reduce the number of parallel changes.

Flag these risks:

• Timeline: Two desks have never used the platform. Domain separation adds domain-specific roles, catalogs, flows, reports, and testing, which is not a 10-week change for a team already behind.
• False assurance: It may not satisfy the regulator if the concern is physical residency or support access.
• Reporting fragmentation: Global dashboards and cross-desk SLAs become harder when data is split across domains.
• Operational overhead: Domain admins, domain-specific data, and domain visibility rules need ongoing governance.
• Translations: Domain separation does not translate the portal; use the translation and localization features separately.
• Contractor access: Domain separation may over-isolate contractors and complicate the service catalog. Recommend a phased decision: fix release governance, confirm residency facts, and use ACLs for contractors first.