Intelligent housing repair software made simple.

Sometimes the simplest way to carry out ‘best practice’ is to avoid the common pitfalls. In this blog we will look at three common mistakes made while administering Keyfax. Two involving SQL best practice and another that relates to general script writing. Hopefully by highlighting these it will improve your experience while using and editing Keyfax.

Hard-headed Hard-coding

It is bad practice to hard code the name of the SQL database you are querying into your SQL query. If the database name should change (eg. A test database is used in UAT or a different database is used after a HMS system upgrade.) this would mean having to re-write all your queries where this method has been used.

This example shows an SQL databox where the SQL database being referenced is hard coded in the expression itself multiple times.

This can be avoided by using the Database dropdown menu. Keyfax enables Omfax technical staff to setup connection strings for you with the login details for any databases you require. Then you can simply pick the relevant database you want to query from the drop down.

This means that any changes to the database name in the future only need to be changed once in the Keyfax configuration file to update all affected SQL databoxes.

Attaching expressions to SQL databoxes

Using expressions against an SQL databox to evaluate the data it returns can, at high traffic sites, affect the performance of Keyfax. The reason for this is that every time the SQL databox is referenced in the scripts the query will be re-run. Where there are hundreds of Customer Service staff using Keyfax simultaneously, it makes sense to eliminate this unnecessary SQL overhead.

In this example, expressions have been written directly against the SQL databox, resulting in the SQL query being run twice.

To avoid the overhead of constant re-running of SQL requests, best practice is that you write the results of any SQL query into a Keyfax Script databox. Then attach any expressions you wish to use to that. This means that the SQL query will run only once. When the data returned is written into a Script databox it can be evaluated as often as you like without affecting performance.

Here the SQL query is run once, and the result is written into Script.Details04 which can then be evaluated as many times as required.

Testing, Testing…

The third best practice is an ‘old chestnut’. Remember that when you add categories and topics to a script set, they will by default be set to test. This means that they will appear in the test container in Admin Tools but will not appear to the staff who are using Keyfax launched from your housing management system. If you’ve added a new category and/or topic to a script set and the staff can’t see it, even though it appears to you in Admin Tools, then it is likely that this is the reason.

You can see any categories or topics that are in Test by looking for the yellow triangles with exclamation marks in the tree structure on the left. In the image below the Fence and Furniture categories and the Bed, Chair and Desk topics are set to test.

This is very useful if you are not ready for staff to use your script yet. It can also be a good tool to use if you wish to edit an existing topic and want to take it offline while you’re working on it. But remember when you are ready for it to be used, you need to take it out of test.

To do so select the category or topic you want to change and click on the properties button.

Then click on edit, change the properties of the item to either Selectable (visible) or ..Continuation (not visible) and save your changes.

To Sum Up

Most Keyfax Diagnostic scripts can be made more efficient, if you have the time to review them. If you haven’t done that in a while, or you’d like some help, ask your Omfax Account Manager to take a look for you, or contact us. All Keyfax customers are entitled to an annual review, and you can ask for this to be a focus.