Yes, we did something similar. In Employee Central (EC), we assigned each employee a geographic region such as North America, Europe/Middle East, Asia, Latin America, etc. Then in the LMS connector configuration file, in the SF User connector section, we mapped the user Domain field to the Region field within EC. You could do something similar using Country if your Regions don't meet the need. When the SF User Connector adds a new user, it puts the user into the appropriate Domain. Then in the LMS System Admin menu, we created domain restrictions for each regional domain, and then assigned those domain restrictions to the workflows within the admin security role. We specifically restricted the workflows for Assign and Unassign Item and Curricula and Edit Item/Curriculum Assignments based on user domain. We chose not to domain-restrict the Search workflows, however. In our company, our admins can view the records of users outside their domain restriction, but they cannot edit the assignments for those users.
One good thing about domain restrictions is that a single Domain Restriction can contain multiple Domains if desired. If you are creating Domains based on Country, you have the option to create a Domain Restriction for only users in Country A and a different Domain Restriction for both users in Country A and users in Country B. If you have administrators who need access to users in more than one country, you can create a security role that contains the Domain Restriction "Countries A and B". On the other hand, if you prefer single-country Domain Restrictions, you can create different versions of the same security role, each with a different country restriction, and you can give multiple versions of the same role to an administrator who has responsibility for multiple countries. You decide what strategy meets your needs best. We have used both strategies at our company.
Mary Katherine Johnson
We have used similar approach that Mary entailed, assigning multiple roles with similar workflows and restrictions based on Organization (not to confuse with Org ID). We have utilized custom columns for Functions, for instance each user in our organization has at least one Org Level value (= Function, HR), which sits under root level on the hierarchy chart (example, Eisai->HR). This prevents updating domains at AP level however when the company re-strategies, meaning change Org Levels conduct detailed analysis and execute change so that assignments are not lost. This happens in partnership with HR (Source) team.
This is a downside of automation I suppose.
We took this approach at Securitas when we set up domains. We set up portions of the US into regions (for example: north, south east and west) along with international domains by country. This made targeting learners by region by AP easy, as well as domain restrictions for Admins. We can talk later....