Workflows standardisieren » History » Sprint/Milestone 1
Thomas Carney, 05/25/2016 04:59 PM
1 | 1 | Thomas Carney | # Create a custom workflow for recurring tasks |
---|---|---|---|
2 | |||
3 | Planio is not only great for [one-off projects](https://plan.io/project-management/). It really shines when it comes to [recurring tasks](https://plan.io/task-management/) that follow a certain workflow within your organization. |
||
4 | |||
5 | Follow along this guide to create a simple vacation approval workflow for your team members - and apply what you've learned to create your own custom workflows. |
||
6 | |||
7 | {{>toc}} |
||
8 | |||
9 | ## Planio workflow basics |
||
10 | |||
11 | In Planio, every issue must belong to a tracker which defines its workflow. Let's look at this in more detail: |
||
12 | |||
13 | ### Trackers |
||
14 | |||
15 | We'd like to see trackers as special issue types. An issue must belong to exactly one tracker. **Task**, **Support incident**, **Software bug**, or -- you guessed it -- **Vacation request** would be great examples for a tracker. |
||
16 | |||
17 | ### Issue statuses |
||
18 | |||
19 | Issue statuses describe the different states, that an issue in Planio can have at any given moment. For instance, an issue can be **Open**, **In progress**, **Waiting for review**, or **Closed**. An issue will always have exactly one status and the status will likely change over time as people work on the issue. |
||
20 | |||
21 | ### Roles |
||
22 | |||
23 | Users in Planio have their own user account using which they take part in projects using one or more roles: While some users may take part as *Manager*, others may be regular *Staff* or e.g. *Client*. The role defines what a user can and cannot see or do in a given project. It also defines the user's workflow. |
||
24 | |||
25 | ### Workflows |
||
26 | |||
27 | The workflow brings it all together: A workflow defines for every possible combination of tracker and role which issue statuses are available. It defines for all its tracker's issues which status changes are allowed and which issue properties are visible and/or changeable. |
||
28 | |||
29 | Say what!? This is arguably the most complex (and powerful) part of Planio, but don't worry -- we will walk you through it and you will be a workflow expert in no time! |
||
30 | |||
31 | ## Technicalities of going on a vacation |
||
32 | |||
33 | We knew you would love this section. Dreaming of that deserted beach in the Caribbean? Let's request some vacation days and off we go. |
||
34 | |||
35 | In many companies, taking a vacation requires approval by a manager. Employees must submit a request mentioning the start and end date of the requested vacation and managers will approve or disapprove the request. Upon approval, the dates of that vacation can not be altered, and the vacation request is final. If disapproved, employees can alter their requested dates and re-request approval until -- hopefully -- they will be allowed their well-deserved days in the Caribbean. |
||
36 | |||
37 | We will now build this workflow in Planio allowing for actual vacation requests being made and approved. We will also show you how to visualise them on Planio's calendar, so you can get a great overview on who is on vacation at which point in time. |
||
38 | |||
39 | ## Tracker, Statuses, Roles, and Workflow |
||
40 | |||
41 | To implement this, we will create a **Tracker** called *Vacation request*, three **Issue statuses** called *Open*, *Approved*, and *Rejected*, and two **Roles**, called *Manager* and *Staff*. |
||
42 | |||
43 | Finally, we will tie all those together using a custom **Workflow** in Planio. |
||
44 | |||
45 | ### Create the tracker |
||
46 | |||
47 | First things first. Let's get down to business: |
||
48 | |||
49 | - Navigate to **Administration** -\> **Trackers**, then click on **New tracker**. |
||
50 | - Enter *Vacation request* as **Name**. |
||
51 | - Uncheck the **Issues displayed in roadmap** checkbox since we do not want to see vacation days on our project roadmaps. |
||
52 | - Uncheck all **Standard fields** checkboxes except the ones for **Start date** and **Due date**. We'll actually use those for the start and end of our vacations. |
||
53 | - Do not select anything in the **Copy workflow from** drop down. |
||
54 | - Click **Create**. |
||
55 | |||
56 | ![](creating_a\_new_tracker.png) |
||
57 | *Your tracker should look like this.* |
||
58 | |||
59 | ### Create issue statuses |
||
60 | |||
61 | The steps are similar but slightly different for the three statuses *Open*, *Approved*, and *Rejected*. |
||
62 | |||
63 | - Navigate to **Administration** -\> **Issue statuses**. |
||
64 | - Do you see a status called *Open*? Great, click on it, and make sure that the **Default value** checkbox is checked. This will make *Open* the default status that's always the first status for a newly created issue. |
||
65 | - Do not see the status? Simply click on **New status**, enter *Open* in the **Name** field, and check the **Default value** checkbox. Uncheck the **Add to all workflows** checkbox since we only want it for our *Vacation request* workflow. |
||
66 | - Click on **Save** or **Create** respectively. |
||
67 | - Create the remaining statuses *Approved* and *Rejected* following the same pattern and make sure the *Approved* status has the **Issue closed** checkbox checked. Do not check the **Default value** checkbox for *Approved* and *Rejected*. |
||
68 | |||
69 | ![](create_an_issue_status.png) |
||
70 | *This is what your "Approved" status will look like.* |
||
71 | |||
72 | ### Create a role |
||
73 | |||
74 | This one should be easy: |
||
75 | |||
76 | - Navigate to **Administration** -\> **Roles and permissions**. |
||
77 | - Do you see the roles *Manager* and *Staff* already? Great. You're done with this step. Those are actually the two basic roles your Planio account came with. |
||
78 | - Do not see the roles? Create them by clicking on **New role**. Enter the role's **Name** and ignore the rest for now, just be sure that the check boxes for permissions **View calendar**, **Edit issues**, **View issues**, and **Add issues** are checked. Repeat this for both the *Manager* and *Staff* roles. |
||
79 | |||
80 | ![](how_to_add_a\_role.png) |
||
81 | *Adding a role* |
||
82 | |||
83 | ### Define the workflow |
||
84 | |||
85 | This is the fun part. Here is where it all comes together. |
||
86 | |||
87 | - Navigate to **Administration** -\> **Workflow**. |
||
88 | - Select the *Staff* role and your *Vacation request* tracker. |
||
89 | - Uncheck the **Only display statuses that are used by this tracker** checkbox and click on **Edit**. |
||
90 | - The checkbox matrix that appears lets you configure all allowed status transitions for a given role and tracker. For instance, the *Staff* workflow should have the checkbox at the lower left checked. This means that members having the role *Staff* can set an issue having a **current status** of *Rejected* back to *Open*. |
||
91 | - Now, let's configure the *Staff* workflow according to the following screenshot: |
||
92 | ![](vacation_request_workflow_for_staff.png) |
||
93 | *Workflow for Staff role* |
||
94 | - Click on **Save**. |
||
95 | - Next, select *Manager* as a role, make sure the **Only display statuses that are used by this tracker** checkbox is unchecked click on **Edit** again. |
||
96 | - Configure the *Manager* workflow according to the following screenshot: |
||
97 | ![](vacation_request_workflow_for_manager.png) |
||
98 | *Workflow for Manager role* |
||
99 | - Click on **Save**. |
||
100 | |||
101 | Wait, what did we just do? Have a look at the screenshots again. What we defined is: |
||
102 | |||
103 | - *Managers* can set an open vacation request to *Approved* or *Rejected* and a *Rejected* vacation request to *Approved* (in case they changed their mind). |
||
104 | - *Staff* can only set a *Rejected* vacation request back to *Open*. (This is for when they change their dates and want to re-request approval.) |
||
105 | |||
106 | ### Adapt fields permissions |
||
107 | |||
108 | Now, let's customize the issue form fields a bit according to the issue status. |
||
109 | |||
110 | - Still on the **Workflow** screen, select the **Fields permissions** tab. |
||
111 | - For *Manager*, set everything to *read-only* except the **Subject**: |
||
112 | ![](fields_permissions_manager.png) |
||
113 | *Fields permissions for Manager role* |
||
114 | - For *Staff*, do the same except for the **Start date** and **Due date** fields: |
||
115 | ![](fields_permissions_staff.png) |
||
116 | *Fields permissions for Staff role* |
||
117 | This makes sure only *Staff* can actually set the dates for a vacation request and that those dates cannot be changed anymore, once approved. |
||
118 | |||
119 | ## Put it all to work in an actual project |
||
120 | |||
121 | That's enough of prep work. Let's try it out. |
||
122 | |||
123 | - Start by creating a new project via **Projects** -\> **New project**. |
||
124 | - Give your project a name, e.g. **Vacation planning**. |
||
125 | - Disable all modules but **Issue tracking** and **Calendar**. |
||
126 | - Select only your **Vacation request** tracker and nothing else. |
||
127 | - Click **Create**. |
||
128 | |||
129 | That's it, you're done. Your users can now use this project for your new vacation request planning workflow. In order to submit a vacation request, all they'd have to do is create a new issue. Selecting a **start date** and a **due date** will be required when creating *vacation request* issues and all other useless fields will be hidden. |
||
130 | |||
131 | ![](new_issue_form.png) |
||
132 | *Stripped down issue form for vacation requests* |
||
133 | |||
134 | In order to try it out for yourself and play around with it, we recommend you create two users that have no administrator privileges and add the as *Staff* and *Manager* to your project respectively. |
||
135 | |||
136 | (If you try it out as an administrator, don't be alarmed by the fact that you can always choose from all statuses when updating an issue. That's normal if you're an admin. Regular users will only see the statuses as defined by their workflow.) |
||
137 | |||
138 | ### Bonus: The calendar view |
||
139 | |||
140 | What's up with the **Calendar** module we've enabled in the roles and your project, you ask yourself? Well, after adding a couple of vacation requests, check out the **Calendar** tab in your project. The Planio calendar will give you a nice monthly overview of all vacation requests which have been tracked. |
||
141 | |||
142 | ![](vacation_calendar.png) |
||
143 | *Vacation calendar view in Planio* |
||
144 | |||
145 | By using a [custom query](http://plan.io/blog/post/25072622222/trackers-viewing-and-grouping), you can even create a calendar view that displays only approved vacation requests. Or create a query for your managers that shows only *Open* requests that have to be approved still. |