Support and Workflow

Last update: June 2025. Version: 106 OUM

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

Workflow Rules

Support → Workflow → Workflow rules menu.

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 activated in the menu Setup → Setup → Issue setup → Workflows → Check closed tickets when running workflow rules.

From version 106, Pandora ITSM brings integrated workflow rules (and actions) which are disabled by default. The most common situations for projects are included and may be reused (modify and activate) or create completely new workflows.

Creation of 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.

Conditions

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.

Actions

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.

Macros

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

Macro Description
_access_url_ Direct URL to the ticket.
_author_ Ticket creator.
_companymanager_ It can be used in the action of sending an e-mail message to the administrator of the company to which the ticket belongs and in the action of changing the owner of the ticket to the company administrator.
_creation_timestamp_ Ticket creation date and time.
_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_ Ticket epilogue.
_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 incident resolution.
_name_status_ Incident state name.
_owner_ Ticket owner.
_sitename_ Site name, 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: _custom_field_name_.

Status Mapping

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