Published by Chris Johnson, on Wednesday, November 14, 2018
My employer performs a lot of migrations, mostly from legacy on-premises platforms to Office 365. One question that inevitably comes up during our first conversations with clients is “What’s your answer to mail-in databases?” By mail-in databases, our clients are referring to either Notes Mail-In Databases or SharePoint Email-Enabled Libraries.
I’ve done extensive work with both, but mostly on-premises. This got me thinking: what do email-enabled applications look like in the modern (cloud) workplace?
In this multi-part series, I try to answer that very question beginning with a simple app built on SharePoint Online and Flow, then adding more integrations to further modernize the app until the email component is entirely optional.
The goal of this series is to chart the path from “basic email-enabled application” to the Modern Workplace and possibly beyond. Part 1 covers the “Basic” and “Smarter” steps below:
I spend a lot of time trying to convince my clients to get out of email as much (and as quickly) as possible. Microsoft is now leading the race to reduce enterprise reliance on email with enormous investments in Microsoft Teams, its cloud-only collaboration-focused all-in-one digital workplace.
But as my larger clients remind me, that transition isn’t as easy for Fortune-500 organizations as flipping a switch, from a technical or change management standpoint. So we still need to have an answer for how to handle email-enabled applications, if only as a stopgap between legacy work streams and a true modern workplace.
Let’s take a typical example: a simple support application where users can email support requests to be processed by a support team. Here’s what that fictional email-enabled app might look like at the most basic level:
This is the extent of most email-enabled apps right now, perhaps with some additional workflows that fire off notifications when a field changes value.
But what if we add improvements from the modern workplace and the intelligent cloud? What if we could:
If you’ve ever migrated an organization from SharePoint on-premises to SharePoint Online, you know that SharePoint online does NOT support email-enabled lists or libraries.
Thankfully, Microsoft Flow and Modern SharePoint Lists have a simple solution for this.
Here are the deliverables for our simple solution:
In the Exchange admin center, create a new Shared Mailbox. Done.
I did this on a Team site, but you can do it anywhere.
If you plan to continue to work through this example from start to finish (including creating a bot), create a new SharePoint Team site to host this list.
Add the following columns to the list:
That’s it for now. Your list should look like this:
First, create a new Flow. For now, you can just create a personal flow; a production version of this app would probably be built as a Business Process Flow.
Every Flow starts with a trigger. We’re going to use the “When a new email arrives in a shared mailbox” trigger:
Type the name of your shared mailbox in the Mailbox Address field and leave “Inbox” as the selected Mailbox.
Next, add a new action and choose the “Export email (Preview)” action. Note that this action is in preview; it allows us to export the actual .eml file so we can attach it to the list item later.
In the Message Id field, click the “Message ID” parameter from the previous step.
Now we’ll create a list item in the Requests list.
Before we create a list item, we need to generate a unique ID for the ticket. We could use the SharePoint list item ID or even the message ID, but the former is a bit short (a single integer) and the latter is crazy long, so we’ll generate a GUID instead.
Add an “Initialize variable” action. Call the variable “RequestId” (type String) and click into the Value field to enter a custom value. In the box to the right, select “Functions” and type “guid()” to generate a new GUID, then click OK.
Next, add a “Create item” shape to the canvas and type in your Site Address (you may need to supply a custom value if your site doesn’t appear in the dropdown). Then select the “Requests” list you created earlier.
Set the field values as follows:
Later, we’ll use Azure Cognitive Services to intelligently set the value of the Status and Priority fields.
Tip: rename each of the actions so your Flow is easier to read later as it grows in size and complexity.
Your Flow should now look like this, and you can test it by sending an email into your shared mailbox and checking the Requests list to see if a list item was created.
Next, we’ll attach the original email to the list item we just created. This must be performed as an extra step. Add an “Add attachment” (SharePoint) action to the canvas, then supply the same site URL and list name as you used in the previous SharePoint step.
In the Id field, add the “ID” value from the “Create request list item” step. Provide a File Name of “Original Email.eml”, then add the “Body” field from the “Export original email” step in the File Content field:
Finally, we let’s shoot the email to the original submitter to let them know the request was received. We’ll include the Request ID in the subject so that if the user replies to the email, we can detect that the email is a reply and not generate a new ticket.
Set the field values as follows:
For the “Body” field, add body text similar to the sentence above; you can include HTML formatting if you wish, but you must first click “Show advanced options” and set “Is HTML” to “Yes”. Do this if you want to include formatting and/or a hyperlink as I did.
At this point, your flow should have 4 actions (you can rename them as you see fit; note that once you use the output of one action in another action, you can no longer rename the first action):
Click “Test” in the upper right-hand corner of the Flow canvas to test your flow (this will save the flow, too). Choose “I’ll perform the trigger action” then click “Save & Test”:
Send an email to the shared mailbox. You can watch the flow execute in real time, with a green check mark appearing next to each completed step:
Assuming your flow ran correctly, two things should happen:
You should receive an email from the shared mailbox with a unique Request ID in the subject.
Here’s the email I received (note that it is sent with Low importance; this can be configured in the “Importance” field of the advanced options for the “Send an email from a shared mailbox” shape):
A list item should also have been created in your SharePoint list, with the original email attached.
Here’s the list item that was created when I emailed the mailbox with a subject of “Testing”:
This is a great first step towards building an email-enabled application, but it still leaves much to be desired. In the next entry in this series, we’ll address the following:
That’s all for now! You can download this flow (the finished product at the end of this post) here: Download the flow from Part 1 of this series
Categories: Microsoft Teams,SharePoint,Microsoft Flow,Email,Exchange,Office 365