On your general question, I would imagine there’s a way to block using specific email domains like gmail to restrict most personal email providers. Hopefully someone chimes in with advice, or it’s a good question for your CSM/Support. 

1.) You definitely should be able to edit the Contact (and by that Account) their community record is associated with. I do it all the time within Salesforce. 

Assuming your integration works the same as mine, the Insided user record creates a specific Salesforce record type (we call it Community Member, not sure if that’s default). And the record is matched with a Contact. When you’re on the Community Member record in Salesforce, you should be able to change the contact it’s associated with (to one that matches their work email) and/or update the the Account that record is affiliated with. 

Note: there are likely two places for Account: 1.) on the Community Member record, and 2.) on the Contact record. You might need to update Account on each. 

I’d guess the simplest solution is to update the Contact for their personal email (rather than change the Community Member record to their work email) so that their personal email Contact is also associated with their known work account. 

2.) Yes, absolutely. We do a version of this, but it takes some configuration. Here’s our solution: 

• We create new contacts for any email not found. Otherwise the Insided record won’t match to a Salesforce Contact and their activities won’t sync. For reporting purposes, we want all our user activities to sync to Salesforce, so we setup a Zapier automation to Create a Contact if it doesn’t already exist, that way it’ll match up with the Insided Automation. 
  (note: new contacts won’t fall into these next steps because you’ll need to match them to an account) 

For Users matched to Salesforce Contacts:

• We use the relationship type (customer/partner/staff or other customer types) to create a custom field in the Community Member record. You can then report off that if needed, but really we do this to enable…
• We use that field to trigger a Custom Role on their insided profile via the API/Zapier. 

The end results is pushing Relationship/Customer Type to Insided as a Custom Role. 

Now that you have it as a Custom Role, you can:

• leverage that in some of the Control filters for moderation and analytics
• use it in the exports that provide their user roles
• create Ranks that are automated based on specific role criteria
• customize access to specific features using permissions (ex. toggle the Customer customer role on and leave it off for non-customers)
• customize other experiences using CSS and third-party scripts

Thanks @DannyPancratz it helps a lot! I don’t have SF access, which makes the process a little more complicated, but this gives a good plan for how I can set it up with my colleagues going forward.

Unfortunately I don’t think we can block any email domains, since we have students and personal use users in addition to the company customers...but with a good integration set up I hope it will fix most of that.

Thanks @DannyPancratz for these awesome tips, also to you @JessEs for asking about it. I actually come across this question sometimes during conversations with our customers, and to be honest I have also not found the ideal solution yet. I however fully agree with the tips above.

One addition that I would want to make is: Update the registration form title for the email input field, e.g.:

Email (please use your company email address if you have one)

This can be simply done by adding this phrase manually via the Phrases page. You can use this information to add a new phrase:
Module: Common
Key: loginBox.emailaddress

I think this naturally will reduce the amount of cases where you would have to update this field manually.

Thanks for your suggestion @Julian ! We already have the custom phrase there, which I’m sure reduces the cases, but we still get some rebels but if we can get the SF integration working so that it connects them to the correct account anyway, it should be fine.