What do email-enabled apps look like in the modern workplace? Part 1
Sharing Our Expertise

Our consultants solve challenging business problems and love sharing their knowledge. Tap into our insights and put them to work for you.

Back to Blogs >>

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:



The case for email-enabled applications

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.

Use case: simple support app

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:

  • A simple queue of incoming emails that can allow a support team to store additional information, such as a Status and Priority, with each request

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.

The “modern workplace” version

But what if we add improvements from the modern workplace and the intelligent cloud? What if we could:

  • Determine whether an email is a new request, or a reply to an existing request
  • Intelligently, automatically classify incoming support requests based on the body of the original email
  • Display some visual queues to the support team when particularly angry requests enter the system, or when a request has been marked “Urgent”
  • Allow end users to request an update on their support request, or sign off when their support tickets have been closed– with a single click
  • Replace email submission/status request component with a bot that can respond to users in real time
  • …and ultimately, what if we can replace some part of the support team with a bot that can point users to help content before escalating and issue to a human being?

Build the basic solution

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:

  • A shared mailbox in Exchange Online that receives emails and creates an item (“Request”) in a SharePoint list
  • The original email is attached to the SharePoint list item
  • The support team can assign a status and priority to incoming requests
  • A response gets sent automatically to the user when the email is received

1. Create a shared mailbox

In the Exchange admin center, create a new Shared Mailbox.  Done.

2. Create a SharePoint list called “Requests”

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:

  1. Sender – Person or Group
  2. RequestId – Single line of text (this will be our unique Ticket ID)
  3. Status – Choice (Requested [Default], Acknowledged, In-Progress, Resolved, Accepted, Rejected)
  4. Priority (1 – Urgent, 2 – Normal [Default], 3 – Low)

That’s it for now. Your list should look like this:


3. Create a Flow to store incoming emails in a SharePoint list and respond to the user when a new request is received

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:

  1. Title: Subject (from the trigger action)
  2. Sender Claims: From (from the trigger action)
  3. RequestId: RequestId (the variable you just initialized with a new GUID)
  4. Status Value: Requested
  5. Priority Value: 2 – Normal

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:

  1. Mailbox address: the address of your shared mailbox
  2. To: From (from the trigger action)
  3. Subject: New request- Request ID: {RequestId} (the variable you created earlier)


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.


4. Test the flow

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:

  • Updating the flow to determine if the email is a new request, or a reply to an existing ticket
  • Allow the sender to request a status update by replying to the automated email response

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

Original Post: https://christophernealjohnson.com/2018/11/13/email-enabled-apps-part-1/

Recommended For You
Many obscure issues can occur that can cause the Dynamics 365 App for Outlook to disconnect and disappear, but thankfully there are a couple of s...
View More ...
Office 365 can improve and modernize your workplace faster and enable you to focus on strategy and adoption rather than implementation.
View More ...
Join Mark Roden for "Using VSTS to automate build and deployment tasks for SharePoint Framework webparts" at SharePoint Fest Chicago on Dec 7.
View More ...
I use it all day, every day at work. I also help run my office Fantasy Football league. See where this is headed? This year, I decided to run our...
View More ...