Dovetail Agent has a number of Work Item types. The most common are Cases, Subcases, and Solutions.
In addition, there are Change Requests, Part Requests, and Action Items.
Not everyone is familiar with Action Items, so this post will cover the basic of action items – what they are, how you might use them, and how they compare to cases.
Action Item Basics
Action Items are simply a task that needs to be completed.
The task could be any number of things – depending on how you wish to use them.
For example, an Action Item could be used:
- To setup a customer’s online account for SelfService/WebSupport
- As an Operations task, such as upgrading a server
- To track a contract renewal process
You can use different action item types for different tasks, so you’re not limited to a single use case for action items.
At a minimum, an action item will have a title, a type, a priority, a start date, and a due date.
Other that the title, all of the other fields are set to default values, which means it’s super quick to create a new action item.
Because an action item represents a task to be completed, there is a Due Date. By default, the due date will be set to 7 days in the future.
This is easily configured with the ActionItemSettings.DueDateNumberOfDaysAfterCreation application setting.
Action Items for Customers
An Action Item can optionally be related to a customer (a contact).
This allows you to create tasks that are specific to an individual customer.
Again, this is optional, so this allows for some flexibility in how you use Action Items.
Just like other work items in the system (such as cases), Action Items support all of the normal workflow operations, including:
- Reject from Queue
Action Items also support batch actions – meaning you can perform the same operation on a set of action items at one time.
- assign a set of action items to an employee
- dispatch a set to a queue
- close a set
- log the same note to a set
- change the status of a set
You can log a note, or log an email to an action item.
When logging a note or an email, you can also use Canned Responses – making it easy to re-use common notes or responses.
Of course, all of the logs and workflow actions are recorded within the action item history.
File Attachments are also supported, so you can easily include screen shots, documents, log files, etc.
Just like all of our work items, you can create business rules on action items, allowing for notifications and escalations.
- Notify queue members when an action item is dispatched to a queue
- Let users know when an action item has been assigned to them
- Notify the owner when an action item’s due date is approaching
- Notify the owner’s supervisor when an action item’s due date has been missed
- Notify a customer when one of his action items has been closed
Action Items can be easily queried, just like other work items.
Action Items are included with the search, making it easy to search for any text within the action item, or any of its notes or emails.
You can also search using properties
Action Items can be enabled or disabled completely throughout the app, and can also be enabled only for certain groups of users.
This is easily accomplished using the standard privilege class UI.
Comparison to Cases
Action Items and Cases share many of the same traits
- They’re both work items, and support workflow operations (assign, dispatch, accept, close, reopen, etc)
- They both support logging notes and logging emails
- They both support File Attachments
- They both support status changes
Customer not required
One big difference is that action items do NOT require a related customer.
When creating a case, you MUST select a contact and site.
But for action items, this is optional. You can, but you don’t have to.
For example, you may decide to use action items to track operations work, which may not be a task that is specific to a customer.
Acton items tend to be a bit “simpler”, and do not support:
- Log Research
- Time and Expense tracking
- Sub-tasks (i.e. subcases)
- Parent/child tasks (i.e. parent/child cases)
So Action items tend to feel lighter-weight compared to cases.
Separation of work
One of the things I really like about Action Items is it allows for separation of work.
For example, we can choose to keep customer support work within cases, and other work within action items.
This separation make things easy, both from day-to-day work, but also for reporting.
Yes, you can filter your reports based on case type. For example, excluding Operations case types from your standard customer reports.
But by moving those non-customer activities into action items, you don’t have to worry about that.
Just like we can have different case types, we can have different Action Item types.
These different types, along with the optional relation to a customer, allows for a lot of flexibility in how you can use action items, and even use them for different workflows and scenarios within your organization.
Note: Action Item types are actually stored in the Task Type list.
Action Items are also supported within Dovetail Task Manager.
This allows for the automatic creation of Action Items as part of an automated workflow process.
And just like when Subcases are created using Task Manager, the Task definition can set properties on the Action Item (such as Priority, Type, and Due Date), and it can also be assigned or dispatched appropriately.
As I mentioned before, emails can be sent out from an Action Item. So what happens if the recipient replies to one of these emails?
In this scenario, Dovetail Carrier can receive the email, and log the reply back to the original action item.
Then a business rule fires that notifies the owner that new information has been added to their Action Item.
So the complete back and forth email conversation is logged, just as you would expect.
Action Items are stored in table_task. There is not a baseline table named action_item.
It’s common to get confused with this model, as Action Items are stored in table_task, but Clarify Task Manager details are stored in table_stage_task and table_task_set. Dovetail Task Manager uses table_dt_task and table_dt_task_set.
BOLT is always helpful when dealing with the Clarify/Dovetail schema. Here’s the task table in BOLT:
So that wraps up this primer on Action Items.
As I mentioned earlier, I think they’re super useful, and provide a great deal of flexibility and options for tracking different tasks within your system.
Are you using action items today? Do you envision some workflows in your organization where they would be useful?
Leave a comment below and let me know!
Sign up to get information like this delivered right to your inbox.