I’ve discussed this template in past posts:

• The “From” Address of a Log Email
• Include a URL to the case in outgoing emails
• Encouraging SelfService use – Include a link in outgoing emails

Example send_email_about_obj template

Here’s an example of the template:

TO: <FOCUS.recipient>
CC: <FOCUS.cc_list>
FR: <FOCUS.sender>
RE: About Case <ADDITIONAL_INFO> : [Case Title] [Subcase Title]
<FOCUS.message>

Log Email API

This template name is coded within the LogEmail API within the Dovetail SDK.

We’ve recently made some enhancements to the LogEmail API to allow for different templates to be used between cases and subcases.

We now support two new templates:

• send_email_about_case
• send_email_about_subcase

send_email_about_case

When performing a log email for a case, if the send_email_about_case template is present in the system, it will be used. Else, the send_email_about_obj template is used.

Here’s an example of a new case template:

TO: <FOCUS.recipient>
CC: <FOCUS.cc_list>
FR: <FOCUS.sender>
RE: About Case <ADDITIONAL_INFO> : [Case Title]

<FOCUS.message>

send_email_about_subcase

When performing a log email for a subcase, if the send_email_about_subcase template is present in the system, it will be used. Else, the send_email_about_obj template is used.

Here’s an example of a new subcase template:

TO: <FOCUS.recipient>
CC: <FOCUS.cc_list>
FR: <FOCUS.sender>
RE: About Subcase <ADDITIONAL_INFO> : [Subcase Title]

<FOCUS.message>

Flexibility

These new templates allow for greater flexibility in configuring outgoing emails.

One common way that this is used is to allow different subject lines in outgoing emails for cases and subcases. Notice the subject lines in the case and subcase example templates above.

Dovetail Agent ships with example templates, which can be customized for your specific business needs.

Use of these templates is entirely optional. If they are not imported into the database, then the existing send_email_about_obj template is used.

Enhanced Templates

We can also easily enhance our templates, such as:

• Customize the subject line
• Include a company logo in the email
• Include a link back to the case in selfservice
• Include a legal footer
• etc.

Here’s an example of an enhanced case template:

TO: <FOCUS.recipient>
CC: <FOCUS.cc_list>
FR: <FOCUS.sender>
RE: Regarding MyCompany Support Case [Case ID] : [Case Title]
![Company Logo](https://mycompany.com/logo.png)
<FOCUS.message>

---
[Check the status and update your case (Case [Case ID]) online at our SelfService site](https://company.com/selfservice/cases/[Case ID])

---
This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.

And here’s an example of what the recipient would see:

Outgoing Email

Versions

This functionality is available in Dovetail SDK version 3.6, and this version of the SDK is part of Dovetail Agent version 20.

Compatibility with Dovetail Carrier

Recall that Dovetail Carrier is used to process incoming emails, including logging an incoming email to the proper case or subcase.

The way it determines which case or subcase to log to is determined by application settings.

EmailAgentExtensionSettings.CaseIdentifierFormat – defines what string to look for to identify a case ID number

EmailAgentExtensionSettings.SubcaseIdentifierFormat – defines what string to look for to identify a subcase ID number

So if you edit the email templates, be sure to edit the corresponding settings in Carrier.

For example, if my send_email_about_case template uses this for a subject:

Regarding Dovetail Support Case [Case ID] : [Case Title]

Then I’d want to edit the EmailAgentExtensionSettings.CaseIdentifierFormat in Carrier to match: (note that this is a regex (regular expression))

Regarding\s+Dovetail\s+Support\s+Case\s+(?!\w+-\w+)(?<caseId>\w+)

What about Rulemanager?

Rulemanager does not need to change here at all, so an updated version of Rulemanager is not needed.

When the LogEmail API does its thing, it picks the correct email template and relates the template to the time_bomb that tells Rulemanager to send the email.

So the template to use is already defined in the database – Rulemanager simply uses the template that’s been related to the time_bomb.

So Rulemanager does not need to change to support this new functionality.

What about Action Items?

Action Items already have their own email template – send_email_about_action_item

TO: <FOCUS.recipient>
CC: <FOCUS.cc_list>
FR: <FOCUS.sender>
RE: About Action Item [Action Item ID] : [Action Item Title]
<FOCUS.message>

What about Change Requests?

Change Requests already have their own email template – send_email_about_bug

TO: <FOCUS.recipient>
CC: <FOCUS.cc_list>
FR: <FOCUS.sender>
RE: About Change Request <ADDITIONAL_INFO> : [CR Title]

<FOCUS.message>

Wrap Up

As I said earlier – this functionality is entirely optional. If you’re perfectly happy with how outgoing emails work – then there’s nothing more to do.
But, if you’d like some additional distinctions between case emails and subcase emails, you now have that power.

Rock on.

The post Introducing New Log Email Templates for Cases and Subcases appeared first on Clarify Solutions | Dovetail Software.

The default notification methods are:

• Email
• Notifier
• Forward to my Supervisor
• Tone Pager
• Text Pager
• Digital Pager
• None

Dovetail Rulemanager also supports SMS, which will send an SMS message (text message) to an employee’s configured device, typically their mobile phone. Refer to a previous post SMS Notifications using Dovetail Rulemanager.

Now, Dovetail Rulemanager also supports Slack as a notification preference. Instead of getting notified by email, a user can choose to receive notifications within Slack.

What is Slack

Slack is essentially a chat room and messaging platform for your whole company, commonly used to replace email as your primary method of communication and sharing.

Slack Notifications

Instead of getting notified by email, a user can choose to receive notifications within Slack.

If your company uses Slack, and your Dovetail/Clarify system administrators have configured the Slack integration, you can choose to receive your notifications via Slack.

When a user chooses to receive Slack Notifications, a direct message will be sent to the employee’s personal Slack channel.

Personal Slack Notification

Slack Integration

To use Slack as your notification preference

1. Retrieve your Slack Member ID
2. Enter your Slack Member ID into the Dovetail/Clarify application
3. Select Slack as a Notification Preference

1. Retrieve your Slack Member ID

Dovetail uses the user’s Slack Member ID to message a user within Slack, so you must enter your Slack Member ID into the Dovetail/Clarify application.

Note: Slack Member ID is not the same as Slack Username! See this Slack post for more information

• Within Slack, Click on your UserName
• Select the Profile & Account option
• Click the More Actions down arrow
• There you will see (and have the option to copy) your member ID

Slack Member ID

2. Enter your Slack Member ID into the Dovetail/Clarify application

Paste that Slack Member ID into the Slack Member ID field on the employee profile page within Dovetail Agent, or on the Employee form within the Clarify Classic Client, depending on your application.

3. Select Slack as a Notification Preference

Select Slack as a notification preference, either in Dovetail Agent or in the Clarify Classic Client

Employee Notification Preferences – Dovetail Agent

Employee Notification Preferences – Clarify Classic Client

Admin Instructions

1. Refer to the Dovetail Rulemanager documentation for complete instructions on configuring the Slack Integration, including:

• Creating a Slack Bot App
• Rulemanager Configuration
• Options for configuring the database field that stores an employee’s Slack Member ID
• Add Slack as a option in the Notifications dropdown list (both for Dovetail Agent and for the Clarify Classic Client)
• How to retrieve Slack Member IDs for all users

2. Refer to the Dovetail Agent documentation for complete instructions on enabling Slack as a notification option within Dovetail Agent.

At Mentions

In Dovetail Agent, we recently added the ability to mention other users, and they will be notified.

Sometimes while working a case, you’ll want to call the attention of another employee. When you include a mention (by typing @ and then the user’s name or login name) in your notes, that employee will be notified.  This works similar to @mentions in many of the other apps that we use on a daily basis, including Facebook, Twitter, and Slack. Mentions are a great way to loop someone else into a case, without having to transfer ownership of the case itself.

Now, those @mention notifications can happen directly in Slack – pretty cool!

Slack Notification due to an @mention

Slack Group Messages

I’ve  posted in the past about how to Integrate Clarify/Dovetail with your group chat app, and ways to Improve the Slack Integration.

For example, you can post group messages to Slack when

• A case is dispatched or accepted from a queue
• When new application feedback has been received
• When a customer comments or leaves a rating on a knowledgebase article

Slack Group Message – A Case Has been Dispatched

Now we can post personal notification messages, in addition to group messages into Slack.

Supported Versions

• The Slack Integration required Dovetail Rulemanager version 2.7 or higher
• The Slack Integration within Dovetail Agent is supported as of Dovetail Agent version 20.

Lets Wrap This Up

Many organizations are using Slack for more real-time messaging and collaboration, so it makes perfect sense to push notification messages into Slack as opposed to email.

Now, it’s easy to do just that.

Hope you dig it.

The post Introducing Personal Slack Notifications using Dovetail Rulemanager appeared first on Clarify Solutions | Dovetail Software.

One of the more recent extensions is the AutoDest Toolkit Extension.

AutoDest Toolkit Extension

This extension allows for automatically assigning or dispatching workflow objects based on an auto-destination rules.

Typically, these messages will originate from Dovetail Rulemanager (such as from a business rule action), although they can also originate from custom applications as well.

Example Message

type=CallToolkit 
toolkit=AutoDest
method=execute 
ObjectType=case
Operation=DISPATCH
Id=12345

This example would evaluate the DISPATCH auto-destination rule for case 12345, and if a destination queue is found, the case would be dispatched to that queue.

Auto-Dest Rule

Here’s an example of an auto-destination rule:

(calltype2gbst_elm:title = "Equipment Repair") -> "Equipment Repair";
(calltype2gbst_elm:title contains "Payroll" ) -> "Payroll";
(calltype2gbst_elm:title contains "Benefits" ) -> "Benefits";
(title contains "Benefits" ) -> "Benefits";
objid > 0 -> "Support Cases";

In English, here’s what that rule says:

• If the case type is equal to Equipment Repair, then dispatch to the Equipment Repair queue
• If the case type contains the word Payroll, then dispatch to the Payroll queue
• If the case type contains the word Benefits, then dispatch to the Benefits queue
• If the case title contains the word Benefits, then dispatch to the Benefits queue
• If nothing else matches, dispatch to the Support Cases queue

Examples

It’s common that this extension would be triggered from a business rule. Here’s a few examples of how we might use this.

• When a case is created from one of our custom integrations, route the case to the appropriate queue
• If a case has been sitting in a user’s wipbin without any activity for a while, re-route it to a queue
• If a case is reopened via a Selfservice/WebSupport app, route it to the appropriate queue
• If a customer sends in an email to a closed case, reopen the case and route it

Re-Route all of an Employee’s Cases

Here’s a more real-world example of how this could be used.

Let’s say that we have an employee that has recently left the company, but she has a bunch of cases that she owns and are still being worked.

We could easily assign all of them to one user, or dispatch them all to a particular queue using a batch action.

But, if we want them to go to different places, then this becomes more difficult. For example, perhaps we want the Benefits cases to go to the Benefits queue, the Payroll cases to go to the Payroll queue, and the remaining ones to go to the general Support Cases queue.

We can create a business rule that will call the AutoDest Toolkit Extension for each case, and the case will get routed accordingly, based on the configured auto-destination rules.

Business Rule

I created a business rule that fires when a log note of type “Action” happens, when the notes text starts with “route”

Business Rule to Route using Auto-Destination

Query

I can query for all of the open cases for that employee

Case Query

Batch Action

Then log a note to all of those cases, which will fire the business rule, and trigger the AutoDest toolkit extension to be triggered.

Batch Log a Note to all of these cases

Results

Looking at the case history, we can see:

1. The note that was logged
2. The business rule fired
3. The dispatch to the queue

Case History

Not Just for Dispatching Cases

In addition to dispatching, Auto-Destination rules can also be used to Assign to an individual employee.

And they’re not just for cases – you can also use Auto-Dest rules for subcases, part requests, change requests, solutions, and action items.

Wrap Up

Auto-Destination rules are pretty powerful, and now they can be used in even more ways.

The AutoDest Toolkit Extension is one more tool to add to your toolbox to enhance your Dovetail/Clarify system.

What other scenarios could you see this being used?

Additional References

Refer to the following Dovetail Knowledgebase Article: Auto-Destination Rules: What they are, how they work, and examples.

Featured Photo by Jamie Templeton on Unsplash

The post Automatically routing cases using Dovetail Carrier’s AutoDest Toolkit Extension appeared first on Clarify Solutions | Dovetail Software.

Interactions

Dovetail Agent now includes Interactions functionality.

An Interaction is just that – a way to capture any type of interaction you may have with a customer.

In call centers, it’s common to capture every call as an interaction. A customer may call into the call center to check on the status of an order, or to inquire about a billing question, etc. Each of these can be captured as an interaction in the system.

Create Interaction

In many service centers, a case is overkill for tracking these simple inquiries. We want to capture that we’ve interacted with the customer, but we don’t need all of the more complex workflow that goes along with a traditional support case.  But, in some instances, an interaction may also lead to a case being created, and we’ve made it easy to create a new case from the interaction page.

There’s nothing that says that Interactions have to be an interaction with a human. And, it’s often the case that interactions are created programatically.  For example, years ago I worked on a project for a bank, and each time a customer called into the bank’s IVR system, an interaction was created automatically. All of these interactions roll up into a complete view of every touch-point with a customer.

Functionality also includes

• Logging Notes to an interaction, including the use of Canned Responses.
• Searching and Querying for Interactions
• The interactions functionality can be completely enabled/disabled on a system wide basis
• Privileges allow for control of who can create, edit, and query for interactions
• Recent Interactions are shown on the Contact page

At Mentions

Sometimes while working a case, you’ll want to call the attention of another employee. When you include a mention (by typing @ and then the user’s name or login name) in your notes, that employee will be notified (via a business rule). Mentions are currently supported only on cases, when Logging Notes or Logging Research Notes.

This works similar to @mentions in many of the other apps that we use on a daily basis, including Facebook, Twitter, and Slack.

Mentions are a great way to loop someone else into a case, without having to transfer ownership of the case itself.

@mentions

@mention notification

Slack Notifications

Instead of getting notified by email, a user can choose to receive notifications within Slack.

When a user chooses to receive Slack Notifications, a direct message will be sent to the employee’s personal Slack channel.

I’ll have another post soon that goes into more details regarding Slack Notifications.

Personal Slack Notification

Log Email with Existing Attachments

When logging an email, users can now select an existing file attachment to include in the outgoing email

Log Email with Existing Attachments

History Improvements for Emails with Attachments

History: Attachments that are part of an email (Sent Email or Received Email) are now grouped with the email history item, instead of showing as separate items.

This makes the history much cleaner, and makes it clearer which files were included with which emails.

Case History – Emails with Attachments

Toggle Case Notes Visibility

Allow case notes to be toggled between Public and Internal. This allow for hiding case notes in SelfService/WebSupport-type applications.

For example, as a user, I may save a regular note that is supposed to be Internal Only. That note can now be easily toggled to be marked as Internal.

Mark an existing note as Internal

Schema Path Builder

Schema Path Builder, to assist with building schema paths for Rule Properties and Auto-Destination Rules

Schema Path Builder

Workgroup Specific Broadcasts

Broadcasts can now be sent to everyone, or only to members of one or more workgroups

Broadcast – limit to specific workgroup(s)

Business Rule Condition Ordering

Business rule conditions can now be ordered (and re-ordered), and Rulemanager will evaluate these conditions in order.

This allows for fine-tuning of how Rulemanager evaluates business rules, and can help with performance.

For example, there may be a custom rule property that needs to do an expensive cross-server query. By putting that condition last, it allows the simple conditions to be evaluated first, and the expensive evaluation to be avoided if any of the simple conditions evaluate to false.

Business Rule Conditions

History for Task Manager

Tasks and Task Sets (part of the Task Manager functionality) now include a History tab, which tracks activities (create, edit, add, delete).

This allows better visibility and auditing capabilities as to who has edited these items and when.

History for Task Manager

Wrap Up

There’s a bunch of cool stuff in this release – and many of these items were enhancements submitted directly by customers.

For a complete list of enhancements and fixes, refer to the What’s New section in the Agent 20 documentation.

If you want to learn more, or want to see a demo of Agent in action – just drop me a line or give me a call – I’m always happy to show off our applications!

The post What’s New in Dovetail Agent 20 appeared first on Clarify Solutions | Dovetail Software.

So if we have a customer that asks to be forgotten, how do we deal with that? And what does that mean within our Clarify/Dovetail systems?

Often, the conversations dive into what data do we need to get rid of.

Customer Information

In our CRM / case management systems, the customer record is pretty contained. We have the contact table for the person itself, which has the person’s name, phone number, email address, etc. And we have the e_addr table, for their additional phone numbers, email addresses, and web sites.

There’s some slight differences if we’re dealing with B2C or B2B organizations. With B2C, where we might be dealing with Individual Contacts, we may also need to deal with the related site and address records.

Notes, Emails, Cases

But then we have all of our workflows and interactions with the customer – which may contain customer data. Notes and emails for the contact themself. And of course – Cases – especially case notes and case emails that may contain sensitive or identifying customer data.

And then the conversation tends to lead to a couple of different avenues of how to deal with this data.

The most common approaches seem to be either to delete or to redact the information.

Delete

Deleting the customer record (and related data) seems to be the most common approach. We can delete the contact and related e_addr records. If it’s an individual contact (in a B2C environment), we might also delete the contact_role, site, and address records.

But, we also have to deal with the cases. Case notes and case emails likely contain sensitive or identifying customer data.

Deleting the data seems to be the go-to choice – but I think it yields some pitfalls as well. If you delete the customer’s cases – you’ve now affected your history and reporting.

If we delete cases, we then lose visibility into not only the cases themself, but related KPIs. We no longer have accurate counts for:

• number of cases created, timing, and frequency
• cases broken down by case type, severity, part, or business unit
• cases worked by an individual user
• SLA measurements
• per-incident contract reporting
• etc.

We spend so much time making sure we collect the data so that we can use it – it seems odd to want to throw it away.

Depending on the number of GDPR requests received, this may or may not have a significant impact on reporting and analytics.

Redact

Instead of deleting the data, we can redact it instead. We can fine-tune our redacting, so that we only redact sensitive or identifying customer data. Obviously, things like customer name, phone numbers, email addresses, addresses, etc.

When we look at our workflow objects (such as Cases) – we can redact certain pieces of data – where we have identifying customer data – and keep the rest intact. For example, we’d likely redact anything that is a text or notes field – where customer data may be present. This would include the case title, notes, emails, phone logs, etc. But we can maintain the case identifying information – case type, severity, the related part and serial number, all of the user and system workflow actions, create and close history items, etc. This allows us to maintain the important data that we collect and use for both historical and future analytic purposes.

Deleting with DIET

I’ve talked many times in the past about the power of the Dovetail DIET (ArchiveManager) tool.

We can use DIET to delete (purge) data from the database.

DIET uses directive files, which direct DIET in what to purge, and how to traverse and deal with related data.

For example, when purging a case, we want to purge

• the case itself
• all related notes logs, phone logs, email logs, and research logs
• all close case records
• all activity logs
• all time and expense logs
• all commitments
• etc.

DIET ships with example directive files that handle all of this.

If you don’t use some of these items, the directive file can be tweaked to remove them. For example, if you don’t use time and expense logs, we can remove them from the directive file. That way DIET doesn’t need to even look for them, since it would never find any. This is purely a performance tweak though.

In addition, if you’re like most Clarify/Dovetail customers, you’ve customized, likely adding additional tables. So the directive file can be edited to include these additional custom tables as well.

Once the cases have been purged, then we can purge the customer (contact) record. We need to get rid of the cases first, then the contact. The directive file for purging contacts says to STOP if the contact has any cases, as we don’t want to end up with cases related to a non-existent contact, thus ending up with our data in a bad state. These built-in safeguards help protect the integrity of your data.

Purge Cases

Here’s an example of where I first purge all of the cases for a contact, and then purge the contact itself.

Purge Cases with DIET

Notice that we purged 353 cases, but the total number of records was over 11,000. All in 22 seconds. (and that’s without any tweaks or optimizations of the directives file)

Purge Contact

Purge Contact with DIET

Then we purge the contact.

Just 1 contact record (as expected), but a lot of act_entries. 102 total records in less than a second.

Redacting with SQL

Rather than deleting the data, we can redact any fields that may contain sensitive information. This allows us to keep the case intact – which is useful for reporting and history. We can see that the case exists, its case type, when it was created and closed, etc. But we’ll redact any sensitive information.

Unlike SaaS applications, Clarify/Dovetail customers have full access to the underlying database – which means we can take advantage of native database tools. Although in this case, I don’t think we need super-fancy tools – some good old-fashioned SQL will do the trick.

The hard part here is determining what you need to redact. We can certainly offer some suggestions for baseline Clarify/Dovetail data, but as the keeper of your system and data, you may need to do some auditing of your system to see where else you may have identifying customer data. For example, we’ll likely want to redact:

• contact name, phone number, email address
• contact notes
• case title
• case history
• case notes
• case phone notes
• case email logs
• case research logs
• close case logs
• etc.

A case, in its normal state

Normal Case

The same case, after being redacted

Redacted Case

And the contact, redacted

Redacted Contact

Example SQL

Here’s the SQL script that I used to redact a contact and their cases. If you want to do something similar, this script may be a good starting point.

Track and Automate these Requests

What if you wanted to track and automate this more? Just kicking around a few ideas here:

• When a new GDPR request comes in, create an Action Item with a type of GDPR and relate to the contact.
• Dispatch to GDPR Request queue
• Accept and Change the Status to Approved.

Create a new Powershell script

• finds any GDPR action items with a status of Approved
• maybe we want a delay, so we only look for those action items that are more than 30 days old
• for each one, we run either our SQL script or DIET purge commands
• log a note to the action item, saying that the purge or redaction happened
• close the action item

Create a Nightly Scheduled Task that runs the above Powershell script

Much of this mimics what I covered in a previous post: Automatically Scheduling and Tracking Work Items

Obviously, this is just some ideas. I’d probably see how many of these requests actually come in, before adding a lot of scripting and automation around the process. But, I do really like the idea of tracking these requests by an Action Item, even without the scripting and automation. This provides some history and visibility into how often these types of requests come in.

Wrap Up

With either of the above approaches (purge or redact), there is a bit of work to do, but I don’t think it’s a huge task.

1. Determine your preferred approach – delete or redact data
2. Determine where you may have identifying customer data (including customizations)
3. Starting with either of the above technical approaches, tweak for your specific needs

The good thing is that once you’ve done this work once, it’s re-usable for future Right to be Forgotten requests.

And if you need some assistance, we’re happy to be that trusted partner and guide by your side.

The post GDPR and the Right to be Forgotten appeared first on Clarify Solutions | Dovetail Software.

How could I  setup a task based scheduling system where I could build out my list of tasks, the frequency, attach the job aide/work instructions, then have the system assign it to a specific queue when the time for the task to be done comes up. These would all be scheduled items. Once I set the frequency of the task, there would be an engine/function that would create these tasks. I would also like to be able to report on these tasks, if they were completed, etc.

As I was thinking about this, I broke it down into a few items:

1. How could we track/manage an individual piece of work?
2. How could we setup the list of work items that need to be done, including their specific attributes and routing?
3. What would trigger the automatic creation of these work items?
4. How could I view and query/report on these work items?

I think all of this can be accomplished using Task Manager and Action Items within Dovetail. Lets give it a whirl.

Action Items

As I covered in my previous Action Items 101 post – an Action Item is simply a task that needs to be completed. The task could be any number of things – depending on how you wish to use them. Here, we’ll use them for a scheduled maintenance task.

I’ve added a new Scheduled Maintenance value to the Action Item Type list, making it easy to identify these action items.

So now I can create an action item of this type, and I get all the normal workflow capabilities (dispatch, assign, close, etc. )

Here, I’ve created an action item for some work to be done, namely to Test the Disaster Recovery Process. It has a type of Scheduled Maintenance, and it’s been dispatched to the Operations queue.

Action Item – Scheduled Maintenance

So we now have a piece of work that can be tracked and managed. Step 1 complete.

Next, we need to look at how we can we setup the list of work items that need to be done, including their specific attributes and routing

Task Manager

Dovetail Task Manager allows actions to occur automatically when a task set is invoked.  For a primer on Task Manager (including a video walkthrough), check out this post. One of the supported actions is creating action items.

Task

Here’s a task that I’ve created to test the disaster recovery process:

• The task will Create an Action Item
• The action item Type will be set to Scheduled Maintenance
• I can provide additional Details, such as notes, or a link to reference
• It has a Due Date of 5 days (from the date the action item is created)
• And it will automatically be Dispatched to the Operations queue

Test Disaster Recovery Process Task

Now that we have a task, we can add that to a Task Set.

Task Set

A task set is simply a collection of tasks. Here, I’ve created a Monthly Maintenance task set, and added the Test Disaster Recovery Process task to it.

I’ve also added another task to Review the Error Logs.

Monthly Maintenance Task Set

So, we now have a monthly task set with a couple of tasks. Step 2 complete.

Next, we need to have this task set get triggered on a periodic basic.

Task Scheduler

We can use the built-in Windows Task Scheduler to trigger the creation of the monthly maintenance tasks. It’s super flexible, and provides a lot of options for scheduling.

Here, I’ve created a Monthly Maintenance task that will run on the first Monday of every month.

Windows Task Scheduler

We have our schedule defined, so now we need to configure the action itself.

How do we have the Windows Task Scheduler trigger the Monthly Maintenance Task Set within Dovetail?

Publish a Message

The way task sets get started is by a message being published to Dovetail Carrier. This commonly happens via a business rule, and Rulemanager will publish that message. But we can also publish a message directly using the handy Publish utility.

In short, the Publish utility makes it easy to send (publish) a message into Dovetail Carrier. I’ve talked about the Publish utility in much more detail here and here, so check out those posts for additional information.

The message that gets published needs a few pieces of data:

• A type of RunTaskSet
• The TaskSetName
• A Case ID (although in this scenario, we’re not concerned about a case, so it can be any case in your system)

So here’s the command line that we want to run:

c:\bin\publish\Publish.exe "type=RunTaskSet\r\nTaskSetName=Monthly Maintenance\r\ncaseId=100"

And here’s what it looks like within the Windows Task Scheduler:

Windows Task Scheduler – Actions

So now, on the first Monday of every month, the Windows Task Scheduler will publish a message to Dovetail Carrier, and Carrier will run the Monthly Maintenance Task Set, and the 2 action items will be automatically created and dispatched.

Query

Action Items can easily be queried on. Here, I’ve created a simple query to view the open scheduled maintenance tasks. I’ve also made it a favorite (notice the filled in star icon), so I can easily run this query at any time.

Open Scheduled Maintenance Tasks Query

So we now have an easy way to query and view the status of our scheduled maintenance tasks. Step 4 complete.

Repeat the Process

If we have other monthly maintenance tasks to be done, it’s now super easy to create a new task and add it to the monthly task set.

We can follow a similar process for other time periods. For example, we can create a weekly task set, that is triggered every week. Or bi-weekly, or yearly. It’s the same process.

Summary

Like many of the solutions I blog about, I think it’s the general approach rather than the specific outcome that is most interesting.

A few things to note

• Not everything has to be a Case – we have other entities in the system that we can use. Action Items are widely underused.
• Once the Windows Task Scheduler action is setup – everything else is configured within the Dovetail Agent UI.
• We can take advantage of the best tools for the job – i.e. Windows Task Scheduler is super flexible and reliable
• Notice that I didn’t write any code here. No custom coding or scripting necessary.

So there you go – one approach for automatically scheduling and tracking work items. Hope you dig it.

The post Automatically Scheduling and Tracking Work Items appeared first on Clarify Solutions | Dovetail Software.

Download Search Results

Users have always been able to download the results of a query, but now they can also download the results of a search as well – in either Excel or CSV format.

Download Search Results

The output columns when downloading search results will be the same output columns as when a query result is downloaded, and are easily configurable using a filter.config file. So it’s easy to add or remove additional columns, and that change will automatically apply to both query and search results.

Search Results – Excel format

Download Limits

A new configuration setting (DownloadMaxRowCount) defines the maximum number of items that can be downloaded, from either a query result or a search result. This helps prevent users from trying to download the entire database – something that will make your DBAs happy!

My Calendar

Action Items are now included in the user’s calendar (based on the Due Date of the Action Item).

My Calendar

Now user’s can easily see all the items that are due soon – including:

• Action Items
• Subcases
• Commitments

Solution Enhancements

We’ve enhanced solutions to go along with the improvements made in Dovetail Selfservice 3.

Solution Type

Solutions now include a Solution Type drop-down, allowing for better categorization and taxonomy, as well as for defining Selfservice Custom Content pages.

Solution Type

Solution Ratings

Display individual and overall average ratings for solutions.

Solution Ratings

Hide comments

Allow for setting the “Internal” flag on a Solution comment, allowing it to be hidden (marked as Internal) within the Dovetail SelfService application.

Toggle Internal/Public flag on a solution comment

Impersonation

For any activities that are performed while a user is being impersonated, the impersonator information is now included in the case history.

Note logged during impersonation

Admin

We’ve made a bunch of improvements within the Admin section of the app as well.

Broadcasts

Broadcasts on the Manage Broadcasts page now include an Active/Inactive badge for each broadcast, making it easy to see at a glance which ones are in play.

Broadcasts

Business Rules

The Manage Business Rules page now shows business rules in a paged format, as opposed to showing all rules on one page. This is especially helpful for those implementations with hundreds of rules.

Manage Business Rules

Business Rule – History

Business Rules now include a History tab, which tracks activities (create, edit, add, delete) on a business rule. We tend to track everything that happens on work items (cases, subcases, action items, etc.) – but not typically on our admin entities. So we’ve added this history tracking for business rules, and we’re planning on adding history tracking for more admin items in the near future.

Business Rule History

Business Rule Conditions

Admins can now edit a condition. In the past, the condition would need to be removed and then re-added. This is especially helpful when a condition has a complicated value.

We’ve also added support for the “is not in” operator for business rule conditions.

Business Rule Conditions

Privilege Class

The priv class page now allows for filtering to view only enabled privileges.

Privilege Class – Show only Enabled Privileges

Print Pages

Improved the print pages for all workflow items (Case, Subcase, Solution, Part Request, Change Request, Action Item). These are now separate pages, allowing for better formatting and greater customizability.

Print Case

Summary

There’s a bunch of cool stuff in this release – and many of these items were enhancements submitted directly by customers.

There’s also a number of minor changes, assorted bug fixes, and some changes that are specific to developers.

For a complete list of enhancements and fixes, refer to the What’s New section in the Agent 19 documentation.

If you want to learn more, or want to see a demo of Agent in action – just drop me a line or give me a call – I’m always happy to show off our applications!

The post What’s New in Dovetail Agent 19 appeared first on Clarify Solutions | Dovetail Software.

For example, when a customer updates a case via SelfService, we can have a business rule fire that sends an SDK Toolkit message to Carrier, and Carrier will change the case status to “Customer Update”.

Complete end-to-end Testing

When I’m putting this all together, and testing it out, a full integration test would be to log into SelfService, and log a note to a case. That would cause Rulemanager to fire a business rule which would send the message to Carrier, then Carrier can do its thing. So I have multiple apps in play here:

1. Dovetail Agent, for setting up the business rule
2. Dovetail SelfService, which is how the customer updates a case
3. Dovetail Rulemanager, which processes the business rule and sends the message to Carrier
4. Dovetail Carrier, which receives the message and performs the Change Status

When I’m first setting this all up, I can simplify all this, and test using just 1 app, rather than dealing with 4.

I like to be able to throw a message into Carrier’s queue to get processed, and test that it’s doing what I expect.

Publish Utility

I can easily do this using the publish.exe utility. This executable will simply take the message content as an input parameter, and publish that message to Carrier. I mentioned this executable before, in the context of custom actions, and we provide this app (and the source code for it) as an example of how you can build your own app that publishes messages to Carrier.

More and more I’ve found myself using this utility to push messages to Carrier for testing purposes.

This way I can just test the Carrier message piece, and not have to worry about the other 3 apps. This makes testing much easier and faster.

Check out the Dovetail Carrier Customizations site for more details on downloading the exe and its source code.

Command Line

From a command line, I can simply call publish.exe, and pass in the message. Note the use of \n to indicate a newline.

Here’s an example where I’m publishing a message into the Carrier queue so that it changes the status of a case.

publish.exe "Type=CallToolkit\n Toolkit=Support\n Method=ChangeCaseStatus\n CaseIdNum=4305\n NewStatus=Working"

Once I have the basic message working, then I can start adding in other parameters, or testing variations as needed.

Carrier Logs

The Carrier logs allow me to track down any errors. For example, here’s the logs showing that the message was received and processed, but I gave it an invalid status.

Dovetail.Carrier.Core.RuleManager.RuleManagerConsumer - 
Carrier message received: Type=CallToolkit\nToolkit=Support\nMethod=ChangeCaseStatus\nCaseIdNum=4305\nNewStatus=Customer Update 

Dovetail.Carrier.Core.RuleManager.RuleManagerConsumer - 
Resolved message data for: Carrier.Extensions.SDK.CallToolkit 

Carrier.Extensions.SDK.CallToolkitConsumer - 
Invocation request received: 
Toolkit: Support
Method: ChangeCaseStatus
Arguments: {
	"CaseIdNum": "4305",
	"NewStatus": "Customer Update"
}
 
Carrier.Extensions.SDK.CallToolkitConsumer - 
Resolved toolkit: FChoice.Toolkits.Clarify.Support.SupportToolkit 

Carrier.Extensions.SDK.ToolkitInvoker - 
Resolved ChangeCaseStatus to Carrier.Extensions.SDK.DefaultToolkitInvocationPolicy 

ERROR FChoice.Foundation.Clarify.ClarifyException - 
FChoice.Foundation.Clarify.ClarifyException: (15126) Element 'Customer Update' in list 'Open' does not exist.

Iterate and Test Quickly

By reducing my development/test footprint to only Carrier, I can more quickly iterate over different message formats, without involving Agent or Rulemanager.

Once everything is good with my Carrier message, I can then bring my other apps into play (such as Agent, Rulemanager and SelfService)

The post How to Quickly Test Dovetail Carrier Messages appeared first on Clarify Solutions | Dovetail Software.

Notification Message

For example, lets say that you received the following notification:

Email Notification

How do I find which business rule caused this notification to be sent?

There’s actually a few options here.

1. Dovetail Agent – Query Business Rule Actions

Using Dovetail Agent, create a query for Business Rule Actions

Dovetail Agent – Query Business Rule Actions

And filter for Message Contains something happened

This will show you a list of rules that contain that string in the message.

Dovetail Agent – Query Results

Clicking one of the results will take you to the Business Rule itself.

Dovetail Agent – View Business Rule

2. Dovetail Agent – from the History

If you know the work item (Case, Subcase, etc.) that the notification pertains to, then you can also check the History for that item.

Make sure the History is set to Show Details. You can then see the Rules that fired.

Dovetail Agent – Case History

Clicking on the rule will take you to the Business Rule page for that rule.

Then you can see the details of that rule, including the message.

Dovetail Agent – View Business Rule

You may have to view a few of the rules on that case before you find the right one, but at least your surface area for rules to check have been reduced greatly.

3. BOLT

Using the Business Rule page in BOLT, filter for Message contains something happened.

BOLT – Search Business Rules

This will show you a list of rules that contain that string in the message.

BOLT – Business Rule Search Results

And from there, you  can click on the rule name to see details of the rule.

BOLT – View Business Rule

BOLT is freely available at https://github.com/DovetailSoftware/bolt

4. SQL

You can also use direct SQL to query for the data.

The following query will give you the names of the business rules based on a notification message.

select * from table_com_tmplte where objid in 
(
  select escal_act2com_tmplte 
  from table_com_tmplte  
  where action like '%something happened%'
  and type = 2
)

From there, you can view the business rule itself in whatever app you use for managing business rules (Dovetail Agent, Dovetail Admin, Clarify Client, etc.)

Using SQL is my least favorite way of accomplishing this task, but it is an option.

Summary

Locating a business rule based on its message is one of those sys admin tasks that pops up on occasion – and with just the Clarify Client, it was a challenge.

Now, with some smarter tools, and a bit of know-how, this becomes an easy task.

Rock on.

Dig This?

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

Sign up for the Dovetail Newsletter

The post Finding a Business Rule based on its message appeared first on Clarify Solutions | Dovetail Software.

I totally dig this feature, as it makes it super easy to customize the queries within the app without having to write code.

We know it’s easy to show data that comes from a database column within the query results – such as a contact’s name or phone number.

But what if we wanted to show something that is more dynamic? i.e. something that needs to be calculated?

For example, in the result set for contact queries, what if we wanted to show the number of open cases that a customer has?

There’s not an existing field in the database that contains this data. The number of open cases needs to be summed up.

So how can we do this in a query?

SQL Views to the rescue

In the past, I’ve discussed SQL views, and how they can be super powerful. As a refresher, here’s what they are:

SQL views allow an administrator to define the actual SQL for a view, as opposed to the schema tool dynamically building the SQL.

SQL views allow for:

• A view with only one table. A common use of this is to take advantage of aggregates (max, min, count, sum, avg, etc.).
• A view using multiple, unrelated tables.
• A view that uses the UNION keyword to consolidate between multiple tables or views.

Number of Open Cases for a Contact

So, what we can do is to create a SQL View that contains the number of open cases for a contact.

Our view will return the contact objid, and a count of the number of open cases.

A simple Dovetail SchemaEditor schemascript will do the trick here.

<schemaScript xmlns="http://www.dovetailsoftware.com/2006/10/SchemaScript.xsd">

   <addSqlView name="dt_contct_open_cases" id="502">
      <baseTable>case</baseTable>
      <groupName>Dovetail</groupName>
      <description>Number of Open Cases for a given contact</description>
      <sql>
      select c.objid as contact_objid, count(e.elm_objid) as num_open_cases 
      from table_contact c
      LEFT OUTER JOIN table_extactcase e ON c.objid= e.contact_objid AND e.condition like 'Open%' 
      group by c.objid
      </sql>
   </addSqlView>

   <addSqlViewColumn name="contact_objid" sqlView="dt_contct_open_cases" dataType="Integer"/>
   <addSqlViewColumn name="num_open_cases" sqlView="dt_contct_open_cases" dataType="Integer" />

</schemaScript>

SQL Query

We can now run a simple SQL query that returns the number of open cases for a contact, given their primary key (objid).

SQL Query against our new SQL View

Now that we have the schema setup to return the data we want, lets include this data as part of the contact query.

Filter Config Overrides

I previously blogged about how to use filter config override files to customize queries.

For this scenario, we’ll create an override config file for the contacts query.

We’ll add a join from the existing query to the new view that we just created.

<addJoin from="con_objid" to="contact_objid"  table="dt_contct_open_cases" adhoc="true">

And then make the # of Open Cases data available for filtering

<addFacet key="numberOpenCases" field="num_open_cases" dataType="int" label="# of Open Cases"/>

And finally make the # of Open Cases data available as a output column

<columns>
    <addColumn key="numberOpenCases" template="number" label="# of Open Cases" index="3" width="140"/>
</columns>

Here’s the complete contacts.override.filter.config file:

<filter overrides="Contacts">

  <query from="rol_contct">

  <addJoin from="con_objid" to="contact_objid"  table="dt_contct_open_cases" adhoc="true">
    <addFacet key="numberOpenCases" field="num_open_cases" dataType="int" label="# of Open Cases"/>
  </addJoin>

</query>

  <columns>
    <addColumn key="numberOpenCases" template="number" label="# of Open Cases" index="3" width="140"/>
  </columns>

</filter>

Simply copy that file to the $dovetailAgent\Filters\custom directory.

That’s it.

Test it

Within Dovetail Agent, we can create a new contact query, and we can see that the Number of Open Cases is now displayed in the results.

Contact Query with the Number of Open Cases Results

Filtering

We can also filter the query based on that data.

For example, lets filter the query to only show those contact with more than 50 open cases.

Contact Query with Number of Open Cases Filter

Summary

While the example here is cool, it very well may not exactly fit your specific needs.

But that’s OK – I think it’s the concepts here that are most interesting.

1. We can use SQL views to calculate, aggregate, or take advantage of other powerful elements of the SQL language
2. We can use filter config override files to easily add filters and output columns based on the SQL view data

And both of these these tasks – a schema change and a config file – are within the wheelhouse of Clarify/Dovetail sys admins.

There’s no code involved here, such as C# or JavaScript, so these types of changes should not require your development team.

So what do you think? Could you see this being useful in your environment?

Have some ideas of things that would fit into this process?  Drop a comment below and let me know!

Dig This?

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

Sign up for the Dovetail Newsletter

The post How to Include Calculated Data in Query Results appeared first on Clarify Solutions | Dovetail Software.

In that post, I discussed how we can analyze the data inside our database to see which rules are firing and how often. We can do this using a Business Rule Usage Report. 

This report tells us what business rules are firing along with how often. Perhaps even more importantly, it allows you to see the rules that are not being fired. Perhaps those rules could be removed, or made inactive, therefore simplifying business rule administration. Or maybe they should be firing, and need further investigation.

These reports are now available within Dovetail Agent.  Makes sense to have this data available right alongside where you create and edit your business rules. 

Business Rule Usage Report

From the Manage Business Rules page, click on the Usage Report link, which takes you to the report.

Business Rule Usage Report

From the report, we can easily see which rules have fired, and how often, within the defined time period. 

By default, the report shows data for the last 30 days. You also have one-click access to filter by other date ranges:

• Last 30 Days
• Last 365 Days
• This Month
• Last Month
• This Year
• Last Year 

In addition, you can manually enter whatever start and end dates that you want. 

Rules that don’t log their Activity

Within a business rule action, you have the option to specify whether an Activity Log is created when the rule fires or not.  If an activity log is not created, then we don’t get the data, and thus we can’t report on it. No bueno. 

So, to make it clear when this is happening, we color those rules differently, so that they stand out, and make it obvious that the report data may be inaccurate because of this. 

Rules that aren’t logging their Activity

The help text on the page provides this information, in context. 

Colored rule action rows have the Create Activity Log option set to ‘No’ so the number of times the rule has fired will always be zero. If you wish the number of rule firings to be accurate for this rule, check the Create Activity Log on Action checkbox for this rule action.

Hopefully this spurs the viewer on to edit the business rule and set the Create Activity Log option to Yes.

Activity Report for a Single Rule

In addition to the Summary Report shown above, we also have access to this information when viewing a specific business rule. On the Business Rule page is an Activity tab. 

Here, we access the same basic report, but it’s specific to only this Business Rule, and its Actions.

Notice that this rule has 2 Rule Actions (notice the number 2 in the Actions tab header), and the Activity report shows the number of times that  each of those actions has fired within the given time period. 

Since each rule action can start at a different time, the # of Times Fired can be different for each action. Here, both actions start at the same time, so that’s why both show the same number. 

Summary

This usage report tells us what business rules are firing along with how often. Perhaps even more importantly, it allows you to see the rules that are not being fired. Perhaps those rules could be removed, or made inactive, therefore simplifying business rule administration. Or maybe they should be firing, and need further investigation.

For even more help with Business Rules, check out the Free Collection of Business Rule Recipes.  There’s also a Business Rule Template, which is helpful when defining new business rules.

You can access the Business Rule Recipes and Template here. 

The post Business Rule Usage Reports in Dovetail Agent appeared first on Clarify Solutions | Dovetail Software.

Quick Refresher on Parent and Child Cases

With parent and child cases, we can relate a group of similar problems with a root cause. The parent case identifies the root cause. A child case is a customer problem that arises due to the root cause and is linked to the parent case.

For example, suppose someone knocks out a utility pole, which causes an internet outage for many customers.

Each customer may call into the call center and report the outage. We can relate all of these cases to a parent case, which is where the repair is being tracked. Updates on the repair are tracked within the parent case. Only one case needs to be updated, thus removing duplicate work.

Parent-Child Cases Extension

This extension allows for automating part of the workflow process here – specifically, it will automatically close all the child cases of a parent case.

A common use case for this is to have a business rule that fires when a parent case is closed. This rule will tell Dovetail Rulemanager to send a message to Carrier, and Carrier will close all of the child cases. An internal note will be logged to the parent case with details.

Example Message

Here’s what the message looks like that we want to send to Carrier:

type=CloseChildCases
caseID=12345
Status=Closed
Resolution=Auto-Closed
Summary=Automatically closed via Dovetail Carrier extension

Integration with Rulemanager

Dovetail Rulemanager supports a business rule action type of Carrier Message, which will send a message to Dovetail Carrier. This allows a business rule to be crafted that will close the child cases.

Example Business Rule

Note: The Number Of Child Cases rule property (used in the business rule condition) is a custom Function-based Rule Property, freely available at https://dovetailsoftware.github.io/property-extensions/

Note logged to the Parent Case

When this message is handled, an internal note will automatically be logged to the parent case with details of what happened, including which cases were closed, which are already closed, and which could not be closed (along with the reason why it could not be closed).

Example of note that is logged

Closed Parent Case

Flip the Script – When the last child case is closed, close the parent case

What if you wanted to go the other way – so that when the last child case is closed, it should automatically close the parent case?

This is easy to do as well. Create a new business rule. When the child case is closed, and the NumberOfOpenChildCasesOnParent is equal to zero, send Carrier a message to close the parent case using the SDK Toolkit Extension.

This business rule is one of the examples provided in the Free Collection of Business Rule Recipes. You can access the Business Rule Recipes here. 

Summary

If you use Parent and Child Cases, this new Carrier extension should help with your workflow automation. 

And don’t forget – if the available Carrier extensions don’t fit your exact needs – you can build your own extensions, allowing you to craft processes that address your specific business needs. Check out the Dovetail Carrier Customizations site for more details. 

Dig This?

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

Sign up for the Dovetail Newsletter

The post Parent-Child Cases Extension in Dovetail Carrier appeared first on Clarify Solutions | Dovetail Software.