Last updated: 2025-11-24
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 CONTENTSQ1: 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?
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.
Q3: What is changing in the approval process?
- 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
- 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 -
- 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)
- 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
- 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
Note: " Create a Service Request" endpoint is planned for deprecation in 2026. Hence, we strongly recommend moving to using the above endpoints. However, if you need more time to make the above changes and if you prefer to continue using this endpoint temporarily (without breakage) till you have made the necessary corrections, please follow the APIs section in the article " Introducing Groups and Chains in Approvals ".
Q4: How will this impact existing customers?
Example -
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.
- 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.
Q5: What are the required actions for customers?
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 -
- 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.
- 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”
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.
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?
- 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
- 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.