Creating and associating issues

You can create issues and associate communication with issues manually using the Issue tabs in the specific communication editors. However, this way of using issues is only suitable for a small number of requests and requires a lot of attention and clicking on the part of agents. For greater convenience, you can let FrontStage create issues automatically and/or search for existing issues for each communication.

Manual and automatic creation

See also

Steps for creating issues manually by agents are described in Creating an issue without any prior communication and Creating or associating an issue from another communication.

Issue selection conditions and issue blocking conditions determine whether issues are created automatically, just manually, or whether both options are possible:

  1. If there is only a blocking condition OR there is no selection or blocking condition, then issues are not created automatically, and they cannot be created manually either.

  2. If both a blocking and a selection condition exist, then issues are not created automatically, but they can be created manually.

  3. If there is only a selection condition, then issues are created automatically.

Automatic deletion

If you create and then remove a new issue from another communication, it will remain unassociated with anything. Over time, the number of issues abandoned in this way would increase enormously. Therefore, unassociated and newly created issues (having an activity New) are automatically deleted.

Issue conditions

In administration and in this text, we talk about issue selection conditions and issue blocking conditions.

This distinction is a bit misleading though. In fact, there is only one type of conditions - issue conditions. Differentiating between issue selection and issue blocking conditions is just a way and a tool for the administration environment to differentiate the rules.

The blocking condition differs from the selection condition only in that the administration turns on Block case creation for us in the condition. Both condition types are also in a single IssueCondition table in the database.

Issue selection conditions

A table for selecting a group of issue topics, default form scenario, and pre-selected topic for the communication that creates an issue.

You can manage issue selection rules in the administration in the Issue conditions section.

Issue blocking conditions

You can manage issue blocking conditions in the administration in the same section; there are the same fields as in issue selection conditions.

Looking up issues

For each communication, you can let FrontStage assess whether it is a new piece of communication or a follow-up to an earlier one (e.g. by message subject, etc.). If, for example, another customer asks about the same matter in another e-mail message, it would be appropriate for all interactions to be combined into the same issue. When the communication seems to follow a previous one, FrontStage will try to find an existing issue and associate it with the communication instead of creating a new issue.

Settings

You set up automatic issue detection using configuration parameters whose title starts with “IssueLookupBlock”:

  • IssueLookupBlockInbound – Indicates that issues are not to be looked up for inbound calls and that a new issue should always be created.

  • IssueLookupBlockMessage – Indicates that issues should not be looked up for messages and that a new issue should always be created.

  • IssueLookupBlockNoNumber – Indicates that issues should not be looked up for inbound calls that have no caller number and that a new issue should be created.

  • IssueLookupBlockOutbound – Indicates that issues should not be looked up for outbound calls and that a new issue should always be created.

  • IssueLookupBlockPhoneBookId – An ID of the telephone directory that groups telephone numbers and e-mail addresses for which issues are not to be looked up.

Another group of configuration parameters starting with “IssueLookupRestrictProject” determines whether the issue looked up must have the same project as the communication:

Procedure for looking up an issue for a call

If the issue look-up functionality is enabled for calls, FrontStage attempts to look up an issue as follows and in the following order:

  1. Is the contact filled in for the call? If yes, FrontStage will try to find all open issues with this contact or, if relevant, project. If there is just one matching issue, then it will be associated.

  2. Is the phone number (PN) filled in for the call? If yes, FrontStage will try to find all open issues with this contact or, if relevant, project. If there is just one issue matching, then it will be associated.

  3. FrontStage will try to find open issues with the same project for which there are other inbound or outbound calls with the same number. If there is just one matching issue, then it will be associated.

  4. If IssueLookupRestrictProjectOnCall is set to false, then FrontStage will try to find all open issues for which there are other inbound or outbound calls with the same number. If there is just one matching issue, then it will be associated.

  5. Search completed; no issue could be found.

Procedure for looking up an issue for a message

If the issue look-up functionality is enabled for messages, FrontStage attempts to look up an issue as follows and in the following order:

  1. Is the contact filled in for the message? If yes, FrontStage will try to find all open issues with this contact or, if relevant, project. If there is just one matching issue, then it will be associated.

  2. Is the phone number (PN) filled in for the message? If yes, FrontStage will try to find all open issues with this contact or, if relevant, project. If there is just one issue matching, then it will be associated.

  3. FrontStage will try to find open issues with the same project for which there are other messages with the same counterparty and of the same type (e-mail / SMS, …). If there is just one matching issue, then it will be associated.

  4. FrontStage will try to find open issues for which there are other messages with the same counterparty, of the same type and sent by the same gateway or, if relevant, under the same project. If there is just one matching issue, then it will be associated.

  5. If IssueLookupRestrictProjectOnMessage is set to false, then FronstStage will try to find all open issues for which there are other messages of the same type and with the same counterparty. If there is just one matching issue, then it will be associated.

  6. Search completed; no issue could be found.