Did you know we provide a few different information feeds that help you stay informed with information about Dovetail? By subscribing to feeds, new information is delivered to you – which means you don’t have to go visiting lots of different web sites to see if there’s new content available.
Blogs
There’s a RSS feed for all the Dovetail bloggers, or you can subscribe to individual bloggers, if you so wish, by visiting their page and clicking the orange RSS icons in your browser or by clicking the RSS link.
Some of us also allow for subscribing by email, in case you’re not an RSS kind of person.
Product Releases
There’s a feed for product releases – so you’ll know when new products are available – including new revisions of existing products.
Knowledgebase
There’s also a feed for new knowledgebase articles. This feed is interesting because it allows you insight into new Solutions – including some best practices, bug fixes, how-tos, and workarounds.
Solutions and Product Releases? That sounds like CRM data.
Those last two feeds – Product Releases and Knowledgebase – the data from those come from our Dovetail / Clarify system. No surprise – the knowledgebase is Solutions (problem descriptions and workarounds), and the product releases are Parts (part numbers and mod levels). We use the Dovetail SDK to retrieve the data that we want (solutions, part revisions), and then a little bit of ASP.NET code to create the feed. Kevin Miller has a nice write-up explaining how to create RSS feeds using ASP.NET.
Pretty sweet!
What other data could you syndicate out of your CRM system? For your employees? For your customers?
RSS?
Confused about feeds and RSS? No worries. The folks over at Common Craft have put together a simple video explaining RSS in plain English.
It's like deja vu all over again.
Hope you find this post (as well as our other information feeds) useful.
Rock on.
While setting up some advanced capabilities of DovetailAgent, we ran into some IIS/Windows permission issues. This post is to capture and share some of the learnings.
To start with, Kevin Miller has a good post on installing Classic ASP web application on IIS7.
The “advanced” capabilities I’m referring to was setting up file attachment uploads, and saving those files off to a permanent file storage area, accessed by a UNC drive such as \\fileServer\attachments
Environment: Windows Server 2008, Dovetail Agent 4.3
File Uploads
The way file uploads work is that the file is first uploaded to the web server where DovetailAgent is running. Then, the application moves the file to the permanent storage location, which is commonly a share on a different server. The application also creates directories and subdirectories where needed. So if your base attachment directory is \\fileServer\attachments, a file may actually get stored in \\fileServer\attachments\case\12345\file.ext
Initial Steps
Make sure you have followed the Configure the Web Server and Install aspSmartUpload steps from the Dovetail Agent documentation.
As I mentioned earlier, if you’re using IIS7, review the post on installing Classic ASP web application on IIS7.
Permission Denied Error
If you’ve done all of this, and you try to upload a file attachment, you may encounter a Permission Denied error (from the attachment2.asp page).
This can happen because the anonymous IIS user does not have permission to access the remote file share, such as \\fileServer\attachments.
We want the user that is executing the web app to be able to write to that remote directory. Here’s one way to set this up.
- Create a domain user that has access to this file share.
- Use this domain user as the application user for the web app.
Domain User
Lets say we create a user called mydomain\dovetail_app
File Server Config
On the \\fileServer, be sure that the domain user has read and write permissions to the attachments directory. This is best achieved by setting the NTFS permissions (as opposed to setting permissions on the share itself).
Web Server Config
We can then set the Identity of the Application Pool to this user. Right-click on the application pool, and choose Advanced Properties. Set the Identity to be the domain user
Make sure your DovetailAgent application belongs to the application pool:
Click the Authentication icon for the application:
Right-click on the Anonymous Authentication item:
Set the Anonymous Authentication Credentials to be the Application Pool Identity:
Now, the app will run as the same user as the application pool, which is the domain user that we configured the app pool identity as earlier.
You should now be able to successfully upload file attachments.
File Downloads
When downloading a file attachment, the DovetailAgent application transforms the physical file path into a URL. As part of the initial install steps for DovetailAgent, as part of Configure the Web Server, an attachments virtual directory / application is setup.
This should be an application, not just a virtual directory. If necessary, right-click on the attachments virtual directory (within IIS Manager) and choose Convert to Application.
Physical Path
The physical path of this application will be the remote file share, such as \\fileServer\attachments.
Set the Application Pool
Be sure to add this application to the same Application Pool as DovetailAgent. (same as we did earlier for the Agent application)
Set the Anonymous Credentials
Be sure to set the Anonymous Authentication Credentials to be the Application Pool Identity. (same as we did earlier for the Agent application)
You should now be able to successfully download file attachments as well.
Phew!
No doubt, there’s a bunch of configuration to do. But hopefully this post will help.
We're looking for a proven .NET technical lead for one of our product lines. You'll be working on a small team that develops applications for large businesses using some of the latest technology. You will work closely with the VP of Products, and will be involved in all aspects of solution development, including analysis, design, development, testing, documentation, and support.
Expectations include
- software design, system architecture, process improvement
- mentor to other team members
- technical leader on product architecture and quality
- validate complete product and system testing
- partnering with other team members to share learnings, create and educate on best practices, and improve the overall efficiency and productivity of the development organization
Participation in the community (blogger, attendance of events, avid blog reader + commenter, etc.) will put you firmly in the running for this position. We’re looking for people that believe learning and continuous improvement are primary responsibilities of a software developer.
Our practices and technologies include:
- Test-driven development
- Continuous integration
- Behavior-driven design
- Domain-driven design
- HTML, CSS, Javascript (jQuery)
- ASP .NET MVC
- FubuMVC
- C# 3.0, .NET 3.5, Visual Studio 2010
- SQL 2008
- Oracle
- NHibernate 2.x
- StructureMap
This is a hands-on coding position. Non-coding architects need not apply
This is a full-time, on-site position in our Austin, TX office. Please DO NOT contact us for outsourcing or tele-commuting.
Email us and tell us why you’d make a great addition to our team: tech-jobs@dovetailsoftware.com
When working cases in Clarify / Dovetail, an option available to agents is Initial Response. Initial Response allows an agent to mark that the initial response to a customer has occurred.
True to its name, an Initial Response can only occur once in the history of a case.
This Initial Response operation can be performed on either the Log Phone call or Log Email forms.
Initial Response button in the User Interfaces
Phone Log form in the Clarify Classic Client:
Email Log form in the Clarify Classic Client:
Phone Log form in DovetailAgent:
Email Log form in DovetailAgent:
Activity Log
When the Initial Response action occurs, it is logged to the case activity log:
Time Bomb
When the Initial Response action occurs, a time bomb is created. Once we have a time bomb – we can create business rules. And y’all know how much I love business rules!
Business Rules
One of the more common business rules that everyone talks about is that a case must be accepted from a queue within a certain period of time. This is OK – but a customer really doesn’t care that a case was accepted from a queue – they want a response and an answer. We can use the Initial Response activity in a business rule to accomplish just that.
Here’s a couple of examples (take note of the Initial Response as the cancel event for the rules):
Business Rule: Urgent severity cases should be responded to within 2 hours
Object Type: Case
Rule Name/Description: Urgent severity cases should be responded to within 2 hours
Start Events: Create
Cancel Events: Initial Response
Conditions: Severity = Urgent
Action 1:
Action Title: Notify Owner
Who to Notify: [Current Owner]
Start Action: 90 minutes
From: Event Creation
Using: Elapsed Time
Repeat : Never
Message:
RE: Urgent Severity Case SLA Warning
Case [Case ID Number] is nearing its initial response service level agreement.
The case has been opened for 90 minutes - It must be responded to within the next 30 minutes.
You are being notified because you are the owner of the [Object Type].
You can view the case at: http://support.company.com/dovetail/Cases/Summary/[Case ID Number]
Action 2:
Action Title: Notify Owner & supervisor
Who to Notify: [Current Owner], [Current Owner Supvsr]
Start Action: 120 minutes
From: Event Creation
Using: Elapsed Time
Repeat : Never
Message:
RE: Urgent Severity Case SLA Expiration
Case [Case ID Number] has hit its initial response service level agreement time limit.
The case has been opened for 120 minutes.
The case owner is [Current Owner First Name] [Current Owner Last Name]
You can view the case at: http://support.company.com/dovetail/Cases/Summary/[Case ID Number]
Business Rule: Notify case owner of support program response time commitment
This is a Clarify baseline rule that is similar to the one above. It uses Initial Response as a cancel event, and it uses the support program’s response time rather than a hard-coded time limit.
Object Type: Case
Rule Name/Description: Notify case owner of support program response time commitment
Start Events: Set Support Program
Cancel Events: Initial Response, Set Product
Conditions:
Action Title: CCN: Spt pgm response notification
Who to Notify: [Current Owner]
Start Action: 90 minutes
From: support pgm response
Using: Cust Spt Prog Hrs
Repeat : Never
Message:
Case [Object ID] is linked to support program [Spt Prog ID:50] on contract [Contract ID:50]. The response time guaranteed by this support program is about to expire, but no action has occurred against the case. Please escalate issue appropriately.
Reporting
Another benefit of Initial Response is that we can use that activity to calculate the time from case create to initial response. This is a useful metric in some support organizations. We have the case creation timestamp, and the initial response timestamp – so a simple data calculation gives us the elapsed time. Using your favorite reporting software, you can start reporting and tracking trends on this value. It’s interesting to see how this initial response time varies over time, and how it varies depending on severity of the case, and/or the medium (phone, email, web, etc.)
Initial Response time based on other activities?
Why not just based the initial response time on other activities?
Well, as explained earlier – basing time to respond on the time that the case was accepted form a queue isn’t really right. The customer doesn’t care when the case was accepted – they want a response – which may be a much later time than when it was accepted.
What about doing it based on a log note, log email, or a log phone call? This might be OK, depending on your workflow. But I can log a note to the case without any communication with the customer. I may also email or call someone else on my team, or a vendor. These will get logged to the case – but they’re not direct communication with the customer.
Setting the Initial Response Automatically
There are some organizations and workflows that want the Initial Response to be set automatically. I’ve done in the past in a couple of different ways.
UI
One way I’ve done this in the past it to customize the UI so that the user is asked if this is the Initial Response.
Something like this (on the Hang Up button of the Log Phone form in the Clarify Client):
Sub POST_Click()
Dim recCase As Record
Dim answer As Long
Set recCase = App.GetContext()
If recCase.RecordType = "case" Then
If recCase.GetField("reply_state") = 0 Then
answer = App.MsgBox ("Is this the initial response to the customer?", cbYesNo, "Initial Response?")
If answer = cbIdYes Then
ClickButtom 'INIT_RESP'
End If
End If
End If
Me.DoDefault
End Sub
Business Rule
Another way to do this is to have a business rule call the Initial Response API. Here’s an example:
Object Type: Case
Rule Name/Description: Set Initial Response on outgoing call
Start Event: Phone Log
Cancel Events:
Conditions:
Phone Log Action Type = “Outgoing call”
Initial Response = 0
Action Title: Set Initial Response
Action Type: Command Line
Start Action: 0 minutes
From: Event Creation
Using: Elapsed Time
Repeat: Never
Message: C:\dovetail\powershell\SetInitialResponse.bat [Case ID Number] [Logger]
The BAT file simply calls a Powershell script named SetInitialResponse.ps1, that calls the InitialResponse API within the Dovetail SDK. Here’s the core of the Powershell script:
param( [string] $caseId, [string] $userName)
#source other scripts
. .\DovetailCommonFunctions.ps1
$ClarifyApplication = create-clarify-application;
$ClarifySession = create-clarify-session $ClarifyApplication;
$supportToolkit= new-object FChoice.Toolkits.Clarify.Support.SupportToolkit( $ClarifySession )
$initialResponseSetup = new-object FChoice.Toolkits.Clarify.Support.InitialResponseSetup($caseId)
$initialResponseSetup.UserName = $userName;
$initialResponseSetup.IsVIAPhone = $TRUE;
$result = $supportToolkit.InitialResponse($initialResponseSetup);
The full Powershell script is available on github at http://github.com/gsherman/powershell.
Business Rule – Log Email
You could also do a similar rule based on Log Email. The events and conditions would probably look different. Perhaps something like:
<snip>
Start Event: Log Email
Conditions:
Email Log Action Type = “External Email”
Initial Response = 0
Log Email Recipients contains [Customer Email]
<snip> Summary
And there you have it – Initial Response. A useful piece of functionality available as part of your Clarify / Dovetail system. Hope you found this useful.
Rock on.
The Dovetail SDK (fcSDK) includes Data Restriction Technology.Data Restriction allows you to segregate your Clarify/Dovetail database so that different sets of users can use the same forms (and customizations), yet see different sets of data from the database. This can include any items such as cases, sites, contacts, parts, etc.
For example, suppose you have two different groups that support different product lines. You might set up Data Restriction so that the users in group 1 can only see group 1's sites, contacts, solutions, cases, and parts. Likewise, group 2 would only see their data. The user’s do not even know that they are not seeing all of the data from the database.
Data Restriction based on Geography
A common data restriction setup is to segregate data via geography. For example, users in Europe may only see data (cases, contacts, sites, etc.) for those customers that are in Europe. Users in North America may see data for customers in the US and Canada. Additional levels can go even deeper – such as Eastern US, Central US, and Western US.
Data Restriction in the Dovetail SDK
Using a simple scheme change, you can put restrictions on any database table or view.
Every time a user performs a query or an update using the SDK, the SDK determines if that table or view is restricted, and automatically modifies the SQL for you. This has one very profound consequence: No form customization is required to use restrictions.
Basically, if you enter restrictions (once) in the database, every time you use the SDK, you will automatically have data restriction working for you. This makes it simple, and easy to use.
Data Restriction Architecture
A restriction set is defined as a set of up to five levels of restriction for an object. The objects with restriction sets are commonly the following:
- employee
- site
- queue
- part number
- script
- action item (task)
- lead
- opportunity
- dialogue
- literature request
- solution
However, you can restrict any objects you want, in any way that you want. It should be noted that many objects in Clarify (such as case and contact), can be best restricted by using a common object (site in this situation).
An administrator starts by creating a set of restrictions that will be given to the users. There can be as many restriction groups as desired, or only a few. It is solely dependent on how each administrator wishes to partition their data as to how restriction groups are set up. Setting up restriction groups well is the key to this product!
Most employees/users will be placed in just one restriction group. That is, the data they should be able to view and modify. But there are times (for examples, managers) where an employee may need to spend time working on different sets of data. In this case, they can be added to multiple restriction groups. But even when a user is placed in multiple groups, only one of those groups can be active at a time. The user can only view/modify data for one restriction group, and if they want to modify/view data from a different group, they have to switch the group they are in.
As mentioned before, Data Restriction works “under the covers.” So, a user who creates a new site will automatically give that site their current restrictions just as a part of creating that site. After that, the site will only be visible to people who have restrictions to see the site.
What about cases and contacts?
A case (and a contact) are both related to a site. So by restricting the site, that same restriction will be used when querying for cases and contacts.
While only a small number of objects are restricted (see above), all of the objects in the system are essentially restricted – using the base restricted objects. For example, contacts are restricted based on the site(s) at which they are located. So even though the product does not place restriction fields on the contact (or case) objects directly, the end-user will still see those as a restricted object.
Tagging
Tagging of data is common in many contemporary applications. Essentially, Data Restriction works a lot like tagging. Entities in the database (such as a site) are tagged, or marked with data that indicates which restriction group they belong to. This tagging happens automatically within the SDK. In addition, the SDK automatically filters data retrieved from the database based on the tag (or tag set) of the current user.
A Data Restriction Example
Suppose you have two customer service representatives in your company; Jane, who takes care of customers for Joe's Clam Shack (JCS) and Betty, who takes care of customers for company Bubba's Bait Shop (BBS).
Now suppose that in your database, you want sites s1, s2, and s3 as customer sites for JCS , and sites s4, s5, and s6 as customer sites for BBS.
The administrator can set the first level restriction of Jane to be JCS, and the first level restriction of Betty to be BBS. When Jane creates new sites s1, s2, s3, their level 1 restrictions will automatically be set to JCS (because a site gets the same restriction set as its creator). Likewise for sites s4, s5, s6 for Betty and BBS.
Now when Jane presses the Find Caller button on the new case screen, she will only see contacts for sites s1, s2, and s3. If Betty performs the same operation, she will only see contacts from sites s4, s5, and s6.
Now you may have a manager (Marcus) who wants to be able to switch back and forth, and see data from either Jane's or Betty's customers from time to time. The system administration can set up Marcus’ account so that he (Marcus) has two restriction sets (one set has level 1 = JCS and the other set has level 1 = BBS) and can switch back and forth between them. Only one set will be active at any time.
It is also possible to break down the restriction sets into finer distinctions by using levels two and three of the restriction sets. Say you have another employee (Edward) who only deals with people from Joe's Clam Shack in the eastern region. His restriction set would look like level 1 = JCS, level 2 = East. You may have yet another employee, Wendy, who deals with Joe's Clam Shack western region. Her restriction set would be level 1 = JCS, level 2 = West. There might be a site s7 with restriction set JSC/East. Edward has access to that site but no others. Jane also would have access to site7 because she has access to any objects whose level 1 restriction is JCS.
Administration Support
The administration of Data Restriction is completed by the Dovetail Admin web application. An admin can setup data restriction groups, assign users to groups, define which entities are restricted, etc.
There is also programmatic access to Data Restriction via the APIs within the SDK. If a user belongs to multiple restriction groups, you can use the FCSession method ChangeResGroup to programmatically change the current restriction group for that user.
Restricting Your Database
The mechanism for modifying your restrictions is to setup the restriction tables provided with this product. A sample restriction file is provided with Dovetail Agent which makes this easy.
There are two fundamental operations that the SDK must perform for restriction to work. The first is that when new rows are added to restricted tables, the SDK must automatically add restrictions to that new row. For example, if the site table is restricted, you want the SDK to add the current user's restriction to each new site row added to the database.
In the lexicon of tagging, these new entities are automatically tagged with the restriction group of the current user.
The other operation that the SDK restriction-enables is querying. For each table or view (you often will data-restrict your views), you will enter one or more rows to the “res_sql_clause” table. Again, a sample file is provided with Dovetail Agent. Each row in this table refers to one “where” clause that will be added to the SQL statement every time you query that table or view. Each of these clauses will be “AND-ed” to the SQL before it is executed.
Data Restriction within an Application
As I mentioned earlier – Data restriction works at the SDK level – so your applications do not have to change to support it – and its essentially invisible to the end users. Lets see what happens using the same exact form (web page) from the same application (Dovetail Agent), but simply logging on as different users.
Logging into Dovetail Agent as a user in the EMEA restriction group, that user will only see the 2 contacts that are tagged as EMEA:
Logging into Dovetail Agent as a user in the North America restriction group, that user will only see the 3 contacts that are tagged as North America:
Logging into Dovetail Agent as a user with no restrictions, that user will see all 45 contacts in the database:
Considerations
I always recommend that organizations carefully consider whether Data Restriction is the right tool for the job. The Data Restriction functionality is powerful, but it does take some careful setup. And it can be a bit confusing to wrap your head around all of the data setup involved. At times, a simple customization to the application itself is all that is needed – as opposed to the full Data Restriction functionality. But when this type of functionality is required – it can be a very powerful tool in your arsenal.
A not-so-uncommon request I’ve heard over the years is the need to be able to close a solution. You can close a case, close an action item, close an opportunity – but you can’t close a solution in the out-of-the-box product. But this is a pretty easy customization – so lets walk through it.
Why close a solution?
Knowledge can become outdated. But we may want to retain that knowledge, especially when we’ve linked these solutions to cases or change requests. By closing it, we can mark it as no longer relevant, and closing will also remove it from a user’s wipbin and all queues.
Status and Condition
Most workflow objects have a status and a condition. We can use a similar mechanism here. We’ll use the Open and Closed Conditions (same as for a case). I create a new user-defined drop-down list to hold the list of statuses for the solution.
Data Model Changes
I’ve added an x_status column to the probdesc table, which will hold the status of the solution.
Dovetail SchemaEditor + a little schemascript does the trick:
<schemaScript xmlns="http://www.dovetailsoftware.com/2006/10/SchemaScript.xsd">
<addColumn name="x_status" table="probdesc" ><length>100</length></addColumn>
</schemaScript>
There is already a relation from solution to condition – so we’re good there.
New Activity Codes
I’ve added 2 new custom activity codes – one for Close Solution and one for Reopen Solution. You can import the DAT file using diet, dataex, or UI Editor. Or create them using the Activity Code UI within Dovetail Admin.
Close Solution API
I created a CloseSolution API. I’ve created it in ClearBasic and in Javascript using the Dovetail SDK)
The code (ClearBasic and Javascript) is available on Clarify Toolbox.
Reopen Solution API
To complete the process (and make testing easier), I created a ReopenSolution API. I’ve created it in ClearBasic and in Javascript using the Dovetail SDK)
The code (ClearBasic and Javascript) is available on Clarify Toolbox.
User Interface
From within the UI (in this example, within the Clarify Classic Client), I added a Close Solution and a Reopen Solution button, which call the APIs when clicked. I also added a bit of code to refresh the form and to proper enable the controls when a solution is closed or reopened.
If so desired, you could get rid of the close and reopen buttons, and simply fire the Close or Reopen APIs based on changing of the Status drop-down control. Pretty trivial to do. Just a different approach.
The code for the solution form (form 321) is available from Clarify Toolbox.
Open Solution:
Closed Solution:
DovetailAgent
A similar customization can be done within DovetailAgent.
Activity Logs
The APIs create activity logs, so you can see when solutions are closed and reopened:
Solution Librarian
Going back to the desire to get solutions out of someone’s wipbin (to reduce clutter) – a different solution I’ve done in the past was to create a Solution Librarian user. This was essentially a dummy user, who we could assign solutions to, thus removing the solutions form our wipbins. This does work OK, but creating dummy users is always a design smell to me, and this means we also lose the true owner (which can be useful in notifications). Just a different approach to the problem.
Closed Solutions
And there you have it. Should you have this need in your business – I hope you find this helpful.
One of the features available within a Clarify / Dovetail system is the ability to “link” cases to solutions.
What this essentially means is that we’ve noted the particular solution that solved the case at hand. For example, if we have a case titled “How do I configure VPN on Windows 7?”, and we have a solution that answers this question, then we can link the case to that solution. In database terms, it simply means we’ve related or joined the case to the solution.
Well, technically, a solution can has one (problem) description and can have many workarounds, so we’re actually relating the case to one of the workarounds, but don’t worry about that for now. Just think of relating the case to the solution.
Obviously, having re-useable knowledge is beneficial to an organization. We can re-use, rather than re-create that knowledge. And we can expose that knowledge to everyone in our organization, and even to our customers, if we so desire. But that’s Knowledge Management 101. Lets get back to Linking.
In addition to linking cases to solutions, we can also link solutions to CRs (Change Requests). Not every case gets resolved immediately, so we may have a solution whose resolution is “this is a bug that doesn’t have a workaround”. We link the case to that solution. From the solution, we create a CR, and link those. Now the CR can be dispatched to the engineering queue to be worked, independent of the workflows of the case and the solution.
A case can be linked to one solution, a solution can be linked to many cases.
A solution can be linked to many CRs, a CR can be linked to many solutions.
With linking, we gain multiple benefits.
Most used knowledge / Most reported bugs
We learn which knowledge is being used most often. This allows us to the opportunity to closely address these particular solutions, and dive into why this knowledge is being used so often. Perhaps it’s a product defect – now we have real data saying that this is a common problem and should be resolved soon. Perhaps it’s a documentation issue – now we have real data saying that the current doc is inadequate and needs to be expanded. Perhaps it’s a platform specific issue – now we know that we need better testing or support for this platform.
When I worked in Technical Support at The MathWorks, my boss had the notion that he wanted to charge back to product development long-standing bugs that cost us money. Because we linked cases to solutions, he could say that we’ve had 100 support calls on this one issue in the last month. And at a cost of $40/call, that means that bug cost us $4000 last month. Hard to argue when you have that kind of data to back it up.
Closed-loop
Because we have everything linked together, we can now use business rules and notifications to close the loop.
When the CR is fixed, we can notify the owner of the Solution that the CR has been fixed and that they may wish to update the resolution accordingly.
In addition, we can notify the owners of all of the linked cases (remember that we may have many cases linked to that one solution). From the CR, we can get to the linked solutions, then to the linked cases. And because they’re linked, Rulemanager can traverse these relationships. The notification may tell the case owners that the CR has been fixed, and that they may wish to contact the customers.
We could also notify the customers themselves. When the CR is fixed, we can get to the customers by traversing form CR (bug) –> Solution –> Case –> Contact. So we could have the system notify the customers that the bug that they opened a case about has been fixed. Pretty cool.
Dynamic FAQ
One of the other neat things you can do is create a dynamic FAQ. Because we have the links, we can easily query for the most linked solutions. It could be the most linked of all time, or most linked in the last 30 days. Limit that query to the top 10, and now you have the top 10 most used solutions. And, of course, this list will change as new knowledge becomes available, and knowledge use changes. Post this list of solutions on your Support Portal web site, and now your customers have access to a list of actual frequently asked questions.
Not linked notifications
Another use of linking that I’ve seen used is the “not linked notification”. If a case is closed, and it does not have a solution linked, then a notification is sent out to the case owner – with a gentle reminder that ideally every case be linked to a solution – and perhaps there’s either an existing solution that can be linked to – or that perhaps that there was some knowledge gained from within the case that would be useful to other agents or customers – and a new solution could be created from this knowledge.
Your usage and ideas?
Do you link cases to solutions? Solutions to CRs? Would it make sense to? Have some other ways that you use this data or see other benefits? Leave a comment and share your ideas.
Big thanks to those that attended today’s webinar on Rulemanager and Advanced Business Rules
We had a good turnout, and some really good participation from attendees.
Slides
The slides from today’s presentation are available on Slideshare.
Links
Ideas for Future Webinars?
Have an idea for a future webinar? Something you’d like to see or learn more about? Leave a comment here or drop me an email: gary [at] dovetailsoftware [dot] com
Just a little reminder that I will be hosting a training webinar this Thursday.
Advanced Business Rules (Part 2)
- User-defined Business Rule Events
- Business rules based on custom object types
- New Event Creation Times and Calendars
- Custom Notification Methods
- Time Bombs
- Tips & Tricks
- Troubleshooting Tips
- etc.
When: Thursday, July 29, 2010 11:00 AM - 12:00 PM CDT
Register here: https://www1.gotomeeting.com/register/138608689
Kevin Miller did a recent sneak preview of Dovetail Seeker 2.0, which we’re hard at work on here.
Here’s an additional sneak preview of search capabilities from the Agent side of things.
Search attachments
Search case attachments, solution attachments, etc.
Search external documents
Search product documentation, whitepapers, technical bulletins, etc.
