Newbie question about tasks

[davidt38509154]

Apologises if this is not the correct area to ask the following. I have trying to get my head around the functionality of WorkFront and then how best to implement it within our company. What I would like is to have a project that cover any small website content changes for the whole of 2018. Then any requests from the wider employees within our company made using an online form be automatically inserted into that project as a Task. The tasks can then be 'worked on' by the web team and when completed closed. I imagine that the % completion of the overall project will fluctuate both up and down as both tasks are completed but also when new tasks are added. The project as a whole would be closed off at the end of 2018 and a new project created for 2019 and then any new small website content change requests be added as tasks to the 2019 version. Understand my terminology may not match that of WorkFront but hopefully you can understand my question. Many thanks in advance David T

[AdinaPi1]

We do this, except we create the "Catch All" project on a quarterly basis. The project starts out with tasks that span the quarter, such as reporting, meetings, data integrity, etc. and if any new small request comes into the team (one that doesn't warrant its own project) we just convert the issue to a task on the project. We don't worry about the percent complete on the project, I just ignore it. Adina

[davidt38509154]

Thanks Adina, will look into using issues, sounds like this is what we need. David T

[NikFr]

Issues have some idiosyncrasies that may make you want to use tasks instead. If you do, you could create a project that everyone's permitted to create tasks in, and then those tasks can be variously "groomed" and moved even to other projects. You're sort of re-creating issue queues this way, but there are many good reasons to limit yourself to tasks for certain workflows and/or reporting needs. Nik Friedman TeBockhorst Engrain

[AdinaPi1]

I want to clarify that we have a request queue for support, and when someone puts in a request, that creates an issue. We then convert that issue to a task in the master quarterly project (and keep the issue for correspondence with the client, since we don't give them access to the task). Adina

[davidt38509154]

Thanks for your help so far. As a test I have configured a queue setup against my project using the standard fields with the request type as request. I am not using a custom form, to ensure the number of fields is not overbearing for the user. This creates any requests as issues on the project. I then rename the issue to include the Ref number and then convert to task. I need to manually change dates but the admin is quite minimal. I will look at going down the task creation route as opposed to the issue route. David T

[JillAc]

The Project that is setup with the Queue that "catches" your Issues can be the repository for all the requests submitted via the Request tool, if none of the requests require a separate Project with multiple tasks. That is how our web and video teams work since they don't want to be bothered with breaking out each thing into multiple tasks, so in essence they only work from one master Project that is populated with Issues. Issues and Tasks look a lot alike, so test this a bit before you decide how to manage them.