Your community has just come up with some new champion campaigns to drive awareness and new adoption scenarios, how is the best way to communicate out the action items for the new campaign and track the status? With task publishing you can now send out tasks to a variety of teams and have those tasks tracked centrally for assignment and completion. We think you will really be able to see the power of this versatile new option for several different examples. Let us dive into a walkthrough talking through this process. Also checkout this article for a simplified walkthrough.
Imagine the scenario above where you have come up with two new campaigns to deliver champion value back into your organization, these two campaigns consist of the following:
Campaign 1: Socially Distanced Lunch & Learns for immersive meetings
Campaign 2: Virtual Team Building: Bingo Squares
Great! You have got some campaigns that your core team has developed and now we want to distribute the tasks for running these campaigns. Enter Task Publishing via Tasks by Planner and To Do in Microsoft Teams to publish your tasks out to the teams responsible for execution.
Task Publishing works off developing a targeting hierarchy for Microsoft Teams to publish content to a large set of teams. The team targeting hierarchy defines how all the teams in your hierarchy are related to each other, which users can publish tasks, and which teams users have permissions to publish. Publishing features are disabled for all users unless a team targeting hierarchy is set up for your organization. To set up a team targeting hierarchy, you will need to create a file that defines the hierarchy and then upload it to Teams to apply it to your organization.
Note that some of these next steps will require some IT Administrative assistance. To publish a hierarchy file, you will need either Global Admin or Teams service admin. See more about the requirements here
Let us have a look at my sample Team environment which will serve as the base of our hierarchy development in this scenario.
In my Contoso organization there are 13 teams for my champion community. I have our topmost team, where I have people from around the organization contributing to ideas, scenarios, etc. – Contoso Global Champions – M365. From there I have regionally established teams that help serve my broader but a bit more specific region of champions (Region 1 / 2 / 3 Champions – M365). Finally, I have teams at each site that my champions there use to discuss specific site needs (these could be large physical locations, central geography regions, etc.), like Site (A – I) Champions – M365.
I have laid out the assumptions of why I have teams organized this way to specifically serve this example. You could apply this to several scenarios, such as in a Healthcare scenario where you are wanting to publish tasks out to a variety of local hospitals or clinics or a Retail scenario where you are providing tasks to a collection of stores.
Now that we have a base for why my teams are thought about in this hierarchy, lets discuss some items we will want to understand around the actual buildout of the hierarchy file – the terminology.
Continuing our example with our distributed champion teams we are applying some Task Publishing terminology to our Teams. A quick note here that any actual Team will be referred to as a node in the terminology.
Each node that we eventually define out in our hierarchy plan will represent a Team that will be designated to receive the tasks that we want to publish.
In our scenario we only have one root node, however we could expand this to encompass many more. In our same examples we could build out a hierarchy file to accommodate for our champion needs as well as other business needs by providing more root nodes and their related dependencies (see below visual to think this process out with a healthcare facility keeping the region to site values):
Now that we have got our mental images of how our hierarchy is set for these scenarios, we need to build out the actual file to support the vision we are laying out. To build out the hierarchy file we will need to use a CSV file and have some required and optional columns to support this. You can find out more information about the requirements here but let’s also dive into them as it relates to our current champions team scenario.
The required fields are DisplayName, ParentName, and TeamId. Additionally there are two types of attribute columns that are supported as well as the notion of bucket columns (for task organization).
This field is the name of the node (team). The name can be up to 100 characters long and contain only the characters A-Z, a-z, and 0-9. Node names must be unique. Note that what you enter here will show up in the publishing menus so if you want them to match your Team names, you should enter the same name here.
This is the name of the parent node. The value you specify here must match the value in the DisplayName field of the parent node exactly. If you want to add more than one parent node, separate each parent node name with a semicolon (;). You can add up to 25 parent nodes, and each parent node name can be up to 2500 characters long. A node can have multiple parent nodes only if the parent nodes are root nodes.
You can also think of the ParentName as organization trees for your teams. Perhaps you want to break up the layout differently on-screen, that can be done here (and shown in the image below)
This contains the ID of the team you want to link a node to. Each node must refer to a unique team, so each TeamId value may appear only once in the hierarchy file.
To get the ID of a team you want to link a node to, run the following PowerShell command:
This command lists the teams in your organization and includes the name and ID for each team. Find the name of the team you want to link to, and then copy the ID into this field.
OPTIONAL | ATTRIBUTE
Each row can contain one value for that attribute, and each attribute column can have up to 50 unique values. Each value can be up to 100 characters long. The set of attribute values you specify in the attribute column will be displayed as filter values for that attribute when selecting recipient teams using the team targeting hierarchy.
In our scenario we will be adding an attribute of Location to better help distinguish our Region areas. This could be any type of grouping we wanted, as well we could apply multiple values.
OPTIONAL | ATTRIBUTE
The text string before the colon (:) becomes the name of the attribute. All columns that contain the same text string before the colons (:) are grouped together into a section in the filtering menu. Each of the strings after the colon become the values for that section.
In our scenario you will see we use this to give ourselves resource filters based on what may be available to a champion group at a particular site or region. They either have the resource, or they do not.
#Name of Bucket
You can add bucket columns to create buckets, which are groupings into which tasks can be organized. Each bucket has its own column in the CSV file. You will not be assigning any row values to bucket columns.
When you add a bucket column, note the following:
Let us look now at my CSV file to get a better understanding of how we are leveraging these values:
You can see I have captured my Teams (nodes) as TargetName in the file that I’ll have represented here for potential task publishing, linked to a ParentName I have determined. For ease of understanding I’ve simply linked my Region Champion Teams into a “regions” and Site Champion Teams into “sites”. Next, I have the ID of the related teams entered. That rounds out my required fields.
Optionally I have included three attribute columns, as well as two bucket columns. Where 1 value in the attribute row is the equivalent of yes and a 0 is the equivalent of no.
Feel free to leverage the snippet below for a simplified starter CSV file that follows the above scenario. Just enter this into a notepad and save as CSV file.
TargetName,ParentName,TeamId,Location,On-Site Assets:Conf Room w/Surface Hub,On-Site Assets:Dining Options, #On-Site Campaign, #Virtual Campaign
Contoso Global Champions - M365,,TEAM-ID,,,,,
Regions,Contoso Global Champions - M365,,,,,,
Sites,Contoso Global Champions - M365,,,,,,
Region 1 Champions - M365,Regions,TEAM-ID,North America,1,1,,
Site A Champions - M365,Sites,TEAM-ID,North America,1,0,,
This will be the part where you will need either a Global Admin or Teams service admin to complete this step. You can refer to more details here. Additionally, you’ll need to ensure (as of this post writing) that you are using the Teams PowerShell public preview module in order to leverage the supported commandlets.
Once you have created your CSV file you need to upload it to Teams. For now only one hierarchy file is supported so you will want to ensure you are incorporating the terminology and hierarchy decisions discussed above if you have multiple areas looking to leverage task publishing.
Run the following command to publish or to update our hierarchy. Updating replaced the old one using the same command:
Set-TeamTargetingHierarchy -FilePath "C:\ContosoTeamSchema.csv"
To see the status and remove your hierarchy please refer to the expanded information located on the docs page here.
Start simple with your sample to get the hang of the creation of the hierarchy file. As we get into the next sections certain elements may not appear if there was an error updating or applying your hierarchy file.
Alright – we have now gotten our hierarchy created, published, and applied to our Teams environment – now onto the fun stuff! The powerful notion of being able to publish tasks to Teams now comes into view as we look to create out tasks based on our champion scenarios we talked about earlier.
Since we have published a Teams Hierarchy, we will now see a new option in Tasks called Published lists which will be empty when we click over to it. Let us go into it and select a new list:
We are going to build out our first campaign (Campaign 1: Socially Distanced Lunch & Learns for immersive meetings). You will notice that we are publishing from the root node we defined in our hierarchy file. Since we only defined one I only have that option, however considering the thoughts above where we had another root node for our hospital locations, we could have multiple options to select here as a home.
Now that we have made our first list we will see it under the drafts column. We can add tasks as you would expect and assign titles, priority, due dates, bucket assignments, as well as additional notes and attachments by clicking in on the tasks.
Let us go ahead and build out our second campaign list - Campaign 2: Virtual Team Building: Bingo Squares
So, we are able to have multiple drafts ongoing at the same time while we build out the tasks that will be associated with each item. We will be assigning these out to our teams we defined earlier so that the teams can all share in completing the same task items while we maintain a centralized view of the progress towards the completion of each.
Depending on the state of your tasks list you can also copy, rename, edit, and delete them. For more information about those actions please visit here. Next, we want to dive into publishing our task list to the teams we identified in the hierarchy earlier.
Now that we have our task list ready let’s go and publish it to the teams we would like to have receive these tasks. To do this we will go back to Tasks, select published lists, select our Draft, and then click on publish to walk through the publishing steps.
What we are doing is publishing all the above tasks into some Teams. We filtered based on their on-site assets and chose to publish to all the region and site teams that were available that matched that filter. At the conclusion we now have that list we created moved into the published category, as well as several received task lists that were inbound since our account is also a member of all these teams.
A user does not necessarily have to be a member of the target team where the list is being published. Let us look at the permissions to publish below, as well you can find out more information here:
Permissions to publish
Permission to publish depends on whether a user is a member of any teams in the hierarchy plus the relationship of that team or set of teams to other teams in the hierarchy.
Note The owner of a team is also granted publishing permission.
Now that we have published our task list for our champion teams lets go see what they see. Ideally, we would expect they can go and work against these tasks – assigning and completing them within their group, and for us to have a view into that centrally within the published list window.
I am exploring Site D Champions and see the following have been populated for me within the team. Keep in mind that how you want to define buckets and other elements during the design phase would also impact on how these tasks are seen and consumed.
I designated the use of buckets to look at the difference between virtual or onsite events. This could be more powerful in these scenarios for the actual campaign buckets of tasks, or even the location avenue. You have a lot of choices in this matter!
I have gone through a few teams now and assigned tasks to some team members as well as mocking the completion of some tasks that were assigned out. Let us see what it looks like back on our dashboard!
I have two powerful views I can swap between here, a task-oriented view so I can see percentage assigned and completed by the task – as well as an all-up team view that shows me the percentage broken out by my regions and sites. Remember in my example my regions are actual teams as well that I have assigned tasks out to. I am imagining them running their own campaigns just like I have asked my site level groups to do. In other scenarios I may not want my hierarchy to break out like this and would instead prefer to depend on attribute filters, etc.
There are some awesome things we can think about doing once we see what tasks publishing is capable of. In my scenario I tried fitting this in with the notion of delivering tasks out to your champion teams. Envisioning you have created the required tasks to complete a certain campaign targeting a champion scenario and easing the distribution of those tasks out to your network just got a whole lot easier.
There is a bit of work to get this initially setup and your hierarchy / buckets / attributes defined to your liking, however once you get those basics completed the practical applications should be numerous for delivering and tracking task list assignments!
Let us know what you think about the feature and how you are thinking about or have leveraged it in our driving adoption forum!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.