Support and Workflow

Pandora ITSM allows you to control your ticket workflow by Workflow rules and Status mapping.

Menu Support → Workflow → Workflow rules.

In this section, you may define custom rules for automated ticket management. Due to the power of this feature, only administrator users (superadmin) will be able to create and edit these rules.

The tickets to be checked will be the open tickets, to check also the closed tickets, the token must be enabled in the menu Setup → Setup → Issue setup → Workflows → Check closed tickets when running workflow rules.

Menu Support → Workflow → Workflow rules → Create.

A description and an execution mode must be included:

• Cron: The Workflow rules will be checked at each cron execution (usually every 5 minutes).
• Real time: Workflow rule checking will be done at the same time that any ticket is created or edited.

When editing a workflow rule (by clicking on its description in the list of rules), you will also have access to the Conditions tab, which may be added by clicking Create, filling in the parameters in the ticket fields and saving with the corresponding button.

Within each condition there is an important field also called Condition, which will define how it will be applied to the rest of the filter fields:

• Match all fields.
• Match any field.
• No match.

Some details of the filter fields:

• Priority: A superior number does not encompass the inferior ones.
• Ticket type: When selecting an item that has custom fields, they will appear and may be used to add them to the condition filter set.

You may have one or several conditions per rule. The default relationship between each of the conditions of a rule is OR: if one of them is met, the rule will be activated and the programmed action or actions will be executed.

Relationships may be changed and each condition may be moved up or down in the Action column in the evaluation order.

The next step is to create the action(s) to be performed if the chosen conditions are met. Depending on the Action type, one or more fields and subfields to be set will appear below, for example, if you choose to send e-mail message you will see “To”, “Subject” and “Text”.

The actions to be performed on the ticket are:

1. Change priority.
2. Change owner.
3. Change group.
4. Change status.
5. Send e-mail.
6. Add Work Unit.
7. Change update date.
8. Change resolution.
9. Execute a command, either execute a command on the server or a custom script.
10. Block.
11. Unblock.
12. Change the type.

To configure the actions, macros may be used. These will be replaced by the value corresponding to that of the ticket.

• _access_url_: Direct URL to the ticket.
• _author_: Ticket creator.
• _creation_timestamp_: Date and time of ticket creation.
• _fullname_: Full name of the user receiving the email.
• _id_group_: Group ID assigned to the ticket.
• _id_priority_: ID of the ticket priority.
• _id_resolution_: ID of the resolution of the incident.
• _id_status_: Incident Status ID.
• _incident_auth_email_: E-mail of the user who created the ticket.
• _incident_closed_by_: User who closes the ticket.
• _incident_epilog_: Epilogue of the ticket.
• _incident_group_email_: E-mail of the assigned group.
• _incident_id_: Ticket ID.
• _incident_own_email_: E-mail of the owner user.
• _incident_title_: Ticket title.
• _name_group_: Name of the group assigned to the incident.
• _name_priority_: Name of the ticket priority.
• _name_resolution_: Name of the resolution of the incident.
• _name_status_: Incident state name.
• _owner_: Ticket owner.
• _sitename_: Name of the site, as defined in the setup.
• _type_tickets_: Ticket type.
• _update_timestamp_: Last time the ticket was updated.
• _username_: Identifying name of the user who receives the email (login name).
• Custom Field Templates: They allow you to use the custom fields of the ticket types. The name of the custom fields you added may also be included as a macro, which will show the value of that field, the format would be: _ckgedit_QUOTcustom_field_nameckgedit>.

A ticket has multiple fields. Perhaps the most important is the status field. This field refers to whether a ticket, problem or change is closed, pending a third party, new or newly created, whether it is assigned, whether it was reopened, whether it was verified or whether it was not confirmed. This cycle is open to the user and may be passed from one to another without restriction by default.

In case you need to define the flow, there is the option of State Mapping, in which you may define which states and resolutions will be available to the user.

There are certain circumstances that are automatically triggered when switching from one state to another. When switching from any state to the “closed” state, a text box called “epilogue”, which was not accessible before, is automatically activated to explain what the result of the intervention or change was or what the cause of the problem and its solution was in short.

A solved ticket is the basis for generating an article in the knowledge base that may be used in the future to solve an issue quickly and documented.

Back to Pandora ITSM Documentation Index