Action Items 101

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
  • etc.

Action Item in Dovetail Agent


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.


Create 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.


Action Item for a customer



Just like other work items in the system (such as cases), Action Items support all of the normal workflow operations, including:

  • Assign
  • Dispatch
  • Accept
  • Yank
  • Forward
  • Reject from Queue
  • Close
  • Reopen


Batch Actions

Action Items also support batch actions – meaning you can perform the same operation on a set of action items at one time.

For example:

  • 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
  • etc.



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.


Log Notes, with a canned response

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.


Business Rules

Just like all of our work items, you can create business rules on action items, allowing for notifications and escalations.

For example:

  • 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

Business Rule for Action Items


Action Items can be easily queried, just like other work items.


Query Action 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.


Search Action Items

You can also search using properties


Advanced Search for Action Items



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.


Action Item Privileges


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:

  • Commitments
  • 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.


Administration of Action Item Types


Task Manager

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.


Task Manager – Task that creates an Action Item


Email Agent

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 Item with outgoing and incoming emails


Data Model

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:


table_task 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!

Dig This?

Sign up to get information like this delivered right to your inbox.