REQUEST A DEMO

Tag: business rule

More Campfire Integration

February 13, 2008 Kevin Miller recently had a recent post talking about how we have notifications from our Clarify/Dovetail system show up in Campfire.   When a case is dispatched to our support queue, we get a notification in Campfire. That tends to be where we all "hang out", so its a perfect place for group notifications.   Kevin had another great idea today that we should also post a message when the case is accepted by someone, so that we know someone has picked it up and is working it.   A quick business rule:   Object Type: Case Rule Name/Description: Campfire notification upon case accept Start Event: Accept Cancel Events:  Conditions: [Current Owner Workgroup] = Support Action Title: Notify Campfire Action Type: Command Line  Start Action: 0 minutes From: Event Creation Using: Elapsed Time Repeat: Never Message:   c:\ruby\bin\ruby.exe C:\repo\DovetailAutomation\focus\campfire\classic-campfire.rb " [Object Type] [Object ID]  has been accepted by [Logger]. : http://www.dovetailsoftware.com/fcclient/console/console.asp?command=casebyid&param1=[Object ID] "…

Testing Business Rules

January 3, 2008 More and more I'm starting to pay attention to the discussions regarding DSLs (Domain Specific Languages). Specifically, I've been thinking about business rules as a sort of DSL. Scott Bellware and I have had many conversations about this. To me, how we define business rules is a good example of a Business DSL.   A simple business rule example: Object Type: Case Rule Name/Description: Notify all queue members upon dispatch Start Event: Dispatch Cancel Events: Accept Conditions: None Action Title: Notify Queue Members Who to Notify: Current Queue Members Start Action: 0 minutes From: Event Creation Using: Elapsed Time Repeat Every: 4 hours Repeat for: 999 days Message: [Object Type] [Object ID] has been dispatched to queue [Current Queue].     Ayende had a recent post that touched on keeping DSLs under source code control, and testing DSLs.   This got me to thinking about an issue we have in Clarify today.   If…

Are Queue Supervisors also Queue Members?

December 10, 2007   We've recently had a couple questions from customers in regards to queue members and supervisors. There is definitely some weirdness here, so hopefully this post will clear up a little confusion.   In Clarify, there are two relations from queue to user: queue2user, a ManyToMany relation, which is the users assigned to the queue queue_supvr2user, a ManyToMany relation, which is the users supervising the queue Queue Membership in the Clarify UI   In the Clarify Classic Client, when you add a user as a supervisor, you see the user listed only as a supervisor.   For example, here I just added the user "texas" as a supervisor of the WebSupport queue. Notice that he shows up in the Supervisors list, but not in the Members list. As expected. Notice there are only two queue members listed.   Queue Membership…

Automatic Subcase Creation

November 14, 2007 While working with a customer this week, they asked about automatic subcase creation, similar to Clarify's Task Manager module.   For example, if a new case of type "New Employee" is created, then I want to automatically create 3 subcases: One subcase for setting up network accounts, dispatched to the network queue One subcase for ordering office furniture, dispatched to the furniture queue One subcase for ordering a new computer, dispatched to the hardware queue   This is easily accomplished with a business rule and a simple script. The script   A simple PowerShell script (my favorite new scripting environment) which takes 1 input parameter (a case id number), and then calls the CreateSubcase API that is part of the Dovetail SDK to create subcases and dispatch them to the appropriate queue.   $connectionString = "Data Source=moorea;Initial Catalog=dovetail;uid=gary;pwd=not4youris"; $databaseType =…

Migrate a business rule from one database to another

November 13, 2007 I was working with a customer today, and they mentioned that one task that is problematic for them is moving business rules from their test database into the production database. Currently, the business rule is manually created via the Clarify Client in the test instance, and then when its all working, it is then again manually re-entered into the production. Manual re-entry is a point of potential failure. The rule may have been perfect in test, but a simple typo when re-entering it in production can cause havoc.One solution to this issue is to archive the business rule using ArchiveManager or dataex from the test database, and then use ArchiveManager or dataex to import it into production.Business RuleFirst, I created a new business rule in my test system:Object Type:CaseRule Name/Description:New Employee RequestStart Event:DispatchCancel Events:NoneConditions:Case Type = New EmployeeAction Title:Create SubcasesMessage…
    class='wp-pagenavi' role='navigation'>
  • ...
  • 2
  • 3
  • 4