Tasks Guides Overview
The Tasks feature provides users with important to-do items assigned to them by an institution.
In this article:
A Task is an assignment of a job to a user. It may be sourced from another system of record or be declared directly through the Pathify administrative interface. A Task may be a personal Task (one which is self-assigned) or an institutional Task (one which is assigned by the institution).
Each Task must have a title which will appear in high-level listings, in messaging contextual to the Task, and in notifications contextual to the Task.
The title of the Task is limited to 1024 characters.
Call to Action
Where a message or notification is contextual to the Task, it will tend to be a clickable link, a Call to Action or CTA. This CTA is described by the Task’s cta_text and link.
It is not mandatory for a Task to contain a CTA.
Each Task must contain body text, which is a longhand description of the Task.
The text of the Task is limited to 32,768 characters. Generally, Tasks should not approach this limit since they are often accessed in a narrow dialog format not appropriate for chapter length text.
The text of the Task may contain a limited set of HTML tags.
Task Due Date
As an assigned job, a Task may have a due date, which does not contain a time part and must be expressed in the format yyyy-mm-dd.
When a Task passes the due date without having been completed, it is flagged as OVERDUE, which is visible to the user. An administrator may sort by Due Date in Admin Center, which will sort Overdue tasks to the top.
When a Task passes the due date having been completed, it remains in the Completed tab for the user.
A Task may also have an expiry date in the same format.
When a Task passes the expiry date, unless it has been completed, it becomes invisible to the user. Expiry status should generally be used to convey whether a Task is no longer relevant to the user.
Tasks may carry reminder notifications which will be sent to users a configurable number of days before the due date. A Task may only have reminder notifications if it has a due date.
A reminder notification is configured with the number of days before due to be sent and may be configured to pop up into the user session, interrupting activity. This popup is dismissible by clicking the acknowledge reminder. The reminder is flagged as having been acknowledged by that user.
The wording of a reminder notification is not customizable.
Any Task that has been created in Admin Center may be self completed by the user.
Tasks may be used as a to-do list for users or as a suggested worklist for a first day on campus.
Tasks that have been marked as completed, regardless of whether they are expired, are still visible in a separate sorted list to the user.
Task Management in Admin Center
Managing Tasks in Admin Center is an easy way to create multiple Tasks at once, manage Task Categories, and even view Task completion details.
Creating Multiple Tasks At Once
Tasks may also be created in Admin Center.
Tasks in the Admin Center are created in batches; each Task in the batch is still assigned to only one user, but all the Tasks in the batch are parameterized exactly the same way; they have the same title, text, expiry, due date and notifications.
A Task batch is assigned to a set of users by means of identifying a set of Roles that should be assigned the Task, as well as individual users; this is consistent with creating a membership filter for a portal group, for instance.
The Task creator must specify the audience of users who will each be assigned an instance of the Task, and whether users will retain the Task if they leave an assigned role, and whether a user who newly acquires the role should also be assigned the Task. In the Admin Center interface, this is controlled by the flag apply to new users.
Whether a user should retain the Task on leaving the role is controlled by the audience_exception_action field of the Task Batch, which is a string value having possible valid values of COMPLETE, EXPIRE, DELETE or NO_ACTION. In the Admin Center interface, this is controlled by the dropdown on role change.
This field is not nullable; a Task Batch must specify what happens when a user no longer has the role which initially justified assignment. It is defaulted to leaving the task assigned to the user: you still have it because you once had it.
Together, this enables an administrator to specify a task which must be undertaken by anyone who is in or will be in a particular role at the institution.
A Task may also be assigned to a category when created in Admin Center. This is used for filtering and sorting and can be parameterized with an icon and a category description.
Categories must be declared in advance of being assigned to Tasks.
A user creating a Task for themselves through the portal may not add that Task to a category.
Administrators using Admin Center also see the percentage completed for the Task.
This shows the proportion of completed Tasks against the number of created instances of that Task (including those retained by users who no longer have the role, under the NO_ACTION strategy).
Whether or not a Task is Ongoing (whether or not new members of the role should be assigned the Task) may be controlled through this view, as well as by editing the Task itself. This is the same flag as apply to new users in the Task editing interface.
Through the frontend interface, this describes the two main strategies of Task creation in the portal - users creating their own to-do lists in the portal, and administrators creating Tasks for batches of users in Admin Center.
Another significant strategy for creating Tasks comes from other systems.
Critical Tasks are often assigned to users from a third-party system such as an SIS or LMS, especially where admissions or advisors manage Task assignment and creation directly in those systems.
In these cases, it may be useful to mirror those Tasks into the portal for the users’ attention, although the Task creator is managing them in another system.
Tasks may be directly created and updated through the portal API interfaces, although this will require significant bookkeeping and handling by the consumer. An institution that already has strong integration competencies may prefer this method.
Most institutions will prefer to synchronize Tasks through the Pathify middleware system, conventionally by flat files.
A Task title should not contain confidential information (such as a grade result). This is because it will often appear in contexts uncontrolled by the user (such as an SMS notification appearing on the user’s home screen of their phone). Confidential information should be reserved for the text of the Task, which is accessed by an intentional user action.