If we could start from the creation of a new dispatch rule.
On the first tab we have Name, Class, Team attribute, Explain log attribute, and Disabled contexts.
I understand Name as any name we decide on. But please help me with Class.
In the description for Class it states “Ticket class the rule will apply to” The documentation example image shows the Class filled out as “Ticket”. So, in this example would the dispatch rule apply to all tickets? Could we use Incidents as the Class and the rule will only apply to Incident tickets?
Thank you,
Andrew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To answer my own question:
Based on errors I get while messing around with the extension.
Yes, setting the Class to “Ticket” will apply the rule to all tickets.
Setting the Class to “Incident tickets” will apply the rule to Incident tickets.
If I’m wrong, someone please jump in…
Moving on to the “Team attribute”.
The documentation states for the Team attribute: Attribute code of the Ticket Class that will be set by the matching Team rule.
Again, based on errors I get while messing around with the extension. I think this is an attribute of the ticket that is updated by the matching rule.
So, If we enter team_id here, the matching rule will update the ticket’s team_id with the team_id of the team found in the OQL of the “Team Rule” tab.
If I’m wrong, someone please jump in…
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I’m back trying to get dispatch rules to work.
Thank you Pierre for your confirmation that what I understand so far is correct. I don’t have any documentation suggestions yet. I still don’t understand some fields. Once I have a better understanding, I would be happy to help anyway I can…
To move on to the next step in the documentation. “Create at least one State rule”
In the documentation the field “State code” is described as: Code of the Ticket state. Entering this state will trigger the dispatch rule.
Here, are we referring to the ticket’s status? In the example, when the ticket’s status is “new” it will trigger the dispatch rule?
The other field is “Stimulus code”. Here, are we referring to what the status of the ticket will be changed to after the rule is triggered?
So, with the State code set to “new” and the Stimulus code set to “assigned”. When the ticket’s status is “new” the rule will be triggered and the status will be changed from new to assigned. Is this correct?
Thanks for any input.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, this is not correct, look at the image, the example provided shows that
State code = new this is an internal value of the status enum, representing a particular State, you got this one right
Stimulus code = ev_assign
This is a Stimulus code, not the destination State,
There could be more than one stimulus code to go to the same destination state.
The triplet (Source State code, Stimulus code, Destination State code) define a Transition.
A Transition can include a set of actions which are automatically executed during the transition. Some Transitions are not proposed in the UI, they are internal, triggered by some code
By naming convention, the user accessible Stimulus code are named ev_ followed by the destination state code, so here ev_assigned when it ends on assigned state.
Last edit: Vincent @ Combodo 2022-03-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Vincent for your help. Now we're getting somewhere…
By using the Stimulus code = ev_assign, and this query in the team rules:
SELECT Team AS t
JOIN lnkContactToService AS l1 ON l1.contact_id=t.id
JOIN Service AS s ON l1.service_id=s.id
WHERE s.id=:this->service_id
The auto dispatch is working. (I think)
Now, the auto dispatch is setting the ticket to assigned. Also, it sets the ticket’s contact to the team that is listed as the contact in the service that the ticket is opened for. It is not, assigning the team as the agent. The agent field is shown as undefined. If this is expected behavior and is all that it does, then it is working. YEA…
If this is all that it does, I have a couple follow-up questions.
1. Is there a way to auto assign an agent to a ticket?
2. Do most people create a Notification rule to notify the team that a ticket has been dispatched. Then someone from the team will assign the agent?
3. When we apply a dispatch rule, the assign button for all tickets disappears. That is, with a dispatch rule active, when modifying a ticket in the admin counsel there is no assign button. Is this expected? Can we change this?
Thanks,
Andrew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, what would be the rule, to select the agent within the team ? Would it be based on Service or service-subcategory? In general, either agents help themselves and take the most urgent one in their team queue when they are free, through a dashboard for eg. or a person is in charge of looking at that queue and dispatching to the agent the most appropriate because of its knowledge or availability... But this is all process, not tool !
In our organization, we do not send notification for each new ticket assigned to our team, we have a dashboard in iTop and we check it regularly. But it's an organizational choice
Yes it is expected and done on purpose, we don't want the user to assign the ticket under creation before auto-mated rules can act. Once the ticket is created, the assign button should be available again, if no automatic rules dispatched it.
No, this cannot be changed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Vincent,
Thanks for your response. It’s very helpful to us.
We have a small IT team (16 members). So many of us are fairly specialized. For example, if there is a telephone issue we have one tech that handles phone issues. Same with network, storage...etc. Having iTop auto assign tickets to agents based on service-subcategory would work great for us.
In our organization, our agents are moving throughout the city working at 25 different locations. Spending fifteen minutes here, two hours there. Getting them to log into iTop has been a challenge. So, we have a person dedicated to assigning tickets. With email notifications to the agent once assigned. By using the dispatch rules along with notifications, we can email an agent that a ticket needs to be assigned with in their teem. This should hopefully ease the workload on the person in charge of iTop tickets. You can see how useful it would be to have iTop auto assign a ticket based on service-subcategory.
Thanks for the clear explanation on this behavior.
Again Vincent, thank you.
Andrew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
As a newbie, I’m struggling to understand the online documentation: Assigning a team based on Service.
If we could start from the creation of a new dispatch rule.
On the first tab we have Name, Class, Team attribute, Explain log attribute, and Disabled contexts.
I understand Name as any name we decide on. But please help me with Class.
In the description for Class it states “Ticket class the rule will apply to” The documentation example image shows the Class filled out as “Ticket”. So, in this example would the dispatch rule apply to all tickets? Could we use Incidents as the Class and the rule will only apply to Incident tickets?
Thank you,
Andrew
To answer my own question:
Based on errors I get while messing around with the extension.
Yes, setting the Class to “Ticket” will apply the rule to all tickets.
Setting the Class to “Incident tickets” will apply the rule to Incident tickets.
If I’m wrong, someone please jump in…
Moving on to the “Team attribute”.
The documentation states for the Team attribute: Attribute code of the Ticket Class that will be set by the matching Team rule.
Again, based on errors I get while messing around with the extension. I think this is an attribute of the ticket that is updated by the matching rule.
So, If we enter team_id here, the matching rule will update the ticket’s team_id with the team_id of the team found in the OQL of the “Team Rule” tab.
If I’m wrong, someone please jump in…
Thanks
Hello,
Your conclusions seems ok to me !
Do you have any suggestion to improve the documentation ?
Hi all,
I’m back trying to get dispatch rules to work.
Thank you Pierre for your confirmation that what I understand so far is correct. I don’t have any documentation suggestions yet. I still don’t understand some fields. Once I have a better understanding, I would be happy to help anyway I can…
To move on to the next step in the documentation. “Create at least one State rule”
In the documentation the field “State code” is described as: Code of the Ticket state. Entering this state will trigger the dispatch rule.
Here, are we referring to the ticket’s status? In the example, when the ticket’s status is “new” it will trigger the dispatch rule?
The other field is “Stimulus code”. Here, are we referring to what the status of the ticket will be changed to after the rule is triggered?
So, with the State code set to “new” and the Stimulus code set to “assigned”. When the ticket’s status is “new” the rule will be triggered and the status will be changed from new to assigned. Is this correct?
Thanks for any input.
No, this is not correct, look at the image, the example provided shows that
This is a Stimulus code, not the destination State,
There could be more than one stimulus code to go to the same destination state.
The triplet (Source State code, Stimulus code, Destination State code) define a Transition.
A Transition can include a set of actions which are automatically executed during the transition. Some Transitions are not proposed in the UI, they are internal, triggered by some code
By naming convention, the user accessible Stimulus code are named ev_ followed by the destination state code, so here ev_assigned when it ends on assigned state.
Last edit: Vincent @ Combodo 2022-03-25
Thanks Vincent for your help. Now we're getting somewhere…
By using the Stimulus code = ev_assign, and this query in the team rules:
SELECT Team AS t
JOIN lnkContactToService AS l1 ON l1.contact_id=t.id
JOIN Service AS s ON l1.service_id=s.id
WHERE s.id=:this->service_id
The auto dispatch is working. (I think)
Now, the auto dispatch is setting the ticket to assigned. Also, it sets the ticket’s contact to the team that is listed as the contact in the service that the ticket is opened for. It is not, assigning the team as the agent. The agent field is shown as undefined. If this is expected behavior and is all that it does, then it is working. YEA…
If this is all that it does, I have a couple follow-up questions.
1. Is there a way to auto assign an agent to a ticket?
2. Do most people create a Notification rule to notify the team that a ticket has been dispatched. Then someone from the team will assign the agent?
3. When we apply a dispatch rule, the assign button for all tickets disappears. That is, with a dispatch rule active, when modifying a ticket in the admin counsel there is no assign button. Is this expected? Can we change this?
Thanks,
Andrew
No, what would be the rule, to select the agent within the team ? Would it be based on Service or service-subcategory? In general, either agents help themselves and take the most urgent one in their team queue when they are free, through a dashboard for eg. or a person is in charge of looking at that queue and dispatching to the agent the most appropriate because of its knowledge or availability... But this is all process, not tool !
In our organization, we do not send notification for each new ticket assigned to our team, we have a dashboard in iTop and we check it regularly. But it's an organizational choice
Yes it is expected and done on purpose, we don't want the user to assign the ticket under creation before auto-mated rules can act. Once the ticket is created, the assign button should be available again, if no automatic rules dispatched it.
No, this cannot be changed.
Hi Vincent,
Thanks for your response. It’s very helpful to us.
We have a small IT team (16 members). So many of us are fairly specialized. For example, if there is a telephone issue we have one tech that handles phone issues. Same with network, storage...etc. Having iTop auto assign tickets to agents based on service-subcategory would work great for us.
In our organization, our agents are moving throughout the city working at 25 different locations. Spending fifteen minutes here, two hours there. Getting them to log into iTop has been a challenge. So, we have a person dedicated to assigning tickets. With email notifications to the agent once assigned. By using the dispatch rules along with notifications, we can email an agent that a ticket needs to be assigned with in their teem. This should hopefully ease the workload on the person in charge of iTop tickets. You can see how useful it would be to have iTop auto assign a ticket based on service-subcategory.
Thanks for the clear explanation on this behavior.
Again Vincent, thank you.
Andrew