Most of the time, the “Get a task” action is used with the “When a new task is created Trigger” because the trigger won’t return any details; we need an action that will fetch the information.

Where to find it?

To find it, you can search for the “Get a task” action.

Here’s what it looks like:

Pro Tip: Power Automate tends to save the most common actions in the main screen, so check there before going trough the full hierarchy. Also you can use the search to quickly find it.


Like mentioned before, the planner’s “Get task” action goes along with the “When a new task is created” trigger. We’ll use a task from the dropdown to test this action, but it will be quite common for you to use the ID instead.

We’ll get the following information:

  1. ID
  2. Title
  3. Created By User Id
  4. Percent Complete (0 to 100)
  5. Start Date Time
  6. Created Date Time
  7. Completed Date Time
  8. Due Date Time
  9. Has Description
  10. Assignments
  11. Plan Id
  12. Bucket Id
  13. Reference Count
  14. Tags

There’s one that is missing from this list, and it’s the “Priority.”

I’m sure there’s a good reason for this, but you can’t get it with the “Get a task” action for now. Let’s explore the ones we get.


All dates are returned in the ISO format, including milliseconds. For example:


The format can be confusing to many, but Flow does an amazing job of converting the date to something you can understand based on your preferences.


The tags are still a week spot for all actions related to Planner. All of them are individual returns by the color name, even if you rename them.

There are other examples, such as the references or checklist items in the “Get task details” action, where we get an array with the selected ones. In this case, we need to know the tag we’re looking for and check if the tag was assigned (the value is true or false). Of course, if we want the list of tags, this will be unnecessarily cumbersome, but I’m sure this will change in the next version of the action.


The percentages are returned with a 0 to 100 instead of the common 0 to 1 scale. This makes things easier to understand since we display the value without converting it.

Has description and Reference Count

I love the inclusion of these two fields. Without us needing to run the “Get task details” action, they will indicate if we have information in these fields. It’s super useful, but it’s a pity that we don’t have one for the checklist items also.


Tasks can be assigned to multiple people. This field can be quite complex to understand since it will return a complex object. For example:

    "userId": "<redacted>",
    "value": {
      "@odata.type": "#microsoft.graph.plannerAssignment",
      "assignedDateTime": "2021-04-25T18:19:46.9749115Z",
      "orderHint": "8585717240476885258PU",
      "assignedBy": {
        "user": {
          "id": "<redacted>"

If you want to get more information, you can always use the “Get user profile” action using the ID as a reference.


As mentioned above, the tasks have more information than the one returned here, like:

  1. Description
  2. References
  3. Checklist items

To get this information, you need to use the “Get task details” action. Strangely, Microsoft decided to break the task’s information into two actions, but I’m sure that there’s a good reason for this. I like that we get less information by the task to run faster, but having all in one action would also be convenient.


Here are some things to keep in mind.

Never generate the ID yourself.

Always get the ID either from a trigger or from another action. Never try to generate the ID yourself since they may change, and then your Flow will fail.

Name it correctly

The name is super important in this case since having only “get a task” doesn’t tell us much. Always build the name so that other people can understand what you are using without opening the action and checking the details.

Always add a comment.

Adding a comment will also help to avoid mistakes. Indicate where the task that you’re trying to get (or the context). It’s important to enable faster debugging when something goes wrong.

Always deal with errors.

Have your Flow fail graciously when the task doesn’t exist and notify someone that something failed. It’s horrible to have failing Flows in Power Automate since they may go unlooked for a while or generate even worse errors. I have a template, and a template that you can use that will help you make your Flow resistant to issues. You can check all details here.

Am I missing something? Leave a comment or interact on Twitter. Let’s work together to make this reference as complete as we can

Back to the Power Automate Action Reference.

Photo by Torbjørn Helgesen on Unsplash

Manuel Gomes

I'm a Project Manager with experience in large projects and companies. I've worked in the past for companies like Bayer, Sybase (now SAP) and I'm currently working for Pestana Hotel Group.

View all posts by Manuel Gomes →

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: