Part Requests

Logistics customers will be happy to know that we’ve brought Part Request functionality into our latest Dovetail Agent platform. This includes:

• Create and Edit Part Request Headers and Part Request Details
• Part Request Workflow operations: Accept,Assign,Dispatch,Forward,Reject,Yank,Close,Reopen
• Part Request Actions: Create New Part Request, Replicate Part Request
• Part Requests are available in My Work, Queries, Recent Items, and Search

Part Request Header

Part Request Detail

Batch Actions – Change Status and Log Notes

Change Status and Log Note are now available as batch actions, making it easy to log a note or change the status of many cases or subcases at one time.

Range select

On the query results grid (such as My Work), users can shift-click to select all checkboxes in-between the first one clicked and the second one that is shift-clicked.

This makes it easy to select a set of items in order to perform batch actions on them.

Additional niceties

• My Work – automatically remember the last selected tab
• Notes are no longer required when closing a case or subcase
• The contact page now has a Create Case Actions menu option, making it easy to create a case for this contact:

Easily turn off unused items

Workflow Items (case, subcase, solution, part request) can be easily disabled with the FeatureEnabled configuration settings.

For example, with everything enabled:

and with just cases and subcases enabled (solutions and part requests are disabled, thus hidden from view):

And this is accomplished with just a simple configuration change – no code changes are necessary.

Summary

Obviously, the major feature here is Part Requests – but we’ve also added enhancements that will benefit those that use cases, subcases, and solutions as well.

As someone who uses this application every day in production use, I’m thrilled with the state of the app – and it keeps getting better!

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

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

Over the last 15 years or so as legacy Amdocs/Clarify deployments gradually began to be replaced by other on premise CRM providers such as SAP and Siebel (two we used to see often), companies somewhat knew what they were getting into. They had experience implementing a fairly similar CRM at least once by that point. They knew it was going to be a relatively timely, resource intensive and costly upfront expense to rip and replace.

However, as SaaS and various other hosted CRM offerings came along, the enticement of a less costly upfront expenditure, combined with more out-of-the-box configurability from the user and admin standpoint showed promised.

Whether it’s an on premise or SaaS solution being considered for rip-and-replace to legacy Clarify deployment, they both have serious challenges that require extremely careful forethought to help ensure success and/or long-term value. At the very least, our 20 years of experience with all things Clarify/Amdocs has shown us just that. Today though, we’re going to focus on specifics to strongly take into account if considering a SaaS offering to replace Clarify.

Is SaaS Right for your Clarify Replacement?

First off, SaaS solutions are somewhat rare for major Clarify replacements for a number of reasons.  They tend to be less “customizable” (by design/SaaS-power of one) and organizations with somewhat rigid change tolerances, coupled with highly customized legacy CRM applications, don’t particularly mesh well with SaaS offerings in this type of scenario. If you’re an organization with this type of environment, be particularly mindful.

Some SaaS solutions are actually quite “customizable” though. When organizations want to perform some true “customizing” (not configuring) they may need to hire new developers skilled in that SaaS offering. If they want to bring them in as full-time employees, they can also be difficult to find.  If they choose to use in-house tech talent, they’ll need to be trained for new skills, which take both significant time and financial resources. Since source code is very rarely, if ever, shared with SaaS offerings, the amount of integration and customizing is typically limited to on premise solutions that allow for such.

Costs to Consider

On the surface, SaaS applications can seem less expensive upfront and sometimes they truly are in a vanilla Clarify legacy environment which is OK with significant change, but there are different types of costs to consider that greatly affect long term value.

SaaS typically offers “named users”.  If you have 100 users, you need 100 licenses (not the case with concurrent licenses).  You have to manage users far more carefully, as well (add a user, new license, new unaccounted for cost) (team shrinks, users need to be immediately cancelled to avoid wasteful spending). If you have sporadic users, perhaps managers that only monitor hotspots here and there or executives that review high-level numbers once a week, those users still require the same costly named-license as a full-time user. More expensive Admin user licenses are common, too. SaaS subscriptions can exceed one-time perpetual license deployments in only three years. Five years is typically the absolute max. And that’s before considering a data migration and customization costs to mimic imperative existing workflows that may be too rigid to be forced into out of box SaaS functionality as addressed previously.

There are important data security implications to note in a SaaS offering when hosting in the cloud, outside of one’s protected internal firewalls. From a vendor vetting standpoint, it is far more work for your security team to review that the vendor is taking the proper precautions to ensure the safety of the data that’s being hosted. Contractually, it involves more legal resources as well. Those pieces are typically short lived, but they do not come without a certain level of effort from multiple internal resources. Government and financial institutions for example are exceedingly stringent with their data security requirements. The amount of internal resources to vet and contract with SaaS vendors is no small effort.

User Tolerance

The final consideration is the tolerance your user base has to change. For as long as reasons why the success or failure of application implementations have been studied, the number one reason that stands firmly alone the top for success or failure is user acceptance. Will your user population be able to and/or willing to adapt to the point that the implementation can be labeled successful? Do you have a technically savvy bunch? Do you have a not-so-technically savvy bunch? Combination of the two perhaps? Pushing rigid change all at once with a total data migration to a new system can be shocking to those in their comfort zone and they may never really get back up to the level of efficiency they enjoyed with the old system. Weigh this carefully from a user and technical culture standpoint. It could not be more important.

Dovetail’s Unique Solution

Dovetail offers by far the most unique solution on the market to all of the issues listed above. We offer zero data migration, a level of comfort enjoyed by those users less apt to change since Dovetail mimics many Clarify workflows and verbiage. We also offer efficient, value oriented concurrent user licensing, source code for developers based on a common .NET platform, and probably the most important thing; the ability to roll user groups on to Dovetail at different times since we tie directly into the back-end database and no data migration is needed. That means customers can strongly mitigate risk and disruption to the business by allowing some groups to faze on to the system while others continue using the legacy Clarify client. All the data works together and interacts the same, even in a hybrid environment. It may feel like software magic to those who have experienced a big, painful cut over, but it’s just Dovetail’s very unique offering that has made for some extremely happy customers over the years. This type of scenario could not be better tailored to Dovetail.

Please consider reaching out to us to learn more if this is of interest. Cheers and best to you in your efforts to maximize your legacy Clarify investment!

The post Considering SaaS to Replace Your Legacy Amdocs/Clarify Deployment? appeared first on Clarify Solutions | Dovetail Software.

Updating an object

Typically, when we want to update some data, we just need to define its uniqueness properly.

For example, if I wanted to update a business rule property name,  I could define its uniqueness as a combination of its object type + name.

For example:

OBJECT TYPE="prop_name", NAME="commitment case id" 
UNIQUE_FIELD=obj_type, prop_name 
    FIELDS 
        obj_type=30;     /* object type 30 = commit_log */ 
        prop_name="Case ID"; 
        path_name="case_commit2case:id_number";
        subtype=0;  
        val_type=0; 
        max_len=255; 
    END_FIELDS 
END_OBJECT NAME="commitment case id"

If I used DIET to import this file, and this prop_name  record didn’t exist in the database, then it would do an INSERT, which would create this prop_name record.

If I used DIET to import this file, and this prop_name record did exist in the database, then it would do an UPDATE, which would update the existing prop_name record. This would allow me to update the path or max length of that rule property.

This syntax allows us to update the non-unique fields of a record.

Updating the unique fields

Updating a unique field on an object is not always as straight-forward.

A common way to do this is to delete the existing record by using the PURGE option of DIET, and then doing a second DIET IMPORT run to insert the new record. It’s two operations, but it works. This only works if you don’t have any foreign keys that reference the object that you’re deleting.

A second option is to use objid as a unique field, as that doesn’t change. But use of objids can cause problems when using the same file on different databases. So the import file may work in your development database, but not production.

A third option is a seldom-used feature of DIET, which allows a  DELETE + an INSERT in one operation. This is a cool little trick that not everyone knows about. Again, this only works if you don’t have any foreign keys that reference the object that you’re deleting.

Update daylight savings time records

A real-world example of this is updating the daylight savings time records. When the start and end dates for daylight savings changed starting in 2007, those daylight_hr records needed to be updated.

The uniqueness for daylight_hr records was the combination of start_time + the relation to the time_zone.

But since we want to change the start_time (and end_time), we can’t use the standard syntax. And since no other tables have foreign keys that point to daylight_hr, we can do this DELETE + INSERT trick in one file.

Here’s an example:

DELETE TYPE="daylight_hr", NAME="delete_2007_Pacific_Standard_Time"
UNIQUE_FIELD=start_time 
UNIQUE_RELATION=daylight_hr2time_zone
 FIELDS
   start_time = DATE "04/01/2007 02:00:00";
 END_FIELDS
 RELATIONS
   TO_NAME="Pacific_Standard_Time" REL="daylight_hr2time_zone";
 END_RELATIONS
END_DELETE NAME="delete_2007_Pacific_Standard_Time"


OBJECT TYPE="daylight_hr", NAME="insert_2007_Pacific_Standard_Time"
UNIQUE_FIELD=start_time 
UNIQUE_RELATION=daylight_hr2time_zone
 FIELDS
   start_time = DATE "03/11/2007 02:00:00";
   end_time = DATE "11/04/2007 02:00:00";
 END_FIELDS
 RELATIONS
   TO_NAME="Pacific_Standard_Time" REL="daylight_hr2time_zone";
 END_RELATIONS
END_OBJECT NAME="insert_2007_Pacific_Standard_Time"

We can have all that information in one DAT file, and use DIET’s import option. DIET will DELETE the old daylight_hr record, INSERT a new one with the correct dates, and RELATE it to the correct time_zone.

And we can do this with just one DAT file, and one execution run of DIET. Pretty cool.

As I mentioned, that DELETE element is rarely used, but can be super useful in certain circumstances. The DIET documentation has more details on the DELETE element.

Just one more tool to add to your bag of tricks.

The post DIET: DELETE + INSERT instead of UPDATE appeared first on Clarify Solutions | Dovetail Software.

At the time, we used a tool called Grunt. This is a node-based task runner. It allows you to define and run tasks that are often repeated in the development process such as compilations, optimizations, file copying, and others. Gulp is also a task automation tool but implemented differently with different objectives that we’ll discuss later in this post.

The Problem

We saw that our gruntfile was getting out of control. It had grown to over 17 separate tasks with some configurations spanning over 50 lines! This was definitely a problem of our own creation, but here was our chance to rethink our strategy. This was also a chance to see if any better tools existed.

The Wishlist

So we sat down and started thinking through our wishlist of things we’d like from our automation.

• Easy to understand
• Fast
• Simple to change
• Good support (plenty of help online if needed)

In looking at our list, we found a few points that grunt struggled to fulfill. Namely, the first 3. Grunt’s “configuration”-style syntax can be quite confusing if you’re not sure what you’re looking at. For example, this was one of our tasks:

jshint: {
  options: {
    jshintrc: '.jshintrc'
  },

  gruntfile: {
    src: 'Gruntfile.js'
  },

  web: {
    src: // files
  },

  test: {
    src: // files
  }
},

At first glance, it might look like there are 4 subtasks, but really there are only 3 while one, the options, is configuring the task for the other subtasks. Once you have this knowledge it’s easier to read, but when looking at this code for the first time, it can be very confusing. We had many more examples similar to this where it just wasn’t easy to see what the task was doing easily.

The second point, ‘fast’ was also hard for grunt. While it wasn’t slow, it also wasn’t very fast. Running tasks seemed sluggish, and running a task that in-turn ran multiple tasks really showed grunt’s weakness: sequential execution. While sometimes it’s nice to have a known order of execution, most tasks are mutually exclusive and can be run in parallel without stepping on each other’s toes. Grunt, however, doesn’t support concurrent execution, so these multi-task tasks took even longer.

Being simple to change became an issue partially because of grunt and partially because of our own bad practice. As our app grew, our tasks grew. The patterns that grunt encouraged became unwieldy and hard to maintain, but this was because to our app complexity requiring these complex tasks.

The Replacement

Gulp has been taking the javascript automation world by storm. In Javascript Weekly there’s almost always a token gulp article, and major projects like Angular have switched to using gulp over grunt. This perked our interest when deciding what direction to take our automation. As we investigated gulp, we saw that it fulfilled more on our wishlist than grunt did.

Easy to understand – gulp’s syntax is more declarative, making understanding a task easier at a glance than the configuration of grunt. As you “pipe” files from tool to tool, you can almost read exactly what is happening:

gulp.src('path/to/files')
  .pipe(less({
    plugins: [cleancss],
  }))
  .pipe(concat('styles.css'))
  .pipe(gulp.dest(dest));

Speed is another area where gulp trumps grunt. It is specifically the concurrency I wrote about earlier that allows for this. While grunt cannot run tasks concurrently, gulp can. For tasks that have multiple subtasks, this looked like it would create big gains in the speed department.

Simple to change – readability is a big help in this area, but we also learned that this would come down to how we wrote the tasks as much as the syntax of the tool. Switching to gulp gave us a second chance at this.

Lastly, gulp has great support. There are recipes in the repo itself and many, many tutorials online on how to get started.

The Execution

Setup

After seeing our gruntfile grow to an unmanageable size, I wanted to avoid getting into that same state with gulp. One recipe describes how to split up your tasks per file. I liked that idea, but I wanted to be a little more verbose about what tasks were available to the developer when they opened up the gulpfile without having to dive into a tasks directory or open up individual files and read the tasks inside. After searching around for a little while, I settled on this pattern:

Directory Structure

gulpfile
gulp/
|--index.js
|--tasks/
   |--task1.js
   |--task2.js

gulp/index.js

var gulp = require('gulp');

module.exports = function(tasks) {
 tasks.forEach(function(name) {
   require('./tasks/' + name);
 });

 return gulp;
};

gulpfile.js

var gulp = require('./gulp')([
  'task1',
  'task2',
]);

gulp.task('default', ['task1', 'task2']);

This allows me to easily create and pull in new tasks, but I can still get a gist of all my available tasks by just opening the gulpfile. This structure also allows for tasks that don’t need to be visible (other top-level tasks just depend on them) to not muddy up the code. For example, we inject a cache buster when optimizing our code, which I split into a different task but that task never needs to be run by itself, just when the optimize task is run. I don’t have to list the ‘cache-buster’ task in the gulpfile, only the ‘optimize’ task.

Configuration

The next step was to figure out how to handle code paths in the tasks. Some tasks depended on the same code paths meaning I’d be duplicating those paths in each task definition. As we had experienced before with our gruntfile, what if a path changed? I’d have to make sure that each spot where those files are referenced was updated. Instead of dealing with that like we had before, I came up with a simpler solution: a config file. This file lives in gulp/ as config.json. It holds all the file paths needed for every task, and each task just pulls in the config file and uses the variable it needs.

gulp/config.json

{
  "files": {
    "scripts": "public/scripts"
  }
}

gulp/tasks/jshint.js

var config = require('../config.json');
var gulp = require('gulp');
var jshint = require('gulp-jshint');

gulp.task('jshint', function() {
  return gulp.src(config.files.scripts)
    .pipe(jshint());
});

gulp/tasks/watch.js

var config = require('../config.json');
var gulp = require('../index')([
  'jshint',
]);

gulp.task('watch', function() {
  gulp.watch(config.files.scripts, ['jshint']));
});

Now if the path of the scripts changes, I only have to change the config.json file and the dependent tasks stay the same.

Tasks

After all the infrastructure was in place, it was very easy to start writing tasks that we needed. As our task list grows and needs change, the complexity of our gulpfile and setup won’t. I was able to copy files, optimize code, compile LESS, watch for changes and even implement livereload without a single task file growing to over 30 lines of code.

Conclusion

So to recap, after letting our gruntfile fall into disarray and getting frustrated with it’s complexity and sluggish speed, we decided to see if there were greener pastures. After investigating what we wanted in an automation tool, we found that gulp allowed for easier syntax, simpler task setup, and faster task execution. By leveraging some shortcuts and tools of gulp like cache and livereload, we’ve seen a dramatic increase in the productivity of our frontend development due to gulp, all while having a simpler structure that’s easy for new and existing customers to get caught up on.

The post From Grunt to Gulp appeared first on Clarify Solutions | Dovetail Software.

Faster all around

We’ve improved performance throughout the application, both on the front and back-end.

On the back-end, we’ve upgraded our major infrastructure components (including FUBU MVC, StructureMap, and Dovetail SDK), which improves the application startup time, as well as improves the time to process every request. We’ve also made improvements to the SQL generation module, which improves the performance of many database queries. In addition, queries are no longer executed on items without any relevant filters, which means fewer queries and better overall performance.

On the front-end, Dovetail Agent is now a true SPA (Single Page Application), which means navigating through the application is much faster. There are less requests from the client to the server, and less data (scripts, templates, css, etc.) being transferred. From a user’s standpoint, it definitely feels faster.

Navigation Menu

The Navigation Menu (the left sidebar that shows up on the console pages (My Work, Queues, Queries, Searches, Recent Items)) is now accessible from every page in the app. This allows users to access the Navigation menu from anywhere without having to return to the home page. This makes moving through the application much easier and faster.

In addition, the Navigation Menu can be hidden, and the page content will expand to fill the entire page. The app will automatically remember the menu’s hidden/displayed state, so if you want it hidden, it’ll stay hidden (until you explicitly display it again).

Here’s a short video showing the improved navigation menu:

From the video you can also see how quick the app is.

And don’t forget about the Keyboard Shortcuts, which also allow users to quickly navigate through the app.

Advanced Search

We’ve added a new advanced search page to the app. When you search using an internet search engine such as Google, most people simply type into the standard search box. But there’s also a Google Advanced Search option, which helps guide you through a more, uh, advanced search. We provide a similar option.

From the Search page, simply click the Advanced Search link, and you’ll be able to create more advanced searches easily.

Read more about the power of search in Dovetail apps.

Default Avatars

Previously, the default avatar was the same for everybody:

Now, the default avatar is the user’s initials, which provides more context and makes it easier to visually parse the history.

Of course, it looks even better when user’s have uploaded their own avatar:

Additional Niceties

• The activity spinner and a “Searching…’ heading is now displayed when waiting for search results to appear
• Added a “Case Type” filter for subcases, which filters on the case type of the related case for the subcase
• Empty tabs for My Work now show a better message to the user – especially helpful for new users and the “first-run” experience.

Summary

We’re really excited for this release – the performance improvements are definitely noticeable, and the Navigation Menu improvements really do make it much quicker and easier to navigate throughout the app.

Couple that with the additional enhancements and niceties, and it all adds up to a pretty awesome release.

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

IE is a different story, which pretty much all of us in the tech community are well aware. Continuing to support older versions of IE is more and more difficult. But, we are sensitive to the challenges of upgrading IE in enterprise environments. For Dovetail Agent, we support IE 9, 10, and 11. IE 9 has its challenges for sure.

Many organizations have stopped supporting older versions of IE, including Google.  And Microsoft recently announced that they were dropping support of older versions of IE.

Barrett Sonntag (one of our developers here at Dovetail) has written a post outlining a recent challenge we ran into where IE9 would crash when dragging, scrolling, and updating styles. This was an issue that a customer reported when running Dovetail Agent on IE9. Barrett ended up going deep into the bowels of IE, using Windows debugging tools to help figure out what was happening. He was able to find a workaround to the problem.

His post is just a little glimpse of some of the challenges and hurdles we have to surmount when continuing to support older browser versions.

Hopefully that post will help another developer somewhere who runs into this issue in the future. Thanks for sharing Barrett!

The post Debugging an IE 9 crash appeared first on Clarify Solutions | Dovetail Software.

Some smart folks right there. We created some good stuff that is still in use by many companies today.

And checkout that scrum board!

The post Throwback Thursday: Our development team in 2007 appeared first on Clarify Solutions | Dovetail Software.

We’ll walk through an example on troubleshooting a specific issue.

In this scenario, Rulemanager logged an error:

2015-06-12 10:23:07 [Consumer7] ERROR
FChoice.RuleManager.OperandException – FChoice.RuleManager.OperandException: (-1)
Invalid operand format for an IsIn operator.

It looks like there was a problem with a rule condition that uses an IsIn operator. So how do we know which rule this is referring to? There may be hundreds of rules in the system.

All of the needed information is contained in the log file. But since Rulemanager is a super busy application, and it’s multi-threaded, the logs contain a LOT of information.

In a log file I recently received from a customer, there’s over 650,000 lines in a single log file.  How do I narrow this down?

Narrow by Thread

In the error message, take note of the information that comes after the timestamp. In this case “Consumer7”. This is the thread. We can use this to narrow down our logs to just contain the information for this thread.

Since I love my UNIX tools, I can easily extract just the logs for this thread into a separate log file using cat and grep.

cat RuleManager.log | grep -i “consumer7″ > consumer7.log

That creates a file named consumer7.log, and narrows me down from 650,000 lines to just 3500. Much more manageable to work with.

Now I simply open that consumer7.log file using my text editor and search for the error. In this case, I search for “Invalid operand format for an IsIn operator”

Logs

Now that I have just the thread logs, I simply start reading up the file.

Here’s the log entries showing the error as well as the handful of entries immediately before the error (I’ve removed the timestamps and class names for brevity)

Found Start event “DISPATCH” for Rule “Cashiering subcases”.
Evaluating condition 268451782: Property: “Current Queue”, Right operand: “(Cashiering’)”, Operator: “IsIn”, Type: “String”
Item “Current Queue” was retrieved from the Repository cache.
Path “case_currq2queue:title” expands to SQL command “SELECT T1.objid, T1.TITLE FROM table_case T0, table_queue T1 WHERE T0.objid = {0} AND T0.case_currq2queue = T1.objid ORDER BY T1.objid DESC”
Property “Current Queue” using “case_currq2queue:title” expands to “Escalation”
RuleManager.ConditionOperators.IsIn – Forcing both operands to be of type “String”
RuleManager.OperandException: (-1) Invalid operand format for an IsIn operator.

Log Entries, One by One

So, looking at the logs just for this thread, we can see exactly what happened:

1. Found Start event “DISPATCH” for Rule “Cashiering subcases”.

We have a rule named “Cashiering subcases”, and it has a start event of Dispatch

2. Evaluating condition 268451782: Property: “Current Queue”, Right operand: “(Cashiering’)”, Operator: “IsIn”, Type: “String”

We have a rule condition that looks like: Current Queue Is In (Cashiering’)

3. Item “Current Queue” was retrieved from the Repository cache.

Rulemanager has already cached the path to the Current Queue, so it already knows how to traverse from case to queue without going to the database.

4. Path “case_currq2queue:title” expands to SQL command “SELECT T1.objid, T1.TITLE FROM table_case T0, table_queue T1 WHERE T0.objid = {0} AND T0.case_currq2queue = T1.objid ORDER BY T1.objid DESC”

This is the SQL that retrieves the Current Queue property for this case

5. Property “Current Queue” using “case_currq2queue:title” expands to “Escalation”

The Current Queue property for this case resolves to “Escalation”

6. RuleManager.ConditionOperators.IsIn – Forcing both operands to be of type “String”

Make both conditions be a String datatype, for proper comparison.

7. RuleManager.OperandException: (-1) Invalid operand format for an IsIn operator.

And here’s our error.

So what happened was that we ended up with a rule condition that looks like:

‘Escalation’ Is In (Cashiering’)

And the comparison fails because of the mismatched quotes in the operand, namely: (Cashiering’)

The operand should be: (‘Cashiering’)

Note the missing quote in the original.

Find the rule that has this condition

Now that we know what condition is failing, going back up the log chain tells us which rule this condition is for:

Found Start event “DISPATCH” for Rule “Cashiering subcases”.

It’s the “cashiering subcases” rule that has the bad condition. We can now use the Business Rule UI within Dovetail Admin to fix the condition, and quote the string properly.

Plan B

Alternatively, since we know the objid of the rule condition from the logs:

Evaluating condition 268451782: Property: “Current Queue”, Right operand: “(Cashiering’)”, Operator: “IsIn”, Type: “String”

We can use SQL with that objid to find the specific business rule:

select title from table_com_tmplte where objid = (select parentrule2com_tmplte from table_rule_cond where objid = {RuleConditionObjid})

So in our case, it would be:

select title from table_com_tmplte where objid = (select parentrule2com_tmplte from table_rule_cond where objid = 268451782)

And this again gives us the name of the business rule with the bad condition: Cashiering subcases

We can now use the Business Rule UI within Dovetail Admin to fix the condition, and quote the string properly.

Summary

Dovetail Rulemanager is a critical component of a Dovetail/Clarify implementation. When something doesn’t work as it should, spending a few minutes tracking down the issue is typically well worth it.

Even though the Rulemanager logs can be very verbose, they can also be super helpful in tracking down an issue. Hopefully this post gave you a few ideas of how to make this process easier.

Related Readings

How Do I Get Notifications When Dovetail Rulemanager Cannot Process A Timebomb?

Troubleshooting Bad Time Bombs

Rulemanager Companion Wiki

The post Troubleshooting a bad business rule appeared first on Clarify Solutions | Dovetail Software.

The heavy lifting for search is all handled on the back end by the Dovetail Seeker application. But the front-end is what users interact with, so we’ll cover that here.

(BTW – If you’re looking for information on Dovetail Seeker, check out one of these posts, or review the docs.)

On the surface, it’s pretty easy to use – put in some search terms and find what you’re looking for.  But there’s a lot more power available, and I wanted to touch on a few of these options.

For the most part, I’ll cover search within Dovetail Agent, although much of this applies to all of our applications.

What can we search for?

Out of the box, Dovetail Agent is setup to search for

• Cases
• Subcases
• Solutions
• Sites
• Contacts
• Employees
• Accounts
• Contracts
• File Attachments on these objects
• Any document collections you’ve setup – such as your product documentation

We often to refer to these as search domains.

A simple configuration changes removes items that aren’t used as part of your implementation. So if you don’t use Contracts, it’s super easy to not have that show up as part of your search options.

You can also customize to search for custom objects.

By default, when you search, it searches across all of these domains.

So if you’re looking for something in the app, just search for it. More than likely you’ll find it.

Looking for a case with some keywords within the notes? a file attachment with certain text? a site based on its name? a contact based on name or phone number? a contract based on the covered site? an employee based on name? cases for a particular contact? a solution with certain text?

Just search – and it’ll probably be found.

Search for everything

Notice we found sites, accounts, contracts, and contacts. (and cases and subcases that I didn’t include in the screen shot)

Limit the search

You can then click to limit your search to just the domain that you want, such as Site:

Now we’re seeing just the sites that were found.

Find by ID

In Dovetail Agent, we don’t have a separate Find by ID form, like the Clarify Client did. Instead, just use the search box:

The search will find cases, solutions, sites, etc – just using its ID:

I discussed this specific use case in a blog post a few years ago – Making the app work the way the user expects it to work.

Search Operators

There are a number of operators that you can use as part of your search.

Wildcards

Advanced Tips

Property searches

When items are setup for indexing (part of Dovetail Seeker), each item can have properties defined, which allow users to search just by that property.

For example, for Cases, we have condition, type, and created date all defined as properties.

Which means we can do searches such as: search for all open cases created in the last 30 days with a case type of please specify:

condition:open* created:30days type:”please specify”

Search Tips

How do I remember all of these operators? And how do I know what properties are available on each item?

Don’t worry – we’ve got you covered. From the Search page, simply click the Search Tips link, and we provide all the information you need:

Advanced Search

When you search using an internet search engine such as Google, most people simply type into the standard search box. But there’s also a Google Advanced Search option, which helps guide you through a more, uh, advanced search. We provide a similar option.

From the Search page, simply click the Advanced Search link, and you’ll be able to create more advanced searches easily.

Favorite a Search

If you have a search that you use often – make it a favorite. Simply click the star icon next to the search box, and that search will be saved in the Favorite Searches list in your Navigation Menu.

Super advanced crazy undocumented search options

Dovetail uses the Lucene search engine, so the standard Lucene modifiers are supported. Most of them we’ve covered above, and are listed on the Search Tips page within the app.

But since we’re using Lucene, we can also use their more super-advanced crazy search operators.

Fuzzy Searches

Lucene supports fuzzy searches based on Damerau-Levenshtein Distance. To do a fuzzy search use the tilde, “~”, symbol at the end of a Single word Term.

For example to search for a term similar in spelling to “coat” use the fuzzy search:  coat~

Proximity Searches

Lucene supports finding words are a within a specific distance away. To do a proximity search use the tilde, “~”, symbol at the end of a Phrase.

For example to search for a “solution” and “boat” within 10 words of each other in a document use the search:

"solution boat"~10

Term Boosting

Lucene provides the relevance level of matching documents based on the terms found. To boost a term use the caret, “^”, symbol with a boost factor (a number) at the end of the term you are searching. The higher the boost factor, the more relevant the term will be. Boosting allows you to control the relevance of a document by boosting its term.

For example, if you are searching for: clearbasic process

then we get the results back in the normal order of relevance:

If we want to boost the clearbasic term, then we can use: clearbasic^4 process

This will make documents with the term clearbasic appear more relevant. We can see that the results have a different order now:

Summary

It’s common that CRM systems are focused on getting information into the system – but we also need to be able to find the information once it’s in there.

Queries and Reporting are great – but when you need to do full-text-searching, robust search functionality is pretty awesome.

We’ve tried to make it simple and intuitive, while also providing the advanced options that power users need.

Have any suggestions for improving Search? Leave a comment below, or drop me an email.

Rock on.

The post Seek and ye shall find – the power of Search in Dovetail apps appeared first on Clarify Solutions | Dovetail Software.

And it’s been 10 years since then, which means we’ve now been around as a company for 20 years!
Guess it’s time for some updated company swag.

The post Throwback Thursday: 10 years of First Choice Software appeared first on Clarify Solutions | Dovetail Software.

File attachments are supported on the following items:

• cases
• subcases
• solutions
• contracts
• site parts
• accounts

We’ve made it super easy to add a file, which uploads it to the server and “attaches” it to the item. File attachments are stored in a common location on the server.

Gone are the days of file attachments in the Clarify Classic Client where a file attachment resided on someone’s C drive, and couldn’t be accessed by anyone except the user who added the file attachment.

Plus-One

On each item, there’s a Files tab. Click on the tab, then click the + on the tab header. (From a development standpoint, we commonly refer to this as our plus-one pattern, where you click the plus sign to add one more related item)

This will open a file picker, allowing you to pick the file to be uploaded.

Keyboard Shortcut

The “u” keyboard shortcut will also open a file picker – without having to click the Files tab first.

Drag and Drop

Users can also simply drag and drop files onto the Files tab. Multiple concurrent file uploads are also supported.

This video shows this in action:

I especially love this drag and drop feature. I find it quick and easy to use.

Files

Once files are uploaded, they are listed on the Files tab. The file name is listed, along with who uploaded it and when.

For images, we also show a thumbnail of the image. Clicking that thumbnail opens the image in a lightbox in a larger size.

For non-images, we show an icon indicating the file type.

For files that are attached to a workflow item (such as case, subcase, and solution), the files are also shown in the History, and images are rendered inline.

I previously blogged about this – including a video showing files and images in the history.

Summary

Log files, screenshots, Word docs, Excel spreadsheets – all are common files attached to items within a CRM system.

We’ve tried to make it super easy to upload files into the system, as well as view and download them.

Hope you dig it.

The post File uploads in Dovetail Agent appeared first on Clarify Solutions | Dovetail Software.

This request comes up when a bunch of test cases get created, or if a customer goes out of support, or a bad email loop creates cases by mistake, or a myriad of other reasons.

Find the cases you want to close

First step – create a query for the cases you want to close.

I want open cases created in the last 365 days with the word “test” in the title.

So, I created a query with 4 filters:

1. Condition Starts with Open
2. Item Type Is Equal To case
3. Created within last (days) 365
4. Title Contains test

Run the query to get results:

Select all the resulting cases using the Select All checkbox:

Select the Batch Actions menu:

Notice that the close menu item tells us that only 6 out of the 19 cases can be closed.

Why?

• Some of the cases are owned by someone else. Application rules enforce that you can only close cases you own.
• Some of the cases are in a queue. Application rules enforce that you cannot close cases that are in a queue.
• Some may have open General subcases. Application rules enforce that a case cannot be closed if it has open General subcases.

We could yank the ones we don’t own, and accept the queued ones.

But, before we do that, I typically take one other step: I tag them.

Why tag them?

This is to handle the situation where a workflow operation (such as yank or accept) could change the query results.

For example, if you wanted to close all the cases that are in the Test queue, your query would look like:

Lets say that the query returned 10 results. If I then accepted or yanked all of these cases, then that query would return zero results. So how do I get back to the cases that I want to close?

Tagging solves this.

OK, back to the task at hand.

Tag ‘em

Using the same Batch Actions menu, we choose Add Tags, and give it a tag name. My tag is named “to be closed”. Clever, I know.

Take ownership

Now that they’re all tagged, we can yank and accept them – using the same Actions menu.

Close ‘em

Now that we own them all, and they’re no longer queued, and they’re tagged, we can close them.

From your sidebar, under Tags, click on the to be closed tag, which will shows all of those cases:

Select All using the checkbox

Now the Actions menu doesn’t warn us about any that can’t be closed. So we’re good to go.

So we simply choose the Close menu item, select the desired status, resolution, and notes – and click the Close Case button

And we get the notification that 19 cases were closed:

Success.

Recap

1. Query for the cases you want to close
2. Tag them (using the Batch Actions menu)
3. If needed, take ownership of them (yank/accept using the Batch Actions menu)
4. Close them (using the Batch Actions menu)

Summary

The Batch Actions menu in Dovetail Agent is a pretty powerful tool, and makes it easy to perform the same workflow actions on multiple items.

Hope you find this useful.

The post Closing a number of cases at once appeared first on Clarify Solutions | Dovetail Software.