Project

Profile

Help

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.