A common question we receive is how to structure and organize your work in OneDesk. OneDesk allows for tremendous versatility in how you work, and every business will have their own workflows. The first step in determining how to organize your work is to get an understanding of the structure of OneDesk. We want to help you make the most of your options and organize your work logically. In this article I’ll go over some best practices and common configurations. Remember that over time you can move items and create new organization levels. Useful features like ‘move to folder’ or macros make this pretty straightforward, so don’t worry! 🙂
Table of contents
- Hierarchy of work in OneDesk
- Common questions
- How should I use projects for tickets?
- Are customers in projects?
- Are users in projects?
- Example work structures
- Organize by department or location
- Organize by release/version
- Organize by client/customer
Understanding hierarchy of work in OneDesk
Portfolios
Portfolios are optional but recommended. Portfolios are the ‘top level’ of organization – containing one or many projects. Portfolios are like folders, they are simple objects used to create structural hierarchy and divide projects. Often portfolios come to represent different departments, clients, or releases. We will see examples later.
You can also use sub-portfolios, a portfolio within a portfolio, to further divide projects.
Projects
Projects contain ‘items’ – tickets and tasks. Projects are more ‘complex’ objects and can be used for planning, tracking, organizing and dividing work. For this article we will focus on the last two aspects.
Organizing work – Projects should contain all the tasks and/or tickets related to, or needed for the completion of the project.
Dividing work – Projects are shared with users, typically on a per-team basis. If a project is NOT shared with you will not see this project or the items within it. If you want to keep work separate between teams or departments, projects are a good method of doing so. (Learn about sharing: Sharing with Users & Teams).
Tip: declutter your account occasionally by archiving projects.
Folders
Folders are used to break up a project. Like portfolios, they are simple objects used to group or divide up work. Folders contain tickets or tasks.
Items – Tickets and tasks
Items are the smallest thing you work on – tickets and tasks. These are contained in projects. The only exception is the ‘outside of projects’ section. Theoretically you can put all items here but there are some downsides. For instance, tasks here cannot have schedule constraints, there are no project roles/permissions, and over time it might get messy.
How should I use projects for tickets?
Projects can be used like ‘boxes’ or containers for organizing or dividing tickets. For example, you can use projects to separate tickets based on departments, quarters, teams, or other concerns. This is especially helpful if you have multiple departments using one account. Each department may only need to see their own projects. So this simplifies and streamline their workflows. Using projects for tickets is helpful long term as well for:
- Organization – For example, you might have tickets in a project designated for a certain release, version number, quarter, so on. This allows you to easily see what issues are happening within the given release, quarter, etc.
- Reporting – While you can filter to pretty much any property in your reports, projects allow for another level of grouping or filtering. So like above if you want to see a report of tickets for a certain release, simply select that release project.
How do work views interact with my structure?
Your defined hierarchy is seen in the ‘Folder Tree’ of the tickets or tasks app, the project scope selector, or the ‘By Portfolio’ view of the projects app. Work views are different ways of viewing and interacting with your data. For example ‘Flat’ displays your tickets, tasks, etc., as a list with no hierarchy displayed. While the ‘Status Board’ is a Kanban board view that allows you to easily see the status of tickets or tasks and update the status with drag and drop. So while you do not necessarily see the hierarchy in all views, it is there! (Learn more about views: Custom work views).
Are users in projects?
Users exist in teams. Projects are shared with a user or team. If a project is not shared with someone, that project (or any items within it) are NOT visible to that user. As touched on above, this is one of the benefits to using projects. If two separate departments are using one account you can separate their concerns by using projects.
Are my customers in projects?
Not exactly! Individual customers are contained within organizations. However projects can be shared with individual customers or customer organizations. In this case the project is associated with the customer. So, the ‘By Customer’ view in your projects application is grouped by the organization associated with the project. You can also open the project detail panel and see if the project is shared with a customer.
Depending on your portal settings, customers can see items in the project. They will receive public messages posted on the project. (Learn more about: Sharing with Customers.)
Common Account Structures – Examples
Now for the examples!
Organize by department portfolios
A common configuration is creating portfolios to represent different teams or departments. Within each portfolio are the various projects the team is working on. Remember for this configuration, you can choose to share only relevant projects for each department. In this way each department will only see their own projects/portfolio.
A similar configuration I’ve seen is using portfolios to represent locations for companies with offices in various countries. You can use sub-portfolios to further divide departments or locations. For example, below the ‘EU Office’ has both ‘Sales’ and ‘Admin’ sub-portfolios to further organize their projects.
Organize portfolios for releases, versions, iterations
If you are in product or software development, or another industry with a similar methodology, a common configuration is creating portfolios to represent releases or versions. Within each portfolio are the various requirements of the release. You might funnel tickets for bugs, feedback, etc., into a designated project for each release. It is possible to move folders to different projects or projects to a different release portfolio when necessary.
Portfolios per client, vendors, end-users
If you work on one or multiple projects for several clients this might be the configuration for you. This approach is popular for industries such as consulting, marketing, and design. For example, below my portfolios represent the clients I work for with each of their projects within.
Below is a slightly more complex version. Here I have sub-portfolios under each client portfolio to group together the type of projects I perform for each client.
Need more advice on setting up your account? Check out our knowledgebase and related articles or reach out to our support team!