ChrisS.45760 (Customer) asked a question.
Hello,
I'm trying to set up the Office 365 Mail Integration as part of some workflows I'm testing. I integrated the connection with my own email and tested out some sending.
A couple questions though:
1) The email ends up being sent through some obscure outlook.com address instead of my actual email which makes the email go to my junk folder when it is received. Is there some other configuration on the Okta or Office 365 side to make the email actually work normally?
2) Someone asked here a few months ago about the ability to send emails as a different user, and your response was not being sure if the Office 365 API allows it. Well, the Graph API specifically mentions altering the from address (as long as the authentication user has sendAs permissions for the address): https://learn.microsoft.com/en-us/graph/outlook-create-send-messages*create-and-send-mail. Are we saying my only option is to make a custom API integration to do this?
3) Someone also asked, why can't we just have the normal Okta email system send the email, like all the other Okta emails come through instead of dealing with Office 365 integration at all. Will this ever be a possibility?
Has anyone actually gotten the Office 365 email integration to work properly in workflows? It seems something this simple as sending an email notification would be easy but that doesn't seem to be the case!
Thanks!
Chris
Have you grant send as permission by Graph API? you should grant it in azure ad for okta workflow.
@ChrisS.45760 (Customer)
1) I am not really sure what you are referring to here. Okta Workflows isn't sending emails at all. It is making an API call to the third party (in this instance Microsoft) and following their documented process for submitting a POST method to their endpoint that expects a specifically formatted request. If the format is valid it should accept the POST action, likely formulate an MIME encoded email, then and sends it via SMTP. The API client (Okta Workflows) isn't going to be able to influence anything other than submitting a valid POST request.
2) Please see my previous answer. The reason why the API client vendor (Okta Workflows) doesn't know exactly how a third-party operates is specifically because we only have access to their public documentation. If their public documentation indicates a method to do what you want, try that, and if it works then your needs are met. Each Workflows App Action card has a "Custom API Action" option which should allow you to try non-builtin custom actions with vendors. You can also leverage the API Connector card for even more flexibility.
I often recommend customers look to see if the third-party provides a Postman collection that contains the actions you are trying to accomplish. These are usually published by the vendor on their own website and is often a good way to determine if something custom can be accomplished. If it can be accomplished you can then duplicate the process in Workflows for automation purposes.
3) See #1 above. You are making an authenticated API call to an email service to send an email on your behalf. Okta is not an email service vendor. This is likely never going happen for a variety of reasons both technical and legal.
3b) Yes, plenty of people leverage O365 successfully in their flows.
Hey Tim, thanks for the reply!
I'm excited for all the cool integrations we can do with workflows, was just a little frustrated how something that sounds simple like sending an email is actually more complex.
For my first question, understood this is just triggering an API call. I had tried setting up the OOB Office 365->Send Email app action in the Okta Workflows. Configured my own company email as the integration, and tried sending an email as part of the workflow using it. But instead of my own company email showing up in the from address of the received email, the from address was outlook_<random letters>@outlook.com instead and sent to junk. Obviously just some weirdness with how Office 365 is processing the smtp request, but getting this action working properly seems to require more development time (ie figuring out the O365 Graph API and building custom requests to get things just how I want them) than just using the OOB solution in Okta Workflows. No doubt many customers are connecting to O365 and doing things through workflows, but I bet they aren't just using this OOB app.
I guess when I typically think of emails from SAAS vendors I'm usually thinking of alerts which are simple to get emails working for (Okta sending email alert about domain connector going down, for instance) vs these custom workflows that could contain malicious content that Okta wouldn't want coming from their domain.
Email is a complicated beast and I guess I should have known sending emails via a script can require some effort. The Okta Office 365 Send Email app function doesn't really mention of those nuances, just a "enter your credentials here". It's just one use case out of thousands of possibilities using Okta workflows, just happened to be the one I picked first :). I'm going to try using a precanned solution for handling automated emails like Amazon SES which seems like easier setup versus customizing POST requests to the Microsoft Graph API.