Power Automate: Planner – When a task is assigned to me Trigger

The “When a task is assigned to me” trigger does something that most don’t. It reacts to changes in all Planner Plans and not only one. Think about it. For example, in SharePoint’s “When an item is created” trigger, you need to define the list you want Power Automate to look at. But here, you only specify the trigger, and you’re done.

Let’s see how to use it efficiently.

Where to find it?

To find it, you can search for “When a task is assigned to me” trigger or select “Planner.”

Select the trigger.

Here’s what it looks like:

Nice! Nothing to configure.

Usage

The Flow works automatically when a user assigns a task to you.

That’s it—nothing to think about.

Outputs

The “When a task is assigned to me” trigger returns a lot of information in a JSON format, although the conversion from JSON is done automatically for you. Here’s an example:

{
  "headers": {
    <redacted>
  },
  "body": {
    "@odata.etag": "W/\"JzEtQEBAQEBAVGFzayAgQEBAQEBAQEBAVCc=\"",
    "planId": "faxNGpZc-u2VpSzbK60CQcvAHT7g",
    "bucketId": "m6cAOk7LLj75O0VhHwIEanz4KXO5",
    "title": "teste",
    "orderHint": "8585731614502726645P2",
    "assigneePriority": "8585432804535053657",
    "percentComplete": 0,
    "createdDateTime": "2021-08-08T17:58:15.2830397Z",
    "hasDescription": false,
    "previewType": "automatic",
    "referenceCount": 0,
    "checklistItemCount": 0,
    "activeChecklistItemCount": 0,
    "priority": 5,
    "id": "-kyg5MWW79Exop6ZcAB7mnMZ1CFk",
    "createdBy": {
      "user": {
        "id": "b6a19137-2a63-4713-b3b9-1a43ba4739fb"
      }
    },
    "appliedCategories": {},
    "assignments": {
      "fb698a5a-c15c-4dff-bba1-4d55bf79f010": {
        "@odata.type": "#microsoft.graph.plannerAssignment",
        "assignedDateTime": "2022-07-20T14:13:51.972215Z",
        "orderHint": "8585432805135991253P@",
        "assignedBy": {
          "user": {
            "displayName": null,
            "id": "bc031a0a-9e17-4b7d-997f-7922d62fc3bb"
          }
        }
      }
    },
    "_assignments": [
      {
        "userId": "fcaee23e-00d2-482f-a1c7-c268479145eb",
        "value": {
          "@odata.type": "#microsoft.graph.plannerAssignment",
          "assignedDateTime": "2022-07-20T14:13:51.972215Z",
          "orderHint": "8585432805135991253P@",
          "assignedBy": {
            "user": {
              "id": "9e6d16c2-1521-41ad-88ac-09dd962d7295"
            }
          }
        }
      }
    ]
  }
}

We’ll ignore the headers since they don’t have much helpful information for us. There’s a lot of information here that is useful to us, but I always recommend that you pick them from the dropdown.

I only include the JSON here so that you’ll know the names of the fields in case you have to do a function with the data.

You can pull from all fields in a task except:

1. Bucket – you only get the ID if you want information about the bucket; you need to use the “List Buckets” action and match the ID.
2. Description, tasks, and references – you need to fetch them using the “Get task details” action to get it.

It works quite the same way as the “Get a task” action, where only part of the fields, but you can do a lot with the ones you have.

Limitations

There’s a huge limitation in the “When a task is assigned to me” trigger when it comes to labels. If you have a different name for a label, the label will always show up in Power Automate as the color of the label and not the description. For example:

Here’s the label.

Here’s the result.

This behavior is for the whole Planner’s actions and triggers, so I would like you to be sure that you know about it.

Recommendations

Here are some things to keep in mind.

Name it correctly

The name is super important in this case since we can get the trigger from anywhere and with anything. Always build the name so that other people can understand what you are using without the need to open the action and check the details.

Always add a comment

Adding a comment will also help avoid mistakes. Indicate what you’re expecting, why the Flow should be triggered, and what the data will be used. It’s essential to enable faster debugging when something goes wrong.

An automated trigger is better than a scheduled one

Sometimes people are tempted to use scheduled triggers that pool the resources once in a while. This way, they can control when the information is fetched and save much Power Automate “triggers” if their quota is low. However, even if it isn’t, it may be more efficient to do batch tasks than once by one. I understand, and in some cases, I can agree, but it brings a lot of difficulties in the process. For example, you may need to keep track of what changed from the last run until this one so that some things may get lost. Also, you’re forcing something to happen periodically, even if there’s no data.

I always recommend using these “automatic” triggers instead, where they trigger one by one, but only when there’s data, so you’re always sure you get something to do. Also, debugging triggers that parse a single data point instead of multiple simultaneously is much easier. If something fails on one, then you can fix the Flow and repeat the process. But while parsing multiple ones, things can get a lot harder.

Back to the Power Automate Trigger Reference.

Photo by Elena Mozhvilo on Unsplash