Project management and help desk

Every project belongs to a group, and one project can be shared across several groups. A chapter, a committee, or a working group runs its own projects without seeing anyone else's.

There are two ways to give people access to a project:

• Invite individual members one at a time
• Give a whole group access in a single action

Group access is how organizations bring a volunteer team into a project without adding each person by hand.

Projects can hold goals, with tasks sitting underneath them. Organizations tracking objectives or the milestones of a funded project use goals as the layer between the project and its individual tasks.

Each project has an overview showing the state of the work across every task, plus an about page describing the project itself for people joining partway through.

Every task carries:

• A title and description
• A checklist of subtasks, each one tickable on its own
• A task type and a priority, from highest to lowest across five levels
• A status
• A start date and a due date, both optional

A task can go to more than one person when it needs input from several. Each assignee's part is marked complete separately, so a task with three owners shows which of them have finished. Members can also assign a task to themselves and track their own work in the same place.

A task can be marked as blocked by another task. Sequential work chains together inside the project rather than in a separate planning document.

Statuses and task types are defined by your organization rather than picked from a fixed list, and each project can run its own set. A grant application moves through different stages than an event checklist.

Each task is its own discussion thread. Comments and file uploads of any type live on the task, so the reasoning behind a decision stays attached to the work instead of sitting in someone's inbox.

The list view puts every task in one table with its assignee, status, and priority visible without opening anything.

Tasks appear as cards in columns by status, and moving a card to another column changes the task's status.

Tasks with a start date and a due date appear on a timeline, showing when each piece of work is expected to run and where two pieces overlap.

Tasks can be grouped by:

• Assignee
• Status
• Type
• Month

Completion rate is tracked per project, so leadership sees how much of the work is done without opening each task.

Your organization defines its own issue types, for example office, member transfer, or platform request. Each type carries a display order and a default assignee, so a new request of that type lands with the right person without anyone routing it by hand.

Issue statuses are configured separately from task statuses and follow your own naming, for example new request, in progress, roadmap, and closed. Support settings hold the statuses, the types, and the list of members who work the queue.

A member submits a request, it takes a status and an assignee, and both sides can see where it stands. Nothing depends on someone remembering to forward an email.

Every member has a personal drive alongside their profile, visible only to that member and to admins. Files an admin uploads there cannot be altered by the member. PDFs, office documents, images, and video all render inside the platform, which is how organizations keep case documents on the record they belong to.

Every project member with assigned tasks receives an email listing what is due in the coming week, sorted by priority and due date. Volunteers see their own workload at the start of the week without an admin chasing them.

Changing a task's status or its assignee notifies the people affected, so a handover does not need a separate message.

Assigned tasks appear on each member's dashboard next to their groups, upcoming events, and open votes. Project work sits in the same place as everything else a member does with the organization.

The workflow engine pairs a trigger with an action that runs when the trigger fires. Available actions are sending an email and adding or removing a tag, including on form responses.

The platform is controllable through a documented REST API, which is how organizations create tasks from their own website forms or from an external automation tool such as Zapier or Make.

Webhooks fire on a fixed set of entities: user, contact, payment, event, attendance, contract, and role. An n8n node wraps the same webhooks in a visual interface. Project and task events are not currently available as webhook types.