Laurie,

Yes... there are two options:

Option 1. The workflow for an inserted ticket would need to be modified to account for "unassigned" tickets. Currently users are notified after they have been assigned, but an easy change could account for unassigned tickets. A workflow developer would need to make this change and then install it.

Option 2. Centric CRM ships with a Scheduled Event that compiles a list of unassigned tickets and emails them to a manager. You can visually see this workflow under the "Admin" tab, "Configure Modules" section, "Help Desk" module, then "Scheduled Actions" link.

By default this scheduled event is disabled because it needs configuration.

To configure, the following must be determined:

- Who should receive the ticket report? a specific email address, a specific user, or a whole department?

- How soon should the manager(s) be notified? by default 10 minutes

Once that has been decided the workflow can be updated and scheduled at the database level.

Either way, a web-based editor does not currently exist to make this change so an administrator or developer would need to be involved.

This is one area in which we plan to automate in a future release.

I believe I could do this myself with a little more information. Where can I find the files that need editing and then how would I "turn it on".

Are you using the binary or source code version?

If using the source code version, then the easiest is to modify the workflow.xml file that ships in the pref/cfs/system directory with the following steps:

1. Find <process name="dhv.report.ticketList.overdue">, <component id="2">

2. Next uncomment <parameter name="notification.to"> and fill in the email address(es) you want to notify (use a comma if more than one). Set enabled="true", then comment out any of the others that get notified.

3. Next, execute "ant install.deleteprefs" to remove the old workflow, then "ant install.copyprefs" to install the new workflow.

4. Refresh the workflow cache -- either restart Tomcat instance or browse to http://127.0.0.1/centric_crm/ProcessSystem.do?command=ReloadSystemPrefs from localhost only

5. To activate the task an event needs to be added to the [business_process_events] table. The following record is used to check for unassigned tickets every 5 minutes, between the hours of 8am and 6pm. The only difficult field is the [process_id] which must map to the newly inserted business process. The cron/workflow will pick up this new entry without a restart.

-[ RECORD 1 ]+------------------------------
event_id | 1
second | 0
minute | */5
hour | 8-18
dayofmonth | *
month | *
dayofweek | *
year | *
task | dhv.report.ticketList.overdue
extrainfo |
businessdays | true
enabled | t
entered | 2003-08-11 09:30:35.779
process_id | 2

• It appears that in the current download, 2 important files are missing which prevents the ant script from deleting or installing the workflow. I will upload these separately in the 3.0 forum and these will be included in the next updates/versions.

I am using the binary version.

I'm guessing that in order to "turn it on" you need the ANT Java compiler thing?

How do we do this in the binary version?

Yes, the binary version does not have a web-based tool to install or modify workflows so these are currently done using command-line tools from the source version.

We've been looking at several GUI implementations to accomplish this task, but haven't found one we agree on. My hope is that we provide a simple-to-use browser based workflow editor, to keep things in the spirit of Centric CRM.

The source tools simply delete the existing workflows then reload them with the updated workflow.xml file, so the following should work. While I have not tested this, the changes to enable the ticket notification can be performed manually at the database level by:

1. inserting the business process event in the [business_process_events] table
2. updating the [business_process_component_parameter] records to specify who should receive the emails, for the corresponding ticket business_process
3. enabling the ticket workflow in the [business_process] table
4. reloading the application prefs
5. verifying the workflow in the Admin and create a ticket to verify

Matt,
Thanks for the tips. I am now....stuck. I shall explain:

1. The business process event was actually already in the binary version turned on. Although not configured at all, so it didn't do anything.

2. The table [business_process_component_parameter] I'm not sure which one to change to a static email address.

- The workflow.xml file contains some commented out code for the mail server and who it was from.

3. enabling the process was easy to do as it was already there and enabled in the [business_process] table

4. I see my changes in the workflow, I created a test ticket and let it sit there...no email was generated to let me know it was unassigned.

So...I'm stuck...I'm not sure which setting to change or add to the [business_process_component_parameter] table.

It seems so simple...and I think I'm almost there...I just get the feeling I'm missing something really minor.

Thanks,
Christopher

Matt Rajkowski wrote:
Yes, the binary version does not have a web-based tool to install or modify workflows so these are currently done using command-line tools from the source version.

We've been looking at several GUI implementations to accomplish this task, but haven't found one we agree on. My hope is that we provide a simple-to-use browser based workflow editor, to keep things in the spirit of Centric CRM.

The source tools simply delete the existing workflows then reload them with the updated workflow.xml file, so the following should work. While I have not tested this, the changes to enable the ticket notification can be performed manually at the database level by:

1. inserting the business process event in the [business_process_events] table
2. updating the [business_process_component_parameter] records to specify who should receive the emails, for the corresponding ticket business_process
3. enabling the ticket workflow in the [business_process] table
4. reloading the application prefs
5. verifying the workflow in the Admin and create a ticket to verify

Ahhh I re-read your earlier post about the "notification.to" parameter...that is not in any of the business process tables.

And I'm still stuck.

Can I download the source and then use ANT to slip-stream the new workflow into a binary release using the method described earlier?

Thanks,