On the surface, the ever evolving Microsoft Office 365 platform seems like a win. With all the toolsets included with the suite, it seems like a no-brainer for many large enterprise organizations to make the switch - which is exactly what I've been working on lately. Specifically, I've been trying to update a staff intranet to allow for single sign on (SSO) through Azure Active Directory and to utilize the office 365 tools as much as possible.
The first step in this process for me was to get a help desk setup for staff to use to request support or flag an issue. Since O365 comes with Planner, this should be a piece of cake, right? Not so fast.
The Missing Link
At first glance, my approach was to setup the following flow:
On the surface, this should work but there was a major gap with the Microsoft Forms product as it doesn't have the ability to include file attachments. This seems like a major shortcoming but after a lot of research, no solution to uploading files from a submission form seemed to be available in the O365 platform.
Round 2
After a frustrating afternoon exploring the lack of cohesion with M$ products, I decided to regroup and incorporate a couple of tools we had already been using on our intranet - Freshdesk and Gravity forms.
The word convoluted comes to mind and I found myself questioning the use of Office 365 entirely for this process. However, by creating this birds nest of an integration we get the following benefits:
- A feature rich support desk (Freshdesk)
- A shared calendar (Outlook) and work schedule (Planner) that allows tasks / tickets to be assigned to staff without everyone needing a Freshdesk seat.
I won't go into detail on how to push Gravity Forms requests into Freshdesk but you can either do a custom integration using the API's or just use a product like Zapier to build the connection and map your fields into the Freshdesk ticket.
Using the Flow module for Freshdesk, I pushed the ticket into a planner task with the following process:
When a ticket containing the specific subject, in my case 'Support Request' is created:
...create a task in Planner. The key here is to first create the task, then wait at least five seconds so that we can access the task by the id. If we don't give it a bit of time, Flow cannot find the task and the workflow ends (which seems like another M$ shortcoming).
In order to get the body of the request to display properly, I used the HTML to text module to convert our HTML ticket description into plaintext, which can then be added to the task description.
The end result is a task that can be assigned to any O365 user and a shared calendar that will display in both the Planner Schedule tab and in the users Office 365 calendar.
This is by no means an ideal solution but it works. Hopefully M$ gets their shit together on this so we can build cleaner workflows within Office 365.