Today the service desk is a hub for requests that require actions in a number of 3rd party systems. Some of the most commonly received requests include password resets, user provisioning/de-provisioning, VM provisioning and so on. The Freshservice Orchestration Center combines the use of Freshservice’s easy to use graphical workflow automator along with 3rd party app actions that can be integrated with these workflows. This serves as your one-stop solution for all your automation and integration needs.

What is Orchestration?

Orchestration is the ability to integrate, coordinate and manage diverse systems and applications; The goal of orchestration is to streamline and optimize frequent, repeatable processes in order to ensure accurate, speedier delivery of services.

 Common use cases 

  • User Provisioning at the time of onboarding

  • Automated  Service Request fulfillment

  • Auto remediation of incidents/alerts

  • Cloud workload automation - provisioning/ deprovisioning VMs

  • Password Resets / Account Unlocks


Components of the Orchestration Center

Orchestration Center Admin Page

The Orchestration center page can be accessed from the admin section and lists a number of pre-built third party apps whose actions can be invoked within the workflow automator. Freshservice admins can install the applications that are relevant to their organization. While the list of apps supported will continue to grow every month, the common category of applications that we support today include Identity Management apps such as Okta, Azure AD, G-suite, Cloud Infra Apps such as AWS EC2 and other business applications for communication and collaboration such as Zoom and Slack


Every application requires a set of configurations that determines which account/tenant the action will take place in. If you have multiple accounts of Slack or AWS for example, you can set them up using multiple configurations which can be referenced inside the workflow automator.

App node

The App node within the Freshservice Workflow Automator can be used to invoke the relevant Orchestration app action within the workflow. For example: You can use the app node to post a message in a Slack channel when an Incident/Change is created or to Add a User to a Group in Azure AD during an Onboarding request.

The Input and output parameters for each app action along with their descriptions are available from right within the app node for any workflow designer to reference. 

Use the configuration option to determine which account / tenant of that 3rd party system the actions need to be executed on.

Test App action

You can test an app action when configuring it. This helps especially to understand if your action will succeed or return error for a sample input payload. Based on the output results of the test action, subsequent conditions can be set up for example: To proceed further only when the Status Code returned is greater than or equal to 200 and less than 300 or to check if a User does not already exists in Azure AD if the System Message returned from the action contains the phrase “does not exist”

Workflows are now context aware! This means that the outputs of one app action can be used as inputs to other condition and action nodes.

Workflow Execution Logs

Workflow execution logs serve as a single pane of glass that allow workflow designers and IT Administrators to debug and audit the execution of every workflow from start to finish. 

You can use Search and Filter options to narrow down the logs that you see and also sort the log entries by the Start Time of execution. Here’s a description of the parameters available in the logs:-

  • Time- Execution start time of that node

  • Source- Identifier of source record that triggered the automation

  • Workflow Title- Name of the workflow

  • Status- Status of that action. App action statuses are 3 fold

    • Success- Action is complete without any errors.

    • Complete with errors- The action is complete but some errors were returned. For example: When we attempt to Get the Details of a User in Azure, but that User does not exist.

    • Failed- The action failed due to a systemic issue for example: If the Orchestration service is down.

  • Node Label- Label of the node on the workflow canvas

  • System Message- Message returned from the App Action

  • Job ID- Identifier for the execution of a single workflow from start to finish or until the next event.

  • Type- The source entity the workflow fired for. (eg: Tickets, Changes, Assets..)

  • Node Details- Configuration details of the specific node.


  • Execution logs will only support execution of App Actions with this release. Support for other nodes will follow soon after.

  • Entries within the execution log will expire after 30 days

Tip: Use your sandbox environment along with the execution logs to test out your integrated workflows before deploying them to production.

Orchestration Report [Coming Soon]

Evaluate the executions associated with the app actions at an aggregate level and make informed decisions with the curated Orchestration report. You can evaluate metrics such as 

  • Total Executions within a given time period grouped by Status, App Name etc.

  • Breakdown of Apps and App Actions within a given time period.

Use case 

  1. Onboarding a new employee
    Consider Jacob, joining your organization as a new employee in the HR department.


        Step 1: When an onboarding request is received for Jacob, the system checks whether the user already exists in Azure AD  using the “Get User details by Username” action. If the user already exists, then a note is added to the ticket. 

        Step 2: If the user does not exist, then the workflow uses an app action to Create that particular User with the relevant details from the onboarding form.

        Step 3: Next we use the Lookup Group action to get the group associated with the HR Department.

        Step 4: Freshservice then adds Jacob to the Group and resolved the ticket.

2. Slack Orchestration use-case

3. AWS EC2 Provisioning

4. Azure AD Internal Transfer: