In general it's bad practice for a user to expose someone else's email address to an application provider without consent (email providers being the one necessary exeception, of course), therefore I would abandon that approach in any case.

You could implement read-only access to a workspace via a generated link (containing a UUID or similar), like e.g. a Dropbox link. You would store the link IDs with the workspace, and you can implement (user-configurable) link expiration and such. Since links are shareable, these wouldn't be personalized to the recipient. A recipient who wants more than read-only access would still have to create an account with you and ask the workspace owner for write access.

> In general it's bad practice for a user to expose someone else's email address to an application provider without consent

Thanks, that makes sense as a rule of thumb. I'll move towards invite code (and work domain/SSO) based access. It's also a bit awkward to be able to add existing users to a workspace without any sort of confirmation, so my system needs a bit of rework regardless.