Service Desk Express ships with a comprehensive, if somewhat clunky, business rules manager that allows the system administrator(s) to view, create, update and delete business rules based on data changes in the Service Desk Express database. Whilst this tool is fit for purpose only system administrators and group administrators are able to use the tool due to permissions and furthermore, require training to do so. This is generally a good idea but there are occasions when you might want someone else in the business to be able to change a setting in a rule such that, for example, an email goes somewhere else.
In these scenarios the risk associated with making this change is minimal and allowing the business to make this change would appear sensible. That said, we don’t want to make everyone a system or group administrator. So what’s the solution.
System Parameters
What we need is a way of storing system parameters that can be used in business rules, calculated fields, emails etc. and we need our support staff to be able to modify those system parameters they own. We can do this by creating a new module in Service Desk Express using the DB Admin Tool.
Example:
Table Name – TBL_PARAMS; Display Name – System Parameters
| Property | Field 1 | Field 2 | Field 3 | Field 4 |
|---|---|---|---|---|
| Alias Name | Param Name | Param Value | Seq.Owner | Owner ID |
| Display Name | Param Name | Param Value | Seq.Owner | Owner ID |
| Column Name | PARAM_NAME | PARAM_VALUE | SEQ_OWNER | CODE |
| Status | Real | Real | Foreign Key (Support Staff) Restrict | Virtual (Support Staff) |
| Primary Key | No | No | No | No |
| Nullable | No | Yes | No | No |
| Index | Yes | No | Yes | No |
| Unique | Yes | No | No | No |
| Data Entry Type | Text | Text | Numeric | Text Upper Case |
| Database Type | nvarchar | nvarchar | int | nvarchar |
| Length | 255 | 255 | 4 | 30 |
| Default | <none> | <none> | <none> | <none> |
So let’s say that we want to create a business rule that sends an email to a bunch of people whenever an incident goes past its due date and time. The rule might look something like:
Incident – Due Date Exceeded
Conditions
when an Incident
Create
Update occurs with
| Expression 1 | Comparison Operator | Expression 2 | Logical Operator |
|---|---|---|---|
| {DB,Incident,State:,”Incident #” = {TR,Incident #}} | Equals | {TR,Incident #} | None |
Actions
Action 1
| Method | Module | Form |
|---|---|---|
| Create | Notifications | Notifications |
| Field Name | Value |
|---|---|
| Subject | Incident #{TR,Incident #} has exceeded its due date and time |
| Body | Incident #{TR,Incident #} has exceeded its due date and time. Please do something |
| Type | SMTP Email |
| Address | jbloggs@company.com;fflintstone@company.com |
The problem here is that when someone wants to add or remove someone from the mailing you have to get a group or system administrator to do so. What we need to do is modify the rule as follows:
Incident – Due Date Exceeded
Conditions
when an Incident
Create
Update occurs with
| Expression 1 | Comparison Operator | Expression 2 | Logical Operator |
|---|---|---|---|
| {DB,Incident,State:,”Incident #” = {TR,Incident #}} | Equals | {TR,Incident #} | None |
Actions
Action 1
| Method | Module | Form |
|---|---|---|
| Create | Notifications | Notifications |
| Field Name | Value |
|---|---|
| Subject | Incident #{TR,Incident #} has exceeded its due date and time |
| Body | Incident #{TR,Incident #} has exceeded its due date and time. Please do something |
| Type | SMTP Email |
| Address | {DB,System Parameters,Param Value,”Param Name” = ‘Incident Email Distribution List’} |
Additionally, we need to open our new System Parameters form and add a parameter called Incident Email Distribution List with a value of jbloggs@company.com;fflintstone@company.com as per the figure below:
The result of doing this is absolutely nothing! The rule does exactly what it used to. The difference here however, is that you don’t have to be a group or system administrator to update the parameter value. What I would then suggest is that you create a client side business rule that says:
System Parameters – Control Updates
Conditions
On Save in module System Parameters
| Expression 1 | Comparison Operator | Expression 2 | Logical Operator |
|---|---|---|---|
| {TR,Owner ID} | NotEqual | {MAGICUSER} | None |
Actions
Action 1
| Method | Module | Form |
|---|---|---|
| Display Message | System Parameters | <Current Form> |
| Field Name | Value |
|---|---|
| Message Box Type | OK |
| OK (True) Button Text | OK |
| Exit Rule if OK clicked | True |
| Window close button (x) should function as | Exit Rule |
| Message | You can’t update a record you don’t own. |
Now you have a situation where, as a system administrator, you can grant every support staff user select and update permissions to this module; insert permissions to, for example, EXTERNAL_SUPPORT (on the grounds that there is no point in inserting a system parameter without some use for it and only system/group administrators will be creation functionality based on these parameters), and delete permissions to no-one. Add a version of the form to their navigator bar that has the Parameter Name and Owner ID as display only and your good to go.
In the next post I will show another use for this system parameters table when it comes to calculated fields…
JOATIT 