Hi WF Community - My team's instance is very task and project oriented, and never use requests. I'd like to know the benefits or purpose of requests or issues, and why they're better than just having people assigned in tasks within individual projects?

[ToddFr]

Benefits of requests instead of just having people assigned to tasks.

[TealeMcCleaf]

Hi Todd -

Queues are useful when you have people across the organization that need to submit a request for work to be completed. The work is probably not being performed by someone on their team as well. For example, you could create a request queue for New Hires. The intake can include all of the particulars about onboarding a new employee from HR paperwork to what type of laptop or computer/monitor the user will be assigned. That request can automatically inform the team of individuals that perform those tasks regularly and one individual from the team can assign themselves to the task to indicate they've taken ownership of the work.

When the work is completed, the paperwork could be attached via a link to show it's complete. The equipment assets can be documented and replacement timing can be tracked. Then you can build reports that automatically notify teams or individuals for when an equipment refresh needs to take place, etc.

Hope this helps,

Teale

[skyehansen]

Tasks and Issues are different objects with different capabilities. They would / could cover two different kinds of work.

First, some basic definition.

Think of tasks as "planned work". Tasks frequently show up for us in project templates or as part of a larger project. They are linked together in some way (we're working on a set of tasks to bring a project to fruition).

Think of issues as "ad hoc work" -- i.e. unplanned work. e.g.1 Issues frequently crop up in the middle of a project. You probably weren't expecting that the designer can't get their work done because the custom form on a project didn't get filled out. e.g.2 To Teale's point above, teams rarely hire employees on demand, so you probably don't have a project with tasks every week for onboarding the new hire of the week. But... whenever it is that a new hire DOES get hired, someone can submit a request.

Second, let's consider complexity.

Tasks can be linked together. You can keep expenses on them. You kind of need a paid license to effectively set up tasks.

Issues are much much simpler. You definitely can't have sub-issues within an issue. On the other hand... anyone can submit an issue/request.

In many companies, the user breakdown is usually along the lines of 75% free licenses and 25% paid licenses. What are my 75% free license holders in the system doing? Usually, they're initiating a work request or reviewing proofs.

When my company is happy with their projects and tasks, this is when we look upstream and try and get the work into the system even sooner. This is where the request can really come into play as a way of marking a placeholder for future work to be assessed. Again, using Teale's example: HR wouldn't get into the system, create a project and assign tasks to IT to order and setup a laptop. IT will do that, as long as HR just tells them who and when.

You didn't ask, but the major down side of working in requests and tasks at the same time comes because many users have custom reports they like to refer to, and there aren't any reports that are able to combine reporting requests and tasks AND sort by due date.

[Doug_Den_Hoed__AtAppStore]

Thanks Skye,

Fabulous dissertation on Tasks vs Issues, with which I heartily concur, and have nothing to add (other than it is now pilfered, secured in my vault, and saved until needed).

Regards,

Doug