by Automation can help us create tasks automatically in Microsoft Planner by using the “Create a task” action. I like this action a lot because it helps me automate the creation of tasks in Microsoft Planner, saving me time.
There are a lot of usages for this action. For example, let’s say that you receive an email in a shared mailbox and want someone from that team to take a look. You can use the “When a new email arrives in a shared mailbox” trigger and create the tasks. You can then check the people in the email and add them to the task to notify them there’s a new task for the team.
There are a lot more, but for now, let’s look at the action.
Where to find it?
To find it, you can search for the “Create a task” action.
Here is how it looks like:
I know what you’re thinking. The label system is a bit ugly. I agree, and this “true/false” system limits a lot of what we can do when adding labels automatically. Also, if you name them something different, the name is not reflected here, so you need to remember that “Pink” is “Backlog” in your Plan. I’m sure that a new version of this action will make things a bit more manageable. For example, we deal with them the same way we deal with references, where we can have a dynamic array with the ones we want.
Usage
To use it you need to define, at least 3 fields:
- Group ID
- Plan ID
- Title
The group and the plan ID are the places where you’ll create the task. You can add “custom values,” but I would strongly advise against it, but more on that in the recommendations below. Finally, the Title indicates what needs to be done.
Start and End date
All dates are returned in the ISO format, including milliseconds. For example:
2021-04-25T18:19:46.9749115Z
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.
Assigned user IDs
If you use other actions, like SharePoint’s “Update item” action, you will notice that they have, what is called, the “Claims” for a person and not the email as in the “create a task” action.
The distinction may be confusing, but it all boils down to how Microsoft Planner works. You can have guest access to your Plan in Microsoft Planner. There are many limitations to what people can do, but you can allow people, with a Gmail account, for example, to access your Plan. Since they are outside your organization, the only identifier you have is the email, hence the difference.
In the case of this field, you need to insert emails using a semi-colon to separate them.
Tags
As mentioned before, in the “Get a task,” action tags are assigned individually. I would like a system like the references or checklist items in the “Get task details” action, where we get an array with the ones that are selected, but this is what we have now.
The system is quite simple. Set to “true” all tags that you want to be assigned to the task, and you’re good to go.
Limitations
Some fields exist on your task that you can’t assign in the “create a task” action, like:
- description
- priority
- progress
- References
- Checklist items
If you want to add them to your task, you need to use the “Update a task” action for the progress and the “Update a task details” action for the description, references, and checklist items. Unfortunately, there’s no way to update the priority yet.
Some consider the title having only 255 characters a limitation. I don’t since even that is quite generous for something to make sense. Suppose you need to be verbose use the description to do it. In my opinion, the title should be as short as possible while being descriptive of the action needed.
Recommendations
Here are some things to keep in mind.
Never generate the Group or Plan ID.
You should never generate IDs manually. I understand that there may be cases where the task may be inserted in one Plan or the other. For example, if you have the same task but could go to a department or another to parse depending on the content. Even in these cases, pick the group and plan manually and generate multiple actions if you have to.
Tools change, and IDs change with them. So you should never have even to know what’s the ID of a Group or Plan.
Finally, having the IDs will make debugging harder because you don’t have the description of the Plan to guide you.
Try to pick them always from the list.
In the same line as above, you’ll always be sure that the permissions are set correctly by picking the items from the list. If you can see it in the dropdown, then you can access them. Again, there may be limitations elsewhere, but at least you have a lot of checks done for you automatically.
Name it correctly
The name is super important in this case since there could be hundreds of Plans in your organization. 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 what’s the plan that you’re inserting data, why you’re inserting it there, and what the rules are. It’s important to enable faster debugging when something goes wrong.
Always deal with errors.
Have your Flow fail graciously 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.
Back to the Power Automate Action Reference.
Photo by Jeswin Thomas on Unsplash
