Parallel Approvals is a feature introduced to enhance the approval process by sending approval requests concurrently to multiple groups. Each group operates independently with specific approval rules applied to them, allowing for greater flexibility and efficiency in handling approvals.
TABLE OF CONTENTS
- Q1: What are the key benefits of Parallel Approvals?
- Q2: Why do customers need Parallel Approvals?
- Q3: What is changing in the approval process?
- Q4: How will this impact existing customers?
- Q5: What are the required actions for customers?
- Q6: How will this change affect customers who use the "majority" rule for approvals?
- Q7: How does the change in approvals affect customers having approvals configured in multiple workflows?
- Q8: What will happen to existing approvals during the transition?
- Q9: How will customers be supported during this transition?
- Q10: What are the timelines for adopting Parallel Approvals?
- Q11: What is the transition period for customers?
Q1: What are the key benefits of Parallel Approvals?
Efficiency in Approval Lifecycle: Parallel Approvals enables faster decision-making by processing approval requests concurrently, thereby reducing delays in workflows.
Granular Control & Flexibility: Each approval group can have its own specific rule, providing more control over the approval process.
Reduced Conflicts: Parallel Approvals minimizes the risk of conflicting approval rules from different groups, ensuring smoother workflows.
Improved Process Control: Distinct approval requirements for each group ensure better risk management and thorough reviews.
Q2: Why do customers need Parallel Approvals?
Parallel Approvals are especially valuable for customers handling complex workflows where multiple departments/teams need to approve requests simultaneously. And each of them have their own approval rule. It eliminates inefficiencies and confusion that can arise with the current merged approval behavior. By allowing different groups to operate independently, it enhances productivity and ensures streamlined processes.
The current behaviour -
Multiple approvers get combined into one single set.
The approval rule for the entire set is the most recent of all those approval rules (override).
Example - If I add 2 approvers with a rule as Everyone to approve and the next two approvers with Anyone to approve - The system will merge all the 4 into one set and ask Anyone to approve.
Q3: What is changing in the approval process?
Deprecation of Merged Approvals: Previously, when multiple approval requests were triggered, they were merged into one group, and the most recent approval rule would override previous ones, limiting flexibility.
Parallel Approvals:
Approval requests to different cohorts of users will now be sent independently and approval groups will be created with respect to each cohort, and each group will have its own rule.
An approval chain - aggregation of all approval groups is also introduced.
The approval status of the chain corresponds to the approval status of the Ticket or Change
Workflow Configuration Changes:
Individual approval actions (groups) will now be grouped under a new action called "Request for Approval".
A new option under the action node (while leveraging "Request for Approval" ) will define the rule for the approval chain to ensure more flexibility.
Another option for the Admin to configure when the workflow should move ahead - depending on approval groups created by that node alone OR also consider groups created manually or by other workflows (execute workflow when)
Example of how things will change -
Two distinct approval groups get created - with their dedicated approval rules
The first group will require both the approvers to approve
The second group will require only one to approve
And a “chain” of command comes into the picture -
This is to aggregate across the approval groups - This chain rule can again be set to All Groups approve, First, Any, Majority etc
This can be set via the workflow itself or manually (needs relevant permissions for the Agent)
API Changes: The API now includes a new optional parameter (approval_group_id) to specify the approval group to which approvers should be added. If this parameter is not provided, approvers are added to a default API-specific approval group.
Use the API endpoint /api/v2/tickets/[ticket_id]/approval-chain-rule to update the approval chain rule for a service request. This allows you to configure the approval groups and their respective rules, ensuring the proper workflow for ticket approvals.
Below are the APIs we support for Service Requests:
Approval Groups for Service Requests: https://api.freshservice.com/#service_request_approval_groups
Create Approval Groups for a Service Request: https://api.freshservice.com/#create_approval_groups
Update Approval Groups of the Service Request: https://api.freshservice.com/#update_approval_groups
Update approval chain rule for a Service Request: https://api.freshservice.com/#update_service_request_approval_chain_rule
List all Ticket Approval Groups: https://api.freshservice.com/#list_all_ticket_approval_groups
Cancel Approval Groups in a Service Request: https://api.freshservice.com/#cancel_approval_groups
Use the API endpoint /api/v2/changes/[change_id]/approval-chain-rule to update the approval chain rule for a change request. This allows you to configure the approval groups and their respective rules, ensuring the proper workflow for ticket approvals.
Below are the APIs we support for Change Requests:
Approval Groups for Changes: https://api.freshservice.com/#change_approval_groups
Create Approval Groups for a Change Request: https://api.freshservice.com/#create_change_approval_groups
Update a Change Approval Group: https://api.freshservice.com/#update_change_approval_groups
Update approval chain rule for a change: https://api.freshservice.com/#update_approval_chain_rule_change
Cancel a Change Approval Group: https://api.freshservice.com/#cancel_change_approval_groups
List all Approval Groups within a Change: https://api.freshservice.com/#list_all_change_approval_groups
View a Change Approval: https://api.freshservice.com/#view_a_change_approval
List all Change Approvals: https://api.freshservice.com/#list_all_change_approvals
Q4: How will this impact existing customers?
New Approval Behavior: All new approval requests will follow the parallel approvals model, meaning approval requests will no longer merge by default.
Configuration Updates: Customers will need to update their workflows to reflect the new behavior and configure the appropriate approval rules for each group, wherever applicable
Example -A new employee needs access to a Macbook and Microsoft Office.
Say Macbook is under the Hardware department and MS Office comes under software.
Approvals are needed from BOTH the software & hardware teams.
Say a workflow sends approval emails software team for MS Office - the rule is “Everyone”
For Macbook - the hardware team members are added manually inside the ticket/change with the rule as “Anyone”
The system now merges all 4 approvers together and expects ONLY ONE person to approve - for the overall approval status to change.
The two different departments that process two independent items are combined and the rule is also wrong - just one person is expected to approve, but ideally it should have required three persons to approve.Does this change with the new approvals? Yes it does.
In the new world, you can create these as two separate approval groups - One group for software (via workflow) and one for hardware (manual)
Both these groups have their own approval rule and do not get combined.
Meaning three people need to approve the request - (as opposed to only person doing it in the current approval process)
If the existing process of only one person approving needs to be retained -
Set the approval rule for the hardware (manually added approval group to “Anyone” or “First Responder”
Set the approval chain rule as “Any Group” or “First Responding Group”
The rule for the approval chain can be set as All groups need to approve (default) - meaning that for the ticket to be closed it would still need both groups to approve.
But both groups can do it at the same time in parallel.
API Changes: Approvals raised via APIs will no longer automatically merge with an existing approval group. Instead, an approval_group_id must be specified to update each request.
Q5: What are the required actions for customers?
Workflow Updates: Customers need to update workflows to accommodate the parallel approvals structure, ensuring that each approval group has the correct approval rule.
In the previous example, customers might need to define the rule for the approval group or the chain accordingly - in order to retain their current processes.
But that would still mean that the process is not ideal - one person approving would move the service request for two items (MS Office and macbook) to the next stage.
Should they choose to adopt the new approvals process and also make things ideal - meaning that the required approvers for a particular item alone need to decide for the workflow to move forward. This can be achieved.
In the previous example -
Approval for the software item (MS Office 2013) was configured via a workflow - meaning 2 approvers would have been added by the System.
The remaining 2 approvers for the hardware item (macbook) were added manually.
But the workflow will still wait for all 4 approvers to approve/reject - only then it will move forward.
This means that I cannot make the workflow move forward independently
Meaning that even though the workflow has approvers only for the software item - it still needs to wait for the other two approvers (Added manually) to also approve.
Does this change with the new approvals? Yes it can be changed.
In the new world, we can decide when the workflow should move forward -
If the 2 approvers who are added via workflow alone need to approve/reject - the option “Execute workflow when” can be set to “All groups approve”
This means that the Groups defined INSIDE the workflow alone are sufficient for the decision - for the workflow to move forward.
Approvers added manually will not be considered.
If the 2 approvers added manually also need to be considered - then the option “Ticket Approval status is approved” needs to be set.
This would mean that the workflow will move forward only when all approvers (added via workflow and added manually) approve.
Note: this is the default option set when we migrate from the old to the new approvals.
API Updates: If using the API to raise approval requests, customers need to ensure that the new approval_group_id and /api/v2/tickets/[ticket_id]/approval-chain-rule parameter are used, and approvers are added to the correct approval group with appropriate approval rules for the group and chain
Q6: How will this change affect customers who use the "majority" rule for approvals?
Impact: For customers who have set the "majority" rule in their approval workflow, this behavior will be impacted as parallel approvals do not merge multiple approval requests. Each group will have its own rule, and the number of approvers may vary.
These customers will have to make configuration changes accordingly - to both the approval group’s rule and the chain rule.
Q7: How does the change in approvals affect customers having approvals configured in multiple workflows?
Scenario 1 -
Say there is an approval configured in an action node in a workflow
There IS NO node after that action node.
Current Behaviour -
In this case, subsequent workflows will execute and fire approvals.
But approval requests from multiple workflows will be merged, and the most recent approval rule would apply.
New Behaviour
Scenario 2 -
Say there is an approval configured in an action node in a workflow
There IS another node after that action node.
Current Behaviour -
Subsequent workflows will not execute and will be blocked.
New Behaviour
Non-Blocking workflow execution configuration
Global Settings > Workflow Automator > Settings
After the toggle is turned ON -
Basically, when the approval decision is received from Group 1 (X & Y), the workflow which is waiting for the same - Workflow 1 - that workflow alone can move ahead.
This can be achieved by setting the “Execute workflow when” setting to “All Groups approve” - Why?
This is so that the approval groups that are present inside each workflow alone are sufficient to help the system decide when to move the workflow forward.
This is how we can make approvals truly parallel across workflows - with each workflow’s resumption after approval being independent of each other.
Hence, we strongly recommend customers to first make the required changes to their workflows, turn ON this setting and then start using parallel approvals. (This setting would be deprecated in May 2026 and all existing customers would be migrated to the new behaviour)
That would make approvals truly parallel and independent (spread across workflows).
Q8: What will happen to existing approvals during the transition?
Migration Plan: Existing (pending) approval requests will be migrated to the parallel approvals model. Previously completed approvals will be grouped into a single approval group, with multiple chains created where applicable.
Q9: How will customers be supported during this transition?
Support and Communication: Customers will receive detailed migration guides and proactive outreach from the customer success team. We will also provide deprecation notices and updates on the transition timeline.
Help with Workflow Adjustments: Our GTM teams will offer support to help customers modify their workflows and ensure a smooth transition to parallel approvals.
Q10: What are the timelines for adopting Parallel Approvals?
New Signups: Parallel Approvals will be immediately available for all new signups.
Existing Customers: The feature will be rolled out gradually for existing customers, starting with those who have requested the feature. It will be applied to all customers after the deprecation period.
