Starting November 5th, 2025, Freshservice is changing how approvals are raised and granted. Read this article to understand the impacts on existing approval flows and actions you must take.


Read this article to understand all the Frequently Asked Questions about the new approvals process. 


TABLE OF CONTENTS


Limitations in the current Approvals capability

Freshservice allows you to raise approval requests where you can assign one of 4 rules—approval by Everyone, Anyone, Majority, or the First Responder. Approval requests raised manually or through workflows or APIs, are merged and executed in a sequence. There is no scope to raise approval requests simultaneously to users or a group of users.


To understand this better, let’s consider an example. Upgrading payroll software requires approval from IT, change management, payroll, and HR. 


With the current approval process supported by Freshservice, this would be executed sequentially, not simultaneously. The approval is sent first to IT. Once IT acts upon it, it is sent further to other teams. This leads to a longer approval cycle. Additionally, for multiple approval requests, the latest approval rule overrides previous rules.


Introducing Approval Groups

Starting May 1, 2025, Freshservice is introducing approval groups. Freshservice is introducing the following new components to the approvals process:

  • Approvers: An individual user who will receive an approval request. Approvers can refer to any entity— users, agents, requesters, Change Advisory Boards, and owners of impacted services.

  • Approval group: Approval group refers to a set of approvers who are grouped together for granting approvals. For each approval group, approval rules can be set by the agent or admin. The rules determine the outcome of the approval—Everyone, Anyone, Majority, and First Responder.

  • Approval chain: Approval chains contain multiple approval groups. Each approval chain comprises groups that independently grant approval or rejection on a ticket/change. Here again, approval rules can be set for the chain—All groups approve, Any group approves, Majority of the groups approve, First responding group approves. Only when conditions set by the rules are met will the entire chain be considered approved. The process of approval within the groups can happen in parallel and in no particular order.


How Approval Groups work

With approval groups, approvals can be sent to distinct groups of approvers with rules governing each approval. There are three ways in which approval groups are created:

  • Manual: When an agent/requester raises an approval request, approval groups are created.
  • Through workflows: When a ‘send approval email’ action is triggered, it creates an approval group with the users under the action added to one group.
  • APIs: When an API request is placed to the approvals API.


Here’s how approval groups will look like in Freshservice:

What is changing?

  • Manual Approvals 
    • Current behavior: When multiple approval requests are triggered, they are merged, and the latest approval rule overrides previously added rules.
    • Post roll-out of Parallel Approvals:
      • All new approval requests will be created using approval groups and chains.
      • Approval requests will not merge anymore.
      • The approval rule will not be overridden by default. 
Note: This will apply to approval requests raised manually, via workflows, or APIs.


  • Workflows
    • Current behavior: Approval requests raised through workflows are merged without unique approval rules. The last added approval rule is set for all approvers.

      For Example, if two approvers are added with the rule “Everyone to approve”, and two more are added with the rule “Anyone to approve”, Freshservice will merge all four approvers into a single set and set the approval rule to "Anyone to approve".
    • Post roll-out of Parallel Approvals:
      • All approval actions will be grouped under a new action “Request for approval” in workflows.
      • Each “Send approval mail to” action creates a dedicated approval group. 
      • Approval groups can be named.
      • Rules can be defined at the level of the group.
      • A new action “Set rule for approval chain as” will define the rule for approval chain.
      • For action nodes with more than one “Send approval mail to” action, a new configuration, “Execute this workflow when”, is introduced. This helps users define when a workflow proceeds further.
      • Choosing any of the first four options would mean that the decision of approval groups within that action node can decide if the workflow should move forward or not.
        If the “Ticket/Change approval status is approved” option is selected, the workflow proceeds only when all approvers (workflow-added and manually added) approve, reflecting the overall approval status.

        For Example -
        A new employee needs access to a MacBook and Microsoft Office. The MacBook is housed in the Hardware department, while MS Office falls under software. Approvals are required from both the software and hardware teams. Assume a workflow sends approval emails for the 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”.
      • Previous behaviour -
        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. 

        Post rollout of parallel approvals
        In the new world, these are created 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.

  • APIs
    • Current behavior: Approvals raised via APIs get merged, and the latest set approval rule takes precedence.


    • Post roll-out of Parallel Approvals: An optional parameter, approval_group_id, is being introduced to the current API to enable the addition of approvers to a specific approval group.

      Note: If approval_group_id is not provided, distinct approval groups will be created for every API hit. They will be part of the current approval chain.


Impact on existing approvals

The Freshservice team will perform the migration from the current approvals to approval groups with no intervention required from customers.

But it is important for customers to be aware of the process changes that are introduced.  


Here’s a summary of all the impacts -
Important note: This is only for the first time when customers are migrated from the existing behaviour to the new approvals process. Post that, things will work for the new approvals capability as detailed in the previous section. 

  • Tickets or changes that have already been approved will not be impacted.
  • Approvals raised through workflows:
    • Workflow configurations having more than one ‘Send approval email’ in an action node, these will be merged into one single approval group (default name is Group 1 and it can be updated)
    • For all these action nodes, the “Execute this workflow when” configuration will be set as ‘Ticket/change approval status is approved’.
    • Workflows with multiple “Send approval email” actions that have other actions in between will be combined into a single approval group and the UI will reflect the same. There will be no impact on behavior. 
  • After the feature is enabled, customers can create new approval groups or add approvers to the existing group as required. 

Note: 

  • When the feature is enabled for the first time, the approval rule of the last “Send approval mail to” in the action node will be adopted. If the last one does not have a rule due to only one approver being present, the rule of the prior one will be used.
  • If different "From Emails" are configured against each send approval action, the last configured “From Email” will be used for the group. This applies only to the Tickets module.

Additional scenarios -


  1. If there is an action node with just one approval action and the rule is configured as "First Responder", there will be no impact after the new feature is enabled - just that the “Send Approval Email to” will change to “Approval Group”. The Approval Group name will be defaulted to Group 1 and can be updated as required.

  2. When an approval is configured in the last node of a workflow -
    1. Workflow 1 - the last node has an approval action and raises approval requests upon execution
    2. Then workflow 2 executes without being blocked and if it has an approval - the approvers are merged into the same bucket created by workflow 1. 
    3. Once the feature is enabled - there will be two separate groups - one for the action in workflow 1 and the other for the action in workflow 2.


Non blocking execution of workflows when approvals are 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 the 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. That would make approvals truly parallel and independent (spread across workflows).


Feature roll-out details

The feature roll-out is planned in the following phases:

  1. New sign-ups: 
    1. For new signups post May 1st, 2025, approval groups will be available by default. 
    2. Non-blocking workflow execution is also enabled by default.
  1. Early access: To try out approval groups, please contact your TAM/CSM and work with them to fully understand the changes required and migration impacts.
  1. General Availability: 
    1. On Nov 5th, 2025, approval groups will be available for all accounts.
    2. For non-blocking execution configuration, we strongly recommend customers to turn ON the setting after reconfiguring workflows. This setting would be enabled and removed from the UI down the line. Communication for the same would be sent out as part of upcoming migration cycles.