A few years ago I wrote a post titled Getting the most out of your business rules. Most of the information in that post is still relevant today.
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.
One of the available extensions within Dovetail Carrier is the Parent-Child Cases Extension, which allows for automating workflow processes involving parent and child cases.
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 …
Dovetail Agent has a number of Work Item types. The most common are Cases, Subcases, and Solutions.
In addition, there are Change Requests, Part Requests, and Action Items.
Not everyone is familiar with Action Items, so this post will cover the basic of action items – what they are, how you might use them, and how they compare to cases.
Action Item Basics
Action Items are simply a task that needs to be completed.
The task could be any number of things – depending on how you wish to use them.
For example, an Action Item could be used:
To setup a customer’s online account for SelfService/WebSupportAs an Operations task, such as upgrading a serverTo track a contract renewal processetc.
You can use different action item types for different tasks, so you’re not limited to a single use case for action …
I’ve often stated that Rulemanager and Business Rules within Clarify/Dovetail are the most powerful (but often underused) components of the system.
And when you combine Rulemanager with Dovetail Carrier, it gets even more powerful.
To demonstrate some of this power, I’ve created a collection of business rule recipes that will educate and inspire you to make the most of your business rules.
There’s over 30 business rule examples, and they stretch across a number of areas, including:
User NotificationsWorkflow AutomationCustomer NotificationsIntegrating with third-party services/appsTask ManagerCalling external apps/scriptsSLA Rules (Service Level Agreement)Bonus!
There’s also a Business Rule Template, which is helpful when defining new business rules.
It can be provided to business users, who can fill out the template and submit it to the technical staff.
This Collection of Recipes and the Business Rule Template is completely free.
Simply click …
When working with parent-child cases, a common workflow is to close the parent case when all the child cases have been closed.
We can easily automate this workflow using Dovetail tools and applications.
Here’s the rule that I want to create:
When the last child case is closed, close the parent case.
In order for this rule to function, I need to know when the last child case is closed.
I can do that by looking at the number of open child cases on the parent case. When this number is equal to zero, I know that all of the children have been closed.
But, out of the box, this number is not an available property.
But I can easily create my own, using the function-based rule property functionality.
NumberOfOpenChildCasesOnParent Rule Property
Following the …
Rule properties are used in a number of places throughout the Dovetail suite, including:
Business Rule ConditionsBusiness Rule Action MessagesCanned Response VariablesTask Manager PropertiesEmail Log Templates
Traditionally, a rule property would traverse a path through the schema, starting from the base object, and ending at a column.
For example, the Contact First Name property for a case would use the path case_reporter2contact:first_name.
However, there are instances where a path cannot be traversed, or where a calculation needs to be made.
For example, you may wish to fire a business rule only if all of the subcases on a case have been closed.
So your two business rule conditions would be:
Number of Subcases is greater than zeroNumber of Open Subcases is equal to zero
Or, you may wish to fire a business rule if the …
I absolutely LOVE this new capability within the system, and I’m super excited to see how our customers use this power.
I received an email from one of our customers this past week detailing how they’ve been able to take advantage of this new functionality.
Just wanted to pass along that we implemented a biz rule action to call into the Support SDK directly in PROD. Pretty awesome stuff! Use case here is that an external process …
Within Dovetail Agent, we support both Subcases, and Parent-Child Cases.
A common question is: What’s the difference, and when would I use one vs the other?
So lets address that question here.
Subcases allow for multiple employees to work in parallel on a single Case. You can “subcontract” pieces of the work to other employees.
For example, we may have a Case for a New Employee. As part of that, we can create 3 subcases:
Create a General subcase for setting up the employee’s network account and dispatch to the Network queue. Create an Administrative subcase for ordering business cards and assign to the office …
Photo by @benchaccounting
When setting up your auto-destination rules, it’s easy to end up with rule bloat, sometimes due to no fault of your own.
Due to business requirements, you may end with a lot of rules, which end up making it difficult to manage all of them.
For example, we may have auto-dest (routing) rules that dispatch a case to a queue based on its case type and the country of the reporting site/contact.
If the contact is in the USA, and it’s a Payroll case, send it to the USA_Payroll queue. If the contact is in the USA, and it’s a Benefits case, send it to the USA_Benefits queue. If the contact is in France, and it’s a Payroll …
Recall that a change request is a task you create in response to a reported software bug, hardware defect, or enhancement request.
As Change Requests are worked, they follow a workflow process. We use Statuses and Transitions to define the process, and define who can move the Change Request through its workflow steps.
Technically, Cases also support a workflow and defined transition. It’s just a very simple one.
We can use Cases as a simple example before moving on to the more robust workflow options with Change Requests.
Cases have just 2 conditions: Open, and Closed.
A case can move from Open to Closed, and from Closed to …