Approvals in Freshservice now follow a new process with the introduction of groups and chains. Read this article to understand the impacts on approval flows created before roll-out of the new process and actions you must take to ensure continuity.


Read this article to understand all the Frequently Asked Questions about the new approvals process. Here's the roll-out schedule for the approvals process.


TABLE OF CONTENTS

Limitations in the previous Approvals feature

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

On May 1, 2025, Freshservice introduced approval groups for all new accounts. The following new components were introduced 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 has changed?

  • Manual Approvals 
    • Previous 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
    • Previous behavior: Approval requests raised through workflows are merged without unique approval rules. The last added approval rule is set for all approvers.

      For Example, suppose two approvers are added with the rule “Everyone to approve”, and two more are added with the rule “Anyone to approve”. In that case, 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: When you trigger approvals through the API, you typically use the endpoint “Request Approval for a Service Request.” Now, since this endpoint accepts only one approver ID at a time, you might be calling the same API multiple times — once for each approver. Each call adds a new approver and sets an approval rule, such as:

    • Everyone can approve

    • Anyone can approve

    • Majority approve

    • First responder approves

Now, the key point is that the last API call defines the approval rule for the entire group. So if the last payload used “Anyone can approve,” that rule applies to all approvers combined as per the existing behaviour.

  • Post roll-out of Parallel Approvals:Once Parallel Approvals is turned on for your account, here after every API call to this same endpoint will create a new approval group — one group per approver — instead of just adding them into a single group. By default, a chain rule gets applied at the top level, and it defaults to “All groups must approve.” So even if your last API call specified “Anyone can approve,” that only applies within that one group, not across all groups. This means your overall approval might wait for every group to finish before proceeding — which could unintentionally delay your approval process. You can follow one of the below approaches to handle this scenario to ensure there is no impact to your existing approval workflows until you fully shift to using the new endpoints:
    • Approach 1 - Update the approval chain rule to control how the new approver groups behave:


      To maintain your existing approval logic, you’ll need to make one additional API call after adding all approvers.

      This call should use the new endpoint called “Update approval chain rule for a service request — setting it to match your desired behavior. You can find details about this endpoint in our API documentation at api.freshservice.com.

      In this call, you’ll pass two key pieces of information:

    • The ticket ID appended to the API endpoint.

    • The approval chain rule value, that you wish to set at the chain level in the request body of your API call for the last approver.

This extra step ensures your approval workflow behaves just as before, even under the new Parallel Approvals structure.

  • Approach 2 - Ensure all approvers stay within a single group


    Step 1: Start by using the existing endpoint called “Request Approval for a Service Request” only to trigger the approval request to the first approver. This is the same API you’ve been using all along — no change here. Trigger it once for the first approver.


    Step 2: In the response body of this API call, you’ll now receive a new attribute called “group_id”. This ID represents the approval group that was just created for that first approver. Make a note of that “group_id”, because you’ll need it in the next step. 


    Step 3:  Use the new API endpoint “Update Approval Groups of the Service Request.” You can find details about this endpoint in our API documentation at api.freshservice.com 


    In this call, you’ll pass two key pieces of information:

  • The ticket ID and the group ID you captured earlier appended to the API endpoint.
  • In the request body for this API call, include the user IDs of the remaining approvers. Then trigger the call.

This will add those additional approvers to the same approval group as the first approver. So now, instead of three separate groups, all three approvers appear together within one group retaining the same approval rule that was defined in the first API call.


Note: The two approaches outlined above are provided to only help you maintain continuity with your existing approval processes during this transition. We strongly encourage you to review the latest API documentation at api.freshservice.com to familiarize yourself with the newly introduced Parallel Approvals API endpoints.
Please plan to adopt these new endpoints at the earliest, as the current approval endpoints are scheduled for deprecation by June. We will share detailed communication and timelines well in advance to support a smooth migration. If you need assistance or guidance during this transition, please contact us at support@freshservice.com — our team will be happy to help.


Impact on existing approvals

The Freshservice team will migrate the current approvals to approval groups, with no customer intervention required.

However, it helps to understand the process changes being introduced. Here’s a summary:

  • 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.

Note: The aforementioned impacts apply for the first time when customers are migrated from the existing to the new approvals process. Post migration, the approvals capability will be in line with what has been outlined in the previous section.


    Additional scenarios -

  1. For action nodes with only one approval action configured and the rule set to "First Responder", there will be no impact after migration to the new approvals process. 

    Impact: The “Send Approval Email to” will be moved under an “Approval Group.” Approval Group name will default to Group 1 and can be updated if required.

  2. When an approval is configured in the last node of a workflow, with subsequent approvals triggered based on the current workflow:
    • Workflow 1— The last node of the workflow has an approval action and raises approval requests upon execution. 
    • Workflow 2— Executes without being blocked, and if it has an approval, the approvers are merged into the same bucket created by workflow 1. 

      Impact: 
    • 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

Non-blocking execution of workflows when approvals are configured in multiple workflows:

  • Scenario 1:
    • Let us assume an approval is configured in an action node in a workflow, and there are no nodes after an 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 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).


Impacted scenarios

  1. Within any workflow action node, do you have multiple “Send Approval Email” actions configured?
    1. If there is only one “Send Approval Email” action, no functional changes are required — the approvers will be grouped together, and execution will remain unchanged.
    2. If there are multiple such actions, during feature enablement, all approvers associated with those actions will be consolidated into a single group. This ensures consistency with your current process behavior.
  2. Are your workflows typically configured with consecutive approvals, such as:
    Approval 1 (Action Node) > Approval 2 (Action Node)
    1. In this setup, once the first level approval is granted, the workflow progresses to the second-level approval.
    2. If your workflows are configured in this manner, the same behavior will continue post-enhancement. The notes mentioned in sections 1.a and 1.b will remain applicable.
  3. Are approvals configured as the final action node in your workflows, or do they precede other nodes (e.g., Approval > Action)?
    1. If approval is the last node - 
      1. Currently the approvers from that node will be merged with approvers (if any) in the next workflow’s approval
      2. In the new world - the approvers from the final approval (Action) node of the first workflow will be created as a distinct group.
    2. If there are nodes after the approval node - 
      1. We strongly recommend you review the Non-Blocking Workflow Execution documentation and enable that configuration after reordering workflows as needed. 
  4. Are approvals configured within a single workflow or distributed across multiple workflows?
    1. If approvals are configured across multiple workflows, we strongly recommend reviewing the Non-Blocking Workflow Execution documentation and enabling that configuration after reordering workflows as needed. 
    2. This will help ensure a seamless and optimized automation experience.


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, contact your TAM/CSM and work with them to better understand the required changes and migration impacts.
  1. Plan-wise roll-out schedule:
    1. Free: Nov 5-10
    2. Starter: Nov 10-16
    3. Growth: Nov 17-23
    4. Pro: Dec 1-7
    5. Enterprise: Dec 8-14
  2. For non-blocking execution configuration, we strongly recommend customers 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 the upcoming migration cycles. Read more.