Email provider for a branch

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.