Some Parameters Regarding the Approval Module
There are several parameters related to the ticket approval module. They are:
Parameter: Use the ticket approval module
Definition: Parameter that indicates whether ticket approval will be activated in your Movidesk account. If unchecked, no options related to the module will be available in your system.
Location: Account settings. Tab Additional Modules, group Ticket Approval.
Parameter: Allow role registration
Definition: Parameter that indicates whether the agent can register the roles that will be informed in the registration of people and later in the creation of approval processes.
Location: Agent access profile. Tab Settings, group People.
Parameter: Allow registration of approval rules
Definition: Parameter that indicates whether the agent can register the approval processes that will be applied to the tickets.
Location: Agent access profile. Tab Settings, group Ticket Approval.
Roles
One of the possibilities established by the approval rules is the ability to define that someone with a specific role, such as a manager, must approve the ticket. Therefore, at the time of ticket creation, the system goes through the hierarchy of that client until it finds someone who holds the role specified in the process. Therefore, that person will need to approve the ticket.
Note that in defining roles, this structure will be key to the approval process. So, you may not want to reflect the structure of your company's organizational hierarchy in the roles. For example, when creating an approval process where a Manager must approve the request, it may not be advisable to indicate in the registration of people that the collaborator is a Marketing Manager or HR Manager. Otherwise, you would be required to create one process for each requesting department. If you indicate in the registration that the person is simply a Manager, you can create a single process that requires approval from the Manager. This way, it doesn't matter if the request comes from the Marketing or HR department, the Manager hierarchically above the requester will need to approve the ticket.
Registering Roles
In the Main tab of the system, access the Settings option. In the left menu, locate the People group and then the Roles option. The role registration follows the standard already used in the other registration screens of the system.
Informing the person's role
In the registration of people, whether they are agents or clients, you can indicate the role that person holds in the organization.
Hierarchical Superiors
Another important point in the approval process is the hierarchy of the people involved. In other words, who reports to whom.
Approval and SLA
While a ticket is waiting for approval from the respective approvers, you can choose not to set a due date. This means the SLA for resolution and response can be paused until the approval occurs. Once the approval event happens, the SLA is calculated, discounting the time the ticket was paused.
To configure the system to operate in this way, you will need to change a parameter in your SLA rules. Otherwise, the due date will be calculated regardless of whether the ticket is awaiting approval.
In the SLA Contract registration, access each of the rules and locate the Pause block. In this block, find the parameter Pause the SLA while the ticket is awaiting approval. If this is checked, the SLA will not be calculated until the ticket approval occurs.
Approval Rules
Approval rules are the approval processes themselves. In these, you define under what conditions the ticket will need approval and also specify who the approvers will be. For each different rule, you can have different conditions and different approvers.
How to Manage Your Approval Rules
In the Main tab of the system, access the Settings option. In the left menu, locate the Approval group and then the Approval Rules option.
Through this screen, you can edit your approval rules registry, modifying existing rules or even creating new ones.
Registering the Rules
The approval rule is composed of a set of information. They are:
Main
Name of the rule and indication of whether it is enabled or not.
Conditions
Definition of the conditions under which the rule will be applied to the ticket. In this block, you can specify the criteria for applying the rule. It can be a service, an urgency, a category, or another criterion established by your company to determine when the ticket should undergo approval.
If you do not specify anything in this block, all tickets that are opened will fall under the rule.
When a ticket is opened and it falls under more than one approval process, it will be subject to all applicable processes, requiring approval from all of them before the ticket can be released.
Parameters
In this block, you must provide some parameters that will define how your rule will function:
Require comment when approving: If this parameter is checked, the system will require the ticket approver to enter a comment regarding their approval, even when authorizing the process to proceed. This is typically left unchecked.
Require comment when rejecting: If this parameter is checked, the system will require the ticket approver to enter a comment explaining why they are rejecting the ticket. In this case, they will need to justify why they are disapproving the execution of the ticket.
Type of Approval:
Sequential: In this approval model, when a ticket needs to be approved by more than one approver, it is sent to one approver at a time, moving to the next approver only after the previous one has approved it. If the previous approver rejects the ticket, it is immediately canceled and not sent to the next approver.
Simultaneous: In this approval model, the ticket is sent to all approvers in the process simultaneously. The criteria for determining whether the ticket is considered approved or rejected also depend on some parameters, which are:
All approvers must approve: In this model, all approvers in the process must agree to proceed. If one of the approvers rejects it, the ticket is immediately canceled, even if other approvers have already agreed. With this setting, it doesn't matter how many approvers the rule has—if one of them says no, the process is canceled. The ticket will only be considered approved when all approvers in the process have given their positive approval.
Consider the first approver's decision to approve or reject the ticket: Using this model, the ticket will be approved or rejected based on the first approver's decision. Once the first approver has approved or rejected it, the ticket is immediately approved or rejected according to that decision. The opinions of the other approvers will no longer be required.
Consider the majority decision of the approvers: With this parameter checked, the system will wait for the opinions of all approvers in the process. Once all have provided their feedback, the majority decision will prevail. If the majority approve, the ticket will be approved; if the majority reject, the ticket will be canceled.
Wildcard Approvers
Wildcard approvers are individuals who are not part of the approval process, will not be notified when the ticket is awaiting approval, but can approve or reject a ticket at any time while it is pending approval. The opinion of a wildcard approver overrides the opinions of other approvers, and the ticket is immediately approved or rejected (depending on the approver's decision) once a wildcard approver provides their approval. Generally, wildcard approvers are those who have the power to veto or approve a process without it needing to go through the established approval flow of the organization.
Approvers
In this part of the rule definition, you can specify which users will need to approve the ticket to authorize its execution.
Remember that the approval rule can require approval from more than one person, depending on your organization's definition for each process.
The approvers can be defined in three ways:
Specific Role: If you define that approval will depend on a specific role, you will need to specify which role must approve the ticket. In this case, when the ticket is opened, the system selects the ticket’s client and ascends the hierarchy until it finds someone with the specified role. For example, if the rule requires approval from a director and the ticket's client is an employee, the system selects that employee's superior, assuming the superior is a manager, and then selects that manager's superior. Upon verifying that this person is a director, the system designates them as the ticket approver.
Note that the system may ascend several levels to find someone with the specified role. If the system does not find anyone in the client's hierarchy with the specified role, approval will not be required.
Hierarchical Level: The definition of the hierarchical level ascends the requester's hierarchy by the specified number of levels to determine the ticket's approver. Typically, a quantity of 1 is used to indicate that the immediate superior of the client must approve the ticket.
Specific Approver: The specific approver option designates a specific person to be the approver of the process. This is usually someone responsible for the affected project or the owner of the involved area.
Triggers
The triggers feature has some conditions and dynamic variables (placeholders) important for the ticket approval module. In fact, your account was initialized with a trigger to invite your approvers to approve the ticket when it is pending their approval. This trigger is disabled, so consider enabling it if you are going to use the ticket approval module.
In addition to using the trigger to invite your approvers, you can create specific triggers to notify responsible parties when a ticket is available for execution, for example.
When creating your triggers, check the conditions under the options Ticket: is… and Ticket: is in…. These conditions provide specific criteria for the different stages of ticket approval.
In the dynamic variables, which can be used in the description of emails, you can use the option {ticket.approval.box}, which is the block for the approver to approve or reject a ticket, where it will open the Movidesk screen to continue with the approval. If the approver is a client, there will be no need to log in with a username and password (if the parameter allowing clients to access the ticket via links sent by email is enabled). However, if the approver is an agent, they will need to authenticate with a username and password.
Approval Applied to Tickets
After completing all the registration and configuration of the ticket approval module, the system will be ready to designate approvers when necessary.
When Opening Tickets
When the ticket is being opened and during the opening process, if it is identified that approval is required for any established configuration, the system will display an orange block on the opening screen to inform that the classification being made will require approval.
During the entire opening process, the ticket will remain unlocked, but when it is saved, all fields will be locked until the approval is granted.
In the Ticket Listing
In the ticket listing, the columns Pending Approval and Pending My Approval will be available for view creation. While the first shows a green checkmark to indicate that the ticket is awaiting approval, the second shows the same green checkmark, but only when the ticket is awaiting approval from the logged-in agent.
Additionally, you can create filters based on tickets that are awaiting approval.
It is also possible to use approval criteria as conditions for creating ticket views.
When Editing Tickets
Whenever a ticket is awaiting approval, the system will keep all fields locked, displaying only an orange message to indicate that the ticket is awaiting approval.
If the user reviewing the ticket is one of the approvers in the process, they will see a block requesting ticket approval.
For tickets that are exempt from approval, whenever a field in the ticket is changed, such as client, service, category, or urgency, the system will check whether the new classification requires the ticket to be submitted for approval. If necessary, the system will display a message warning that the new classification will require approval and ask if the user wants to continue.
If the user cancels, the change is undone, and the ticket does not go to approval. If the user confirms, the change is consolidated, the ticket is locked, and it is sent for approval.
Another option related to approval available when editing tickets is the detailed view of approval data. This detail is located in the ticket’s Options menu.
When you click on the Approval Details option, a screen is displayed with various information about the approval process to which the ticket is subjected.
It will show a history of all the process approvers, each of their responses, and the comments that were entered at the time of approval or rejection.