Automate raising and receiving approval requests from stakeholders for service requests and changes in Freshservice. Create workflows to automate the process of raising approval requests across hierarchies. This helps maintain compliance and hierarchies for approvals across the organization.


TABLE OF CONTENTS


How approvals are processed

Before raising approvals, it is important to understand how Approvals work in Freshservice. Approvals in Freshservice consist of the following components:


  • Approvers: An individual user who receives the approval request. These can be users such as department heads, reporting managers, agent groups, or users as a part of a change advisory board (CAB). Approvers can also be users of the impacted service.

  • Approval group: Approval group refers to a set of approvers who are grouped 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 aggregate 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.


Note:
  1. The ticket or change approval status changes only when the chain is approved, rejected, or canceled.
  2. At any point, only one chain can be active. A new chain is automatically created once the ticket status is approved/rejected.


With approval groups, approvals can be sent to distinct groups of approvers with rules governing each approval.


Raising Approvals

Approval requests can be raised in one of the following ways:


Manually

To manually raise an approval from within a ticket, 

  1. Click . This brings up the Request for approval slider.


  2. Add approvers to oversee your request and grant authorization. You can select individual users or teams.


  3. Name the approval group, define the approval rule(Everyone, Anyone, Majority, or First Responder).

  4. Create a description for the approval email. Use placeholders to fill in relevant information.

  5. Add another approval group if you want the approval to execute in parallel without any dependency on the previously added approval group. Click Add approvers, add users, and define the rule for the approval group.

  6. Click send. 


This sends the approval email to all added approvers. Approval rules both at the group level and at the chain level determine whether the ticket will be approved or rejected. The following rules are offered at the group level and the chain level:

Approval Groups: 

  • Anyone: Your ticket will be approved if just one of the approvers in the group grants their approval.

  • Everyone: Your ticket will be approved only if all the approvers in the group grant their approval.

  • Majority: Your ticket will be approved if a majority of the approvers in the group grant their approval. For example, if 3 out of 5 approvers grant their approval, it will be considered as approved by the group.

  • First Responder: Your ticket will be approved/rejected based on what the very first responder of the group decides. If the first user to respond marks it as approved, your ticket will stay approved. If the first user to respond marks it as rejected, your ticket will stay rejected.

Approval Chains:

  • All groups approve: The chain will be approved only if all groups approve.

  • Any group approves: The chain will be approved even if just one of the groups approves.

  • Majority of the groups approve: The chain will be approved if a majority of the groups, say 2 out of 3, approve 

  • First responding group approves: The chain will be approved/rejected based on whether the first responding group approves/rejects. If the first group to respond marks it as approved, the chain will be approved. If the first group to respond marks it as rejected, the entire chain will be rejected. If the chain get rejected, the approval status of corresponding ticket/change also gets updated as the same.

At any given time, only one chain remains active. Only when the chain is closed, can the next chain be created.




Workflows

Approval requests can be configured as part of a workflow where the approval mail is sent to users or teams when the criteria matching the workflow action is met. Here’s how you can configure an approval as part of the workflow.

 

  1. Open a workflow of your choice.

  2. Add the action node.

  3. Select the module on which you want the action to be executed. Approvals are available for Tickets(Service Requests) and Changes.

  4. Select ‘Request for Approval’ from the dropdown and define the users/teams to whom the approval email will be sent. Assign the approval rule and add a name to the approver group. You can select between 4 approval rules: Everyone, Anyone, Majority, or First Responder.


  1. Add another approval group if you want the approval to execute in parallel without any dependency on the previously added approval group. Assign approval rules that apply to this group.


  1. Assign a rule for the entire approval chain.

     

    1. Set approval chain rule as: chain rule found on the approvals  page.

    2. Execute workflow when: This is for moving the workflow forward.

  2. Click Done.


This saves the workflow. Whenever the criteria set by the workflow are met, the approval request is sent to the relevant approvers. 


Editing or cancelling an existing approval group

Approval groups can be edited to add or remove approvers or cancelled entirely. To modify an approval group, click the 3-dot icon and click Edit approval group. This allows you to add or remove approvers from the approval group. Edits made to the approval group impact only the approval group. It does not affect the overall approval chain. If changes are made at the chain level, it impacts the overall chain.



Click Cancel the approval group if you wish to cancel it entirely. This cancels the approval group. This action is irreversible. 

Accepting/Rejecting an existing approval

Approval Requests can be accessed by approvers in one of the following channels:

 

  • Ticket


  • Email

  • Slack


  • Microsoft Teams

Roles and Permissions


Non-blocking workflow execution for approvals

This article describes how workflows involving approvals operate within Freshservice.

Note:
  • For existing users: Non-blocking workflow execution is currently available for early access. To enable this feature, please contact the Freshservice support team.

  • For new users: This non-blocking behavior will be the default setting from the May ERM (Enterprise Release Milestone).


Previously, when a workflow triggered an approval, subsequent workflows or actions that matched the same event and conditions would be blocked.

The non-blocking execution feature changes this behavior. Once an approval email is sent from an initial workflow, any subsequent workflows that match the defined event and conditions will commence execution immediately, without awaiting the outcome of the preceding approval.

Enabling the feature (for Early access users):

  1. Navigate to Settings within the workflows section.

  2. Enable the Approvals node won’t block workflows toggle to activate non-blocking behavior for all event-based workflows.
    Note: This setting must be enabled separately in your sandbox and production environments. The Sandbox sync functionality will not transfer this specific configuration.


Action required: Preparing your workflows

Before enabling the non-blocking feature, it is crucial to review and adjust your existing workflows:

  • Re-order or Modify Workflows: Examine your current workflow configurations to ensure that workflows which are currently not executing (due to being blocked by an approval) do not start executing without the correct configurations or in an unintended order once the non-blocking feature is active.

  • Enable only after Review: It is recommended to complete all necessary workflow modifications before enabling the non-blocking feature.

Impact of multiple send approval actions in sequential workflows

Consider a scenario where you have multiple workflows (e.g., Workflow 1, Workflow 2, Workflow 3) triggered by the same event, and each contains a "Send approval" action.

  • Immediate Execution: Once the approval email is dispatched from Workflow 1, Workflow 2 and Workflow 3 (if their conditions match) will also execute their "Send approval" actions without waiting for Workflow 1's approval outcome.

The following behaviour will be changed if you are using the Parallel approval feature:

  • Merged Approval Group: All approval requests sent from these sequential workflows (Workflow 1, 2, 3 in this example) will be consolidated into a single approval group within the associated ticket or change. This is consistent with the current behavior in production for such scenarios.

  • Overriding Approval Rule: The approval rule (e.g., "Everyone must approve," "Anyone can approve") of the most recent approval action will take precedence and apply to the entire merged approval group. In the example of Workflow 1, 2, and 3, the approval rule from Workflow 3 would override those from Workflow 1 and 2.

Using Parallel Approvals feature

If you are using the Parallel Approvals feature, the behavior is different:

  • Separate Approval Groups: Approvers from each workflow will be grouped separately.

  • Distinct Approval Rules: Approval groups will remain distinct, and no merging will occur. Each workflow’s progression will depend on its individual approval decision.

Use case

For example, Scenario (Merged Approvals): If multiple workflows have triggered approval emails that have been merged into a single approval group, a key question arises: which workflow will proceed once an approval decision is made?

  • Latest Workflow Moves Ahead: Only the latest workflow in the sequence that initiated an approval (e.g., Workflow 3 in our example) will proceed based on the approval decision.

  • Reasoning: Due to the merging of approvals into a single group, the system cannot specifically attribute the approval decision back to each originating workflow (e.g., Workflow 1 or Workflow 2). Therefore, even if approvers who received emails from Workflow 1 or Workflow 2 take action, these earlier workflows will not advance.

Recommendation for Intentional Blocking configurations

For customers who have intentionally configured approval nodes to block the execution of subsequent workflows, it is highly recommended to:

  • Verify in Sandbox: Thoroughly test this new non-blocking feature in a sandbox or test account.

  • Production Rollout: Only after confirming the behavior aligns with your requirements in the test environment should you consider enabling it in your production environment.

Customizable Approval Emails

You can customize approval email content for each approval group directly within the workflow configuration. This enhancement improves clarity in approval communication, helping approvers make faster and better-informed decisions.

You can do the following:

  • Flexible email content : Choose between using the default approval templates or writing custom messages specific to the workflow and approval scenario.

  • Dynamic personalization with placeholders
    Use dynamic placeholders to automatically insert contextual details, such as:

    • Ticket fields (e.g., Subject, Priority)

    • Requester information

    • Associated asset details
      This ensures each approval email is       informative, actionable, and relevant to the recipient.