none
SCSM - Incident moving automatically to other queue after End-User comment RRS feed

  • Question

  • Hi all!

    I'm configuring the SCSM (System Center Service Manager).

    I have there 1 main queue, let say "MainQueue" and then child-queues "Queue1" and "Queue2".

    The "Queue1" is configured like this:
    It's opening incidents, when the user is from country "Austria".

    The "Queue2" is configured like this:
    It's opening incidents, when the user is from country "Romania".

    Everything is working fine. Then I'm sending from the Incident an email to the user with "Request User Input", which is also working. The user is answering to this email and the Incident is getting updated with the user-feedback, but then the incident is moving automatically from "Queue2" to "Queue1".

    I haven't configured this kind of flow, to move it automatically to "Queue1". I checked all settings, but it isn't configured.

    Any idea why SCSM is doing this?

    Thanks in advance!

    Best regards,

    Strahinja

    Friday, July 26, 2019 6:46 AM

Answers

  • Hi!

    I have now the following solution:
    First I had in the exchange connector always a default template for new tickets and also when an update arrived.
    That's why it got back always into the default queue, when a new ticket-update came from the user.

    Now I configured an empty template and assigned it to the exchange connector but only for the tickets where an update arrives. And this is working. Now the tickets are not going back into their default queues.

    Regards!

    Tuesday, August 6, 2019 11:44 AM

All replies

  • Are you using the SCSM Exchange Connector for processing incoming emails in SCSM?

    If so there is an Incident template configured in the Exchange Connector that is applied on incoming emails and Incident updates. Check this Incident template if there is a Support Group/Tier Queue configured.

    Hope this helps. 


    Andreas Baumgarten

    Friday, July 26, 2019 11:33 AM
    Moderator
  • Hi!

    Yes I have configured two templates and I'm using the exchange connector.

    1. Template
    When user is sending an email AND the user is from "Austria", then it should put the ticket into the "Austria" queue.

    2. Template
    When the user is sending an email AND the user is from "Romania", then it should put the ticket into the "Romania" queue.

    Both are working fine, that's not the problem.
    The issue is, that when I send an email from a ticket which is in the "Romania" queue and the user is answering back, then the ticket is moving automatically to the "Austria" queue. But for this task I haven't configured any rules/workflows.

    Also if I move a ticket from the "Austria" queue to the "Romania" queue, request again an update, user is sending a feedback.... then the ticket is moving automatically back to the "Austria" queue.

    BR,

    Strahinja

    Monday, July 29, 2019 6:42 AM
  • Hi again!

    OK, I found that on my exchange connector I configured that it should use always the template for "Austria" queue.

    But can you tell me, what would be the best setup for the following scenario:
    I'm using one mailbox now. An user from Romania is opening an incident and this get's automatically into the "Romania" queue. And let's say this ticket needs to go to the "Austria" queue. Now I'm requesting an update from the user and the user is answering. Normally I would like that the ticket stays still in the "Austria" queue, but due to the workflow and template it will go back to the "Romania" queue.

    Monday, July 29, 2019 10:25 AM
  • Per Exchange Connector you can only configure one template on update  by email.

    If you don't want to get the Support Group set by the template you have to remove the config of the Suppoert Group in the template.

    If you need more than one template applied on update the only option is to use different email adresses and different Exchange Connectors. 

     

    Andreas Baumgarten

    Monday, July 29, 2019 11:02 AM
    Moderator
  • Are there any logs, where I can see why it moved the tickets into another queue automatically?
    I know that I can check the "Workflows" -> "Status" but there it's only showing if it was successful or not.

    I have no two exchange connector which are connected to the same mailbox. One connector is using the "Romania" template, the other connector is using the "Austria" template.

     I have disabled the templates for the workflows I have configured before.

    But now when I open two incidents, one for Austria and one for Romania and I update them via email, now the incident is going automatically to the Romania queue. Is there any priority set somewhere? Where can I check this. The connectors have totally different templates.

    Monday, July 29, 2019 2:28 PM
  • Still the same issue.

    When I send an email to the support-email address, it's opening the ticket in the wrong queue.

    But the exchange connectors are configured correctly, also the workflows.

    One of them should open the ticket in "Austria" gehe, the other one in the "Romania" queue.
    But now when I send an email to the SCSM, it's opening always in the "Romania" queue.

    No idea what's happening.

    (See also the last entry from me regarding the logs)

    BR,

    Strahinja

    Tuesday, July 30, 2019 11:53 AM
  • Just to be clear:

    In an Exchange Connector you configured an Incident Template "on create an Incident" and a second, different Incident Template "on update an Incident"?

    Which Support Groups are configured in each template?

    You have one mailbox per Exchange Connector? 


    Andreas Baumgarten

    Wednesday, July 31, 2019 5:55 AM
    Moderator
  • Hi!

    I have now the following solution:
    First I had in the exchange connector always a default template for new tickets and also when an update arrived.
    That's why it got back always into the default queue, when a new ticket-update came from the user.

    Now I configured an empty template and assigned it to the exchange connector but only for the tickets where an update arrives. And this is working. Now the tickets are not going back into their default queues.

    Regards!

    Tuesday, August 6, 2019 11:44 AM