Tip: Find Hidden Personal Microsoft To Do Capability in Power Automate

Way before Microsoft had a fully-fledged Outlook and Microsoft To Do app for iOS and Android, there were two apps that tightly integrated with each other to form an absolute machine in productivity – Sunrise and Wunderlist.

Tasks would show as ‘All Day’ items at the top of your calendar, with ticks next to each one completed as a frequent reminder of progress as you check your calendar for the seventeenth time during the working day.

A digitally produced image of Sunrise Calendar with Wunderlist Integration on an iPad
Sunrise Calendar with Wunderlist Integration on an iPad

Microsoft bought both of those products and that’s how we arrived at Microsoft’s eventual Outlook Tasks replacement and the ability to add third party calendars to our Outlook with ease, but not all features were migrated easily, and I have always wanted a replacement, but never found one.

By using the Power Platform, we now have the ability to bring together the capabilities of personal Microsoft To Do with Outlook, and any other service is hidden within the Outlook Tasks Connector within Power Automate!

Simply search for the Outlook Tasks when creating a flow, and once you’ve chosen your trigger or action, you’ll be able to see your tasks.

A screenshot showing the selection of a Microsoft To Do list in Power Automate via the Outlook Tasks Connector
Selecting a Microsoft To Do list in Power Automate via the Outlook Tasks Connector

I’m unsure on when exactly this feature became available for personal accounts, but Microsoft To Do with business accounts has been available for a while under it’s own Connector.

What’s the catch?

As with a lot of early Connectors that have since had iterative updates in Power Automate, not all actions are built consistently.

A screenshot showing a list of some of the available Actions within the Outlook Tasks Connector.
A list of some of the available Actions within the Outlook Tasks Connector.

We also have to bear in mind that Microsoft To Do and Outlook Tasks are built on entirely different architectures where functionality has merged over the years, and therefore there are several fields available that may not directly align to what you expect, particularly when trying to use the data you’ve received in another Connector.

Having said all of the above, once you have established the correct Dynamic Values and the correct Actions to use, the connector is extremely reliable and hasn’t failed me yet in any working examples.

References

Microsoft Docs: Outlook Tasks Connector

Microsoft Docs: Microsoft To Do (Business) Connector

Translating Unknowns into Tangible Requirements

For me, the most exciting part of a project is the challenge of figuring out exactly what a client is asking for based on a very short brief provided in an introductory call.

This challenge is increased in my industry when you move from Dynamics 365 based projects to pure Power Platform projects, because you move away from a functionally built system, to a set of tools that enable the capability. Not only do we now have to qualify the tool, but we also need to qualify the business process at an earlier stage than we typically used to, as well as the full data model.

For example, a “helpdesk replacement tool” screams Dynamics 365 Customer Service, and consultants in the industry typically understand the core operational processes before they speak to a customer. On the Power Platform, however, no two ‘self-serve chatbot’ projects would ever be the same, and there’s no functional process that you can align to this.

So how do we quantify projects with so many unknowns when we need to fully design the data model, the user interface, and the functional process? One way to start is to look for three themes:

  • Trends
  • Assumptions
  • Caveats

The first consideration I make is whether there are any repeatable components for any given high level requirement.

Whilst this doesn’t necessarily give us the full requirement ready to build, it does give us an idea of the size of the scope in contrast to a solution that is easier to estimate. Let’s take the idea of implementing a chat bot for a client on their website.

As a website user, I want to be able to engage with a chatbot, so that I can easily find out store opening times and current stock levels.

Within the industry I work in, we know that a configurable Power Virtual Agent for Teams solution that only uses Entities is relatively straight forward, and doesn’t require code. The interface used to build the solution is entirely controlled by Microsoft, so we also have confidence that it works! Let’s now put our original requirement into context by using known unknowns:

  • We know that the client cannot deploy this through Teams, but we don’t necessarily know exactly how to deploy it through a website that we don’t control just yet.
  • We are not being asked to build their website and we don’t know what their data source is, but we do know that we can take advantage of data and automation services that we can control to make this easier, perhaps Microsoft Dataverse with some sort of movement of data via Power Automate?

We now have broken down the requirement into tangible considerations and we can justify risk and complexity based on what we do know and what we can control, so we should factor this in to our estimate right from the beginning.

As a website user, I want to be able to engage with a chatbot, so that I can easily find out store opening times and current stock levels.

Trends:

1. Power Virtual Agents for intelligent chatbot functionality.

2. Power Automate to drive dynamic data interactions between end user and data source.

3. Dataverse to assist with controlling data where necessary.

Assumptions

Next up, assumptions. We are often taught that making assumptions is a bad thing, and in most cases that is correct, but assumptions can be extremely powerful when defining a requirement if used correctly.

Taking our earlier example of a chatbot being deployed via a client’s website, we really don’t want to be developing the website in unfamiliar territory, nor do we want run into any bumps if their data source isn’t fit for purpose. For now, we can set assumptions against our requirement to portray what we would typically expect within the client’s landscape, and if any of these are found not to be true, then we can justify a change in direction for a requirement through a change of scope, estimate, and change request!

As a website user, I want to be able to engage with a chatbot, so that I can easily find out store opening times and current stock levels.


Assumptions:
1. Assumes that the client’s existing data model is fit for purpose, and if any changes should be made, the client will take responsibility for these.

2. Assumes that the solution can be deployed using a embedded HTML code snippet, as per Microsoft’s standard approach.

Caveats

And last but not least, we have caveats. Clients may see these as the supplier creating ‘get out of jail free’ cards, but in reality, these are to ensure that everyone involved understands what should happen in the event that one of these factors occurs. Caveats are usually based on assumptions, but can extend further than this to cover typical project factors too.

As a website user, I want to be able to engage with a chatbot, so that I can easily find out store opening times and current stock levels.


Caveats:
1. If the data source should change after delivery, the client will be responsible for a change request for any errors that may occur with this solution if they wish to continue using the functionality.

2. If the client’s website cannot support HTML snippets for any given reason, the project may need to be delivered via a Power Apps Portal, which would incur extra cost to ensure the delivery is built to the correct standard.

Summary

When I describe this way of working with my team, I reference a phrase that may be familiar to some – It’s about the journey, not the destination. Imagine you have a 100 mile journey to make with no map functionality, digital or print. What would be your first move?

Success isn’t just the destination, or the solution in this case, it’s the route to it and the service provided along the way that counts. This continues to be a significant theme throughout the whole lifecycle of the project, and it can make or break the final engagement with the software.