EmailConnector - Allow Users to Add Accounts

0
Hi Everyone,I have a requirement to allow users to add their own accounts via an OAuth config linked to M365. I am using the EmailConnector module and I am able to do this from the admin console but that's not a very good experience. What I would like to be able to do is have a user click a button to create and authorise their own M365 email account for Mendix so they will eventually be able to decide which address they want an email or template to go from.I don't want to grant users access to the same entities and attributes as the Admin user (and in fact, doing so creates even more problems) but I hit a wall where I can almost do this but get an illegal access error unless the page is refreshed which is also a rubbish user experience. Has anyone been able to make this work? I'd rather not create a whole new module to do this via Graph - EmailConnector works fine, but it's exposing it in the right wat to end users that is my challenge.Any pointers gratefully received.
asked
1 answers
0

Hi,


What you are trying to achieve is a valid use case, but the challenge you are facing comes from how the EmailConnector module is designed. Out of the box, it is primarily built with an admin-driven setup in mind, and the entities involved (such as Account, OAuth configuration, tokens, etc.) are typically restricted to admin roles. Exposing this directly to end users without adjusting security will lead to the kind of illegal access issues you are seeing.


A clean way to approach this is to introduce a controlled abstraction layer instead of exposing the EmailConnector entities directly.


First, avoid giving end users direct access to the EmailConnector domain model. Instead, create your own entity (for example, UserMailbox) that is associated with Account (or the relevant EmailConnector entity). This allows you to manage ownership (per user) while keeping EmailConnector internals protected.


Second, handle the OAuth flow via a microflow or nanoflow that runs with elevated privileges (for example, using a microflow with “Apply entity access = false” or a dedicated admin/helper microflow). The idea is that the user triggers the action (clicks “Add Account”), but the actual creation and linking of the EmailConnector Account and OAuth tokens happens in a controlled server-side flow with sufficient rights.


Third, the illegal access error you mentioned (which disappears after refresh) is typically caused by object access mismatch within the same request. This often happens when:

  • An object is created in a context without sufficient read for the current user
  • Or associations are set on objects the user cannot yet access

To resolve this:

  • Ensure that after creating the Account, you explicitly grant the current user access through an association they are allowed to read (for example, linking it to a UserMailbox owned by the current user)
  • Commit the objects before returning them to the UI
  • If needed, retrieve the object again in user context after commit, so it respects security constraints

Fourth, make sure your security model is aligned:

  • Users should only have access to their own “wrapper” entity (e.g., UserMailbox)
  • They should not have direct access to all EmailConnector accounts
  • Use XPath constraints like [UserMailbox_User = '[%CurrentUser%]'] to isolate data per user


Finally, for the user experience (button → authorize → select account), you can:

  • Trigger the OAuth authorization via a page or external redirect
  • Store the resulting tokens using the elevated microflow
  • Then return a clean, user-owned object back to the UI

In summary, the key is not to expose EmailConnector entities directly to end users, but to wrap them in your own domain model and handle all sensitive operations through controlled microflows with proper security boundaries. This avoids illegal access issues and gives you full control over the user experience without modifying the core module.


answered