Task notifications
Hunto tells people about task changes in three ways: when a task is assigned to them, when someone comments and asks for the organisation to be told, and, if you set it up, through a notification model that emails a named list when a task changes.
Delivery of every email depends on how your organisation's email notifications are configured. If a message you expect does not arrive, see Troubleshooting and ask your administrator to check the rules described in Notification Configuration.
What gets sent
| Event | Who is told | How |
|---|---|---|
| A task is assigned to you, or reassigned to you, by someone else | The new assignee (a person, or the members of a group when the task is assigned to a group) | Email titled "New Task Assigned" (listed in your preferences as Task assigned to you). Links to the task in My Tasks. |
| A comment is posted with Notify ticked | The whole organisation | Listed as New comment on a task. Comments marked Internal are never sent. |
| A task changes and it has a notification model | The people on the matching stage of the model | An email titled " |
The assignment email is not sent when you assign a task to yourself. Model emails have no such exclusion: if you make a change that matches a trigger, and you are on that stage's list, you are emailed too.
Every link opens the task's pane directly, for example .../monitor/tasks/my-tasks?task=TSK-... for assignment emails and .../monitor/tasks/overview?task=TSK-... for model emails.
Your own preferences
Open Notification Preferences from the notifications page (the Inbox has a link to it). Task events appear as their own rows (for example Task assigned to you and New comment on a task), with a switch for each channel: In-app, Email and SMS. A channel that a notification is never sent by shows a dash.
Some rows show "Digest" with an interval, for example "Digest · 15m", next to them. That means your administrator has chosen to bundle these notifications into a periodic digest rather than send each one as it happens, and it cannot be changed from your preferences page. Organisation administrators can also switch to Organisation default to set defaults; note that at the time of writing the page says organisation defaults are saved but not yet applied to individual members.
Turning off a critical alert asks you to confirm.
Notification models
A model decides who is told when a particular kind of task changes. Typical uses: a management roll-out where an approver is told when work reaches review, or a security lead is told whenever a Critical task changes.
Only organisation administrators can manage models. Open Org Management > Notifications and choose Notification Models. The page lists each existing model as a card and has Add New Model.
Creating a model
- Choose Add New Model.
- Give it a Name, set Module to
task, and choose a Type (the task types in use in your organisation, such as the type given to tasks that came from a review request). - Add one or more stages. For each stage give it a name, choose the Users/Teams to email, and choose the Triggers that fire it.
- Save.
A model can have several stages: for example a stage "Approvers" that fires on Status: Review and a stage "Owner" that fires on Assignee Changed. When a change matches the triggers of several stages, every matching stage sends.
To use a model, open the task and choose the model in the Notify field of the detail pane. The create form does not have this field, so a new task gets its model after it exists. Only tasks with a model selected send model emails, and only for changes made after the model is selected. Creating a task never sends a model email.
Available triggers
| Group | Triggers |
|---|---|
| Field changes | Title Updated, Description Updated, Assignee Changed, Status Changed, Severity Level Changed, Points Updated, Team Changed, Type Changed, Due Date Changed, Completed Date Set, Reference Updated |
| Ownership and system fields | Owner Changed, Creator Modified, Creation Time Set, Last Updated |
| Specific status | Status: Not Assigned, Not Started, In Progress, Review, Rejected, Completed |
| Specific severity | Severity: Critical, High, Medium, Low |
A "field change" trigger fires on any change to that field. A "specific" trigger fires only when the field changes to that value, so Status: Completed is the one to use to tell someone when work is done. The ownership and system-field triggers are rarely useful because those fields are not edited from the task screens.
Triggers named New Task Added and Bulk Imported Task are listed but do not send anything at present. To be told about new tasks use the assignment email, or ask for the task's assignee to be someone who wants to know.
Limits to be aware of
- A model can be added, but the page has no way to edit or delete one afterwards. Create a replacement and select it on the tasks that should use it.
- Clicking an existing model card opens the form pre-filled with an Add button. Pressing it creates a second, duplicate model rather than editing the first.
- A model fires one email per changed field. Changing three fields in the detail pane sends up to three emails.
- Models notify on changes made after the model is selected; they do not go back over history.
- Members are stored as users or teams; choose them from the picker rather than typing names.
Comment notifications
The Notify box on a comment tells the whole organisation, not just the assignee. Use it sparingly. It is hidden when Internal is ticked, because internal comments are never sent. There are no @mentions; to draw one person's attention to a task, assign it to them or send them the task link (Copy link in the detail pane).
Scheduled and periodic summaries
Task Analytics is not emailed. If you want a weekly picture of overdue and unassigned work, see Use cases and wiring tips for the recommended routine.
Troubleshooting
| Problem | Check |
|---|---|
| Assignee did not get the email | You assigned it to yourself (no email is sent), or their preferences have the Task assigned to you row switched off for Email, or it is in a digest. Also confirm the address on their profile. If everything looks right, ask your administrator to check that an email rule exists for the assignment notification. |
| A model does not send | The task's Notify field is empty; the trigger you chose does not match the change; the stage has no users; or the change was made at creation time (models only react to later edits). |
| A model sends too many emails | It sends one email per changed field. Change fewer fields at once, or use a narrower trigger such as Status: Completed. |
| A comment email did not go out | The comment was Internal, or Notify was not ticked. |
| An email link opens the wrong page | Open the link while signed in to the right organisation. |