Hello Harm,

The email providers as they have been implemented were never intended to serve the purpose of connecting end users with a mailbox. They are not intended as a way of integration or synchronization between the Software Factory/IAM and third party email solutions. Instead, they can be used in combination with the Email connector process action to send informative emails from an application, whilst it being possible to include data from said application in the email.

This is not much different from what the SMTP connector has always done in the past, except for the fact that we now also support other providers such as Mailchimp, MS Graph and Sendgrid. Besides that, the providers make it possible to reuse predefined setups without having to set up basic values such as authorization for every single process flow or situation.

In theory I believe it would be possible to add Gmail as a provider type in the future. If you would like to have this option I kindly request you to create an idea for this.

Kind regards,

Renée

Hello Renee,

Thanks, I understand this, but what I don't understand is how and when to enter the username and password for each email provider. Do I have to create a task with process flow myself?

A full explanation with at least one example would be appreciated.

Best regards,

Harm

Hey Harm,

In the case of the SMTP connector and the Email connector you would use a general email account to send the emails from, which would have its own username and password that only has to be entered once. For the SMTP connector, this has to be set up in the process action input parameters. For the Email connector, this can be set up per email provider which is subsequently connected to the process action.

From the way you phrase your question I get the feeling that you're trying to create functionality that allows users to send emails from their own email addresses, this is also not the intended purpose of these connectors.

If I am just completely misunderstanding the intended purpose, please let me know

Dear Renée,

It is clear to me that email providers can only be used for scenarios to send automatic notifications from the application. In the SF we can then predefine that and in IAM the credentials can be updated, correct?

However, it is still not clear to me when and how the credentials were entered, in case of a non-SMPT provider.

In addition, there is indeed a desire to allow end users to connect to a mailbox from applications to be able to send and/or receive email messages. For this I am waiting for a solution in the Thinkstore, as stated by Roel in his post: https://community.thinkwisesoftware.com/news-blogs-21/seamless-synchronization-with-microsoft-graph-4156

I'm sorry to say, but there is very often a lack of understanding between your development team and us as functionally driven developers. It's a pity, because you are capable of making the most beautiful things, but it costs us unnecessary effort to get them implemented. That is why it would be nice if documentation gave more extensive examples of how components can be implemented in applications and what it will look like for our end users. Short instructional videos, rather than too abstract documentation, would help.

In the case of a non-SMTP provider you can enter the credentials in the SF, these email providers and their credentials are subsequently synchronized to IAM.

In IAM you can then update these credentials and/or save them as an encrypted value, as explained in the following parts of the documentation:

• https://docs.thinkwisesoftware.com/docs/iam/applications#email-provider-for-an-application
• https://docs.thinkwisesoftware.com/docs/iam/applications#store-key-data-encrypted-for-file-storage-email-provider-and-oauth-server

If the email provider is used in a process flow, which has been set up in the SF and subsequently synchronized to IAM, updating the credentials in IAM will result in the process flow using these IAM credentials instead.

In regards to your comment on the Documentation, I just want to note that the development team of the SF/IAM and the team that writes the Documentation put in quite a lot of effort to describe all the functionality within both applications as thoroughly as possible. When possible we provide examples of how things can be implemented, but it can be difficult to predict what all the developers using the SF and/or IAM need most. We will take this comment into consideration for future changes to the documentation.