Posts by Gary Sherman:
We’ve done a lot of work recently to improve case (and subcase) history within Dovetail Agent 5.
It feels much cleaner, is easier to read, and just feels pleasant. Plus there’s some cool new features.
Here’s a few highlights.
Avatars for users, applications, and customers are shown.
Notice that there is an avatar for Annie (who is a employee/user), Scott (who is a contact), and for Dovetail SelfService (an application).
And the avatars are clickable links. If the avatar is for a user/employee, the link goes to the employee page. If it’s a contact, it goes to the contact page.
Reverse Chronological Order
Notice that the history shows the newest entries at the top, similar to many current …
One of the modules within a Clarify system is Task Manager. In support environments, it’s typically used to automatically generate subcases. Task Manager can be kicked off by using the Jobs button on a case, or by having a business rule call the taskmgr executable.
A task definition defines the specifics of the object that is to be created (in this case, we’re talking about a subcase that gets created).
Out of the box, Clarify allows you to set the following subcase properties when a subcase is created via Task Manager:
title description required date priority status severity elapsed time
But, like most things in Clarify, we can setup additional properties.
Custom property – subcase type
For example, lets say we want to be able to set the subcase type. The valid subcase types are General and Administrative.
We use our Dovetail SelfService application for supporting our customers on a daily basis. It gives customers the power to access what they need, when they need it – quickly and easily.
Customers have access to:
knowledgebase product downloads product documentation license keys
And of course, they can interact with our support staff using cases:
create new cases update existing cases: add notes, upload files, change severity close cases reopen cases etc.
When a case is created via SelfService, customers pick the severity of the issue, such as:
Low – I’ve just got a question Medium – It’s minor and not significantly affecting production High – Production is heavily degraded Urgent – Production down
A common request I hear from users is: How do I get solutions (knowledgebase articles) out of my WIPbins?
A Solution (in baseline Clarify/Dovetail) is always in an Open condition – meaning it’s always in a user’s WIPbin. But once I’m done creating/editing it – I don’t want to see it anymore. It just clutters up my workspace.
One very simple way to tackle this is to create a dummy Solution Librarian user. That way, a user can simply assign a solution to the Solution Librarian, and this takes it out of the user’s WIPbin.
I’ve posted in the past about how to notify the case owner when someone else logs a note to their case.
For example, if a customer logs a note to a case in SelfService, I want to know. If a customer responds to an email, and is automatically logged to a case (via Dovatail Carrier), I want to know.
This post recaps information in the previous post, and adds some additional niceties to the notification message.
Here’s an example of a notification received via email:
The business rule
Object Type: Case
Rule Name/Description: Notify the …
I got a question today about how to close a case when all of its subcases are closed.
You could certainly add code to your application (such as the Clarify Client or Dovetail Agent), but to me, this sounds like more workflow automation, and we can do that with business rules. Plus, if you use multiple client applications (lets say the Clarify Client and Dovetail Mobile) – you don’t want to have to customize each of those apps.
To accomplish this task, we’ll create a business rule that fires when a subcase is closed. If all of its sibling subcases are also closed, then we can close the case.
First wrinkle: How do we know when all of a subcase’s siblings are also closed?
One way to do it is to look at …
I’ve been recently working with a couple of customers who were dropping database columns from their schema on Oracle, and the drops were taking a long time to complete.
In one instance, the customer estimated it would take 50 hours to drop a bunch of columns from their contact table.
In another, a customer observed that dropping two columns from table_site_part took over two hours. Dropping 3 columns from table_contact took over 1 hour.
These long execution times can disrupt normal operations – especially those environments with limited maintenance windows.
Dovetail’s schema editing tool (Schema Editor) and Amdocs schema editing tools (ddcomp, SchemaManager) all do the same basic operations when it comes to dropping columns. Basically they all do this: ALTER TABLE table_name DROP COLUMN column_name;
There’s a better way.
Within your Clarify / Dovetail schema, there’s a concept of an Optimized View. This is really an implicit feature of a view, but if you’re aware of it, and understand how they work, you can use it to your advantage.
An optimized view happens when you have a join to a table, but the only field that you’re including from the joined in table is the objid field, and the relation type from the main table to the joined table is a OTOP or MTO.
When these conditions are met, then the schema editing tools (ddcomp, SchemaManager, Dovetail SchemaEditor) will optimize the underlying view, meaning that it will not actually create a join to the table, but instead will simply use the column from the main table as part of the select clause.
That’s a bunch of …
As I mentioned, I initially hacked together some code as a proof-of-concept.
I’ve cleaned up the code a bit, and have made it available on Github: https://github.com/gsherman/raplet
The code is freely available, although it does use the Dovetail SDK, so you do need an SDK license key.
I totally dig this integration. It’s not uncommon that I exchange emails directly with customers, and having additional case information right there in context is pretty sweet.
Hope you find this useful.
While discussing Dovetail SchemaEditor recently, a question came up around deletes (drops), i.e. How do you delete a column using SchemaEditor, as it doesn’t seem like SchemaScript supports deletes.
First, a little background.
SchemaEditor works with Data Dictionary files and with SchemaScript files.
A Data Dictionary file is a complete reference of the database schema. This is similar to a Clarify complete schema files.
SchemaScript is a simple, imperative way of specifying the changes to be made to the database schema.
A complete schema file (Data Dictionary), because of its size and complexity, can quickly become unwieldy and cumbersome to work with.
Schema Script simplifies the process of schema changes by allowing a user to specify only the changes to be made, as opposed to the complete schema.
However, only adds and updates can be performed using SchemaScript. Deletes are not …